Let’s see who can guess the two designs I’m referring to. Here’s a hint: they’re more psychological than technical—and if you say anything involving the words “GUI,” “CLI,” “mouse,” or “wizard,” you’re way off track.
The two designs are (drum roll)…
Memorized actions and search.
Though I seem to refer to these architectures as a dichotomy, that is more for historical than strictly technical reasons. For example, this mouseless GUI design shamelessly masquerades as a search design while subconsciously teaching the user memorized actions. However, the intersection of the two designs is usually limited to mixing paradigms, such as having shortcuts keys that are redundant with visible buttons, or listing available shortcuts in pull-down menus. The purest examples of these paradigms would be the command-line interface and the wizard—the former highly criticized for an exceptionally steep learning curve, the latter for inflexible, cumbersome operation.
While this distinction in paradigm seems to be a rather esoteric point, there are far-reaching consequences that an interface designer should be acutely aware of.
For example, selection between these two approaches is based on superficial, abstracted consequences of such design decisions. User interfaces more commonly are discussed by such phrases as “Do we want to use wizards?” and “Should we depend on shortcuts or icons?” rather than the underlying decisions “Are the users willing to be trained to learn the software for efficiency of use?”, “Do the users value ease of learning over operational expedition?”, or “How can we make the program easy to use but still encourage frequent users to adopt better use habits than beginners?” Just as horrific code comes from programmers designing software before understanding the problem they are trying to solve, this skipping over the most fundamental aspect of an interface rarely results in good design, and then only by accident.
Another example of the extraordinary importance of this distinction is the advent Graphical User Interface. Aside from falling cost, little else did as much to mainstream computing as the mouse-based GUI pioneered by Xerox Star and popularized (or, depending on your political stance, stolen) by Apple’s Macintosh. The magic of these computers is usually attributed to the hardware difference—the mouse—which, while good at its job, has its shortcomings. The real credit, however, belongs to the groundbreaking design of an interface which, instead of compelling the user to endure the tedious process of becoming an expert in the interface, allowed the user to learn only how to search within the interface for what they want. It was one of the most dramatic changes in the history of computing: from an at least partially memorization-based design to comprehensively search-based. Granted, there were precedents of on-screen hints, some menues, and so on, but training and the need to refer to a manual while using software was (until GUIs) not only acceptable, but expected (violating Jef Raskin’s sacred train of thought).
User interface designers have discovered that exclusively or primarily memorization-based interfaces are wholly unsalable for anyone outside of the professional software” market, where speed of use is king; “home users”, on the other hand, demand that interfaces be “intuitive,” “discoverable,” and usually attractive. Consequently, search-, and by extension, graphical mouse-based interfaces are blessed with the near entirety of usability research. (It seems that most researchers have decided that piling a bunch of keyboard shortcuts and feedback-less mouse actions into an program are the omega of professional “fast” interfaces, warranting little theoretical attention).
However, as the world becomes increasingly computerized, everyone comes closer to being a “computing professional,” and the time savings that further optimized interfaces confer become ever more beneficial to everyone. With memorization-based interfaces seemingly off the table, designers have made attempts of varying success to optimize the search experience.
Incremental search (perhaps better termed incremental refinment), popularized by iTunes more than any other application before it, has seen high praise, thanks to its ability to quickly refine your search domain to an essentially instantly visually searchable list. The greatest criticism is that it requires some fore-knowledge of what you’re looking for. Well-designed fuzzy search terms would fairly readily minimize this issue, however. More importantly, though, this interface leverages the user’s knowledge—in effect memorization—to turn a slow searching task into a very rapid one! See Long Zheng’s blog entry on “Scout” for Office’s new ribbon toolbar for an example of how to use even a little memorization to expedite access t commands, or even eliminate the context switching that the ribbon forces between most commands.
Another way give the user both slow (but easy to learn) search, and harder to learn (but faster to use) memorization is to blend memorization into the search process.
There are numerous other ways to improve the user experience—when a designer has a firm idea of the of the premises upon which an application is built.
Gc | 08-Jul-07 at 6:01 pm | Permalink
I think you oversimplify CLI. Command line interfaces have long had ways to search for help, so they are not strictly memorized. The simplest is the help command, or the ? command. Some interfaces have command completion, some have documentation search (often called “apropos”).
Along this line of thinking, one important difference is that when you search for help in a GUI, it is all in menu popups or help page popups that disappear (or at least can be hidden), so you can get back to what you were doing after you have finished searching for the action. In CLI interfaces, the help output is interspersed with the real work.
For this distinction, it might be better to distinguish windowed interfaces vs. command line interfaces. There are windowed interfaces to character terminals, where different rectangular areas of the screen are dedicated to different purposes. Many operating systems have character based text editors, such as emacs or vi, which divide the character terminal screen into different windows without being graphical.
Another important difference might be that a GUI divides commands into a hierarchy of categories (the tree of menus), whereas CLI help is often not so hierarchical.
clay | 08-Jul-07 at 6:33 pm | Permalink
While I probably did overstate the dependence of CLI/Console/Text interfaces, the point about the GUI was that (especially with Apple’s early offerings) the GUI was essentially completely search-based, and that was the major reason for the sudden increase in apparent accessibility.
As for your suggestion that I distinguish between windowed and command-line interfaces, the point of the entry was not that there were no other ways to differentiate designs, but rather that memorization versus search is on that is generally overlooked, and that it could be argued to be one of the most fundamental decisions.
James G Sack | 09-Jul-07 at 1:22 pm | Permalink
I come here after reading your nice _mouseless_ article.
Regarding _only two_, I wonder if that includes in some subtle way or perhaps overlooks the concept of spatial mapping and motion, which brings back into consideration the valid uses of the mouse (pointing device).
As a simple example, while there may be keyboard bindings to perform scrolling (and drawing), the mouse offers some advantages in it’s role as the architypical pointing device.
However, there certainly remain some mouse behavior things still looking for solutions. Here’s one I thought you might be interested in:
Scrollbars on long documents are often almost totally useless (as a positioning tool) because the viewport moves way too much for the smallest mouse drag motion. At least for me, the scrolling operation is so disorienting that I specificaly avoid using it.
When the document is less than ‘a few’ times the length of the viewport, the scrollbar paradigm works just marvelously, I would say.
I’m thinking that when the document length is above some limit (relative to viewport length), there should be an alternate (visually distinguished) mouse _thumb_ surrounding the usual one. The usual one shrinks as the document grows, but the alternate one might be thought of as position within the surrounding ‘few viewports-worth’ of document, and has a minimum size. The alternate thumb would be designed to scroll more slowly, as if the document were shorter. It is left as an excercise for the reader to resolve the details of moving the alternate thumb, resyncing alternate with traditional thumb, continuing to scroll at boundaries, etc.
I suppose it is also useful and necessary to look at gesture mechanisms and mousewheel behavior. I believe Microsoft Vista has some changes in this area worth examining, as well.
Keep up the good work!
Regards,
..jim
minimal design | 09-Jul-07 at 3:57 pm | Permalink
I was writing a comment on your blog but it turned into something way too long to post here ;) So I posted it on my blog at:
http://minimaldesign.net/blog/web-design/behaviors-and-ui-design
You might be interested, and I’m definitely curious to see what you think about it. Small warning: I respectfully doubt the usefulness of your article on there… But I’m very open to discussion and definitely not looking for a fight!
Rob St. Amant | 09-Jul-07 at 8:57 pm | Permalink
Memorized actions and search.
This distinction strikes me as being very similar to the familiar “recall versus recognition” issue in HCI. Is there something more to it that I’m missing?
Peter Amstutz | 10-Jul-07 at 12:42 pm | Permalink
A few comments –
Like anything else, both “search” and “memorization” based interfaces can be done well or done poorly. However, I think it is a false dichotomy, because most good user interfaces allow the user to start with search and work their way towards memorization.
One thing that is important to consider is the “distance” between commands or modes. A memorization based interface encourages a “flat” command space, where you can access all possible commands or values with just a few keystrokes. Hierarchical search based interfaces traditionally tend to bury those same commands under several levels of menus, icons and dialog boxes which require multiple mouse clicks to access.
Where the flat command space really wins, though, is that it is actually easier to search. By typing in part of the command name and/or annotating commands with a full text description with additional keywords, the user can often find the commands they need in a simpler and more straightforward way than hunting through menus.
A downside to the flat command space is that it often harder to discover new commands. Where in a hierarchical-search based interface the user will often stumble upon other functionality in their search for some particular command, the ability to access commands more efficiently actually reduces this aspect of discovery.
The best example of a searchable memorization-based interface is Emacs. I know of no other program where one can have 400+ different files, buffers and views open, and yet be able to switch between them with only three or four keystrokes. At the same time, I can go into the help text and use the standard text search features to quickly find the commands I am looking for. The GUI version of Emacs also has the usual windows, buttons and dialog boxes, to help new users get up to speed. It is a “scalable” user interface. We study how to make computers scale up to process large amounts of information, why not study how to design interfaces that scale up to allow you to work with huge amounts of information?
Peter Amstutz | 10-Jul-07 at 12:54 pm | Permalink
I just thought of one other point I wanted to make. Memorization interfaces are typically more language or word based. Keystrokes are “verbs”. Visual search based interfaces are, for obvious reasons, usually graphical, and often spurn the richness of language in favor of inscrutable icons.
One of the best examples of combining language with a visual interfaces is the ability in OS X to search the control panel for keywords, and it will suggest which panels you are interested in. Don’t know where to configure DHCP? Type “DHCP” into the search and it will present you with the correct tab of the correct control panel.
Going back to the Emacs example, since it is entirely based on text and language, searching is trivial.
It’s fair to argue a language-based interface probably will not work as well for something like Photoshop, although even in that case there are a lot of hidden layers (both literally and figuratively) and abstraction in how you work with the application that are not necessarily best served by purely graphical push-button UI.
So I think there is a visual vs. language dynamic going on here — similar to recognition vs. recall dynamic mentioned by a previous poster.
Rob St. Amant | 11-Jul-07 at 5:39 am | Permalink
One thing I do like about Clay’s post is that the dichotomy he identifies is not at the level of “Am I using a command line or a GUI for interaction?” Another example of what he’s getting at is marking menus. Superficially, pie menus are just menu items arranged in a circle, but two other things make them interesting: muscular memory acquired over time can turn an exploratory action sequence into a learned gesture, and for experienced users the menus themselves may not even need to be displayed. Some of the same ideas are nicely worked out in Shumin Zhai’s SHARK work.