
This is a screenshot of the Cisco IP Communicator software. You can use it to make phone calls on your computer over the internet, which is cool because it uses your office extension so you can work from anywhere without having to tell your work friends to call a different number.
It is also a great example of software whose UI uses a metaphor — a term I’ll apply to interfaces that are designed to evoke a familiar non-software object to encourage ease of use. CIPC looks and behaves exactly like the physical phone sitting on your desk, so you can use it without having to learn anything new.
Recognizable metaphors are attractive to UI designers, but metaphors often do more harm than good:
Most metaphors are incomplete – software generally doesn't exactly mirror the object its interface is based on – and it's hard for users to understand how software will function when the metaphor fails. For example, even after you empty the "trash can" in OS X, your files are still recoverable, even though the trash can metaphor suggests they are gone forever (or at least inaccessible).
(And More Importantly) Metaphors are often based on objects that would have been designed differently if the capabilities of a computer were available to them.
CIPC is a great example of this. The designers of the OG phone would have done things differently had they full keyboards, high resolution screens, and copious processing power available to them. Why should computer software mimic items that were designed the way they were because they couldn't take advantage of a computer? In the CIPC case, for example, all I want is an autocompleting text box into which I can enter the name of the person I want to call.
CIPC is a great example of this. The designers of the OG phone would have done things differently had they full keyboards, high resolution screens, and copious processing power available to them. Why should computer software mimic items that were designed the way they were because they couldn’t take advantage of a computer? In the CIPC case, for example, all I want is an autocompleting text box into which I can enter the name of the person I want to call.
The trash can I mentioned in (1) is also relevant for (2). Why should I have to “move” something to delete it? Pressing “delete” should cause the file to disappear, viewable (in its original directory) if I do something like View » Show Deleted Items.
For that matter, why should there be any concept of “emptying the trash” i.e., (per the metaphor) “deleting files forever”? When you “empty the trash”, what’s actually going on is the operating system designates those files “safe to write over with other data”. However, the operating system should be smart enough not to write over any of these “deleted” files until it has to. In the case of a 50Kb Word document on a 1000GB hard drive, this should be virtually never.
There’s no good trash can-like metaphor for a filesystem that saves every version of every document, and maybe this makes such a system harder for a beginner to understand; but the benefits it would offer to intermediate and advanced users would more than compensate.
Another good example of this is the filing cabinet / folder metaphor for organizing files. (As a side point, this metaphor isn’t even that strong — no physical filing cabinet has folders nested 10 levels deep, and the fact that you can do this on a computer is confusing to beginners). In a physical filing cabinet, a document can only be in one folder. However, on a computer, a single “file” can be “placed” in any number of “folders”. Why can’t I describe “Annual Report.doc” as both Categories » Work » Reports » Annual Report.doc and Time » 2008 » December » Annual Report.doc? (Google Docs is moving in this direction — it’s about time).