Awhile back I was working on some UI for a program that offered the user great flexibility. Good thing, yes? Well… when you start having to reckon with UI text, such as naming a feature or an option, the difficulty quickly becomes clear.
Let’s say you decide to send an IM to your pal. You click a button, right? During the chat you decide that you’d rather talk on the phone with them, and fortuitously the program allows you to transition from one mode to another by clicking a subsequent button. (That is, you could phone them using the computer…like with Skype. Don’t get me started.) Anyway, if the label for the button you originally clicked apparently narrowed your action to sending an instant message, that’s misleading. And from the evangelism standpoint it doesn’t hype the great feature. You’d have been led to believe that you had to do one thing or the other, and the great functionality might be a rude surprise if you discovered it at all.
On the other hand, that workflow seems relatively intuitive, if not common, so there’s an argument for keeping that nomenclature. But there are other cases where ambiguity (or versatility!) starts to make me a little crazy. In most cases, I’d posit, at some point the user has to “fish or cut bait” – choose what he or she wants! Is it an advantage to let users do this at multiple points in the process, instead of having a clear-cut choice at the to level?
For example, do you want to save the document or print it? You wouldn’t instinctively think you’d be able to print it by clicking Save, and typically users are fine with having to make that choice up front. Change your mind? Go back and click the right button. And ultimately it comes around to terminology: if you could in fact print from the Save dialog box, shouldn’t the label of the initiating command (and dialog box) be “Save or Print”? Fulfilling expectations is important. In general this is the way things work.
But in the IM/phone case, to be accurate this would require a very vague top-level command like “Communicate” that would leave your options open – or one or more long labels to point out the possibilities -- and then lower-level commands to get you going down any later road you really want. But there have to be choices for people who know what they want to do at the outset as well as for those who change their minds later. So it’s not ideal to have the vague top-level command(s). And there you are, faced with precise but inaccurate top-level commands and additional precise lower level ones. (Also it’s what they call an endless regression because every time you change mode there’s still the possibility of further waffling -- excuse me, flexibility – so it’s never entirely accurate to use a term that limits the user’s choices.
So there are two issues – how to design so that flexibility is not confusing, and how to talk about flexibility without becoming either meaninglessly vague or irritatingly verbose. Welcome to my world. Maybe I’m over-thinking the whole thing. Hmm, I need some coffee.