In my previous blog entry I asked whether the iPod is an example of a new user interface paradigm, and concluded that it is. This time, I try to provide more of the nomenclature for describing user interfaces of this type.
Discussion of desktop user interfaces is much aided by the desktop metaphor conceptual framework, augmented by the MVC (model-view-controller) design pattern. The desktop metaphor describes how overlapping graphics contexts give rise to on-screen windows that mimic the look of overlapping pieces of paper. MVC provides a design framework for (potentially) multiple views of the same data to be present on the screen and to stay in synch as the underlying data changes.
Together, the desktop metaphor and MVC are the foundation of nearly every non-trivial desktop user interface. iPod-like user interfaces discard the desktop metaphor. Overlapping objects are out of place on the iPod. They have no metaphoric meaning, and the screen is too small to give overlapping objects enough visual context.
In the desktop metaphor, each window is a viewport into a two-dimensional document that extends, mostly, above and below the view the viewport provides. In an iPod-like user interface, the whole of the screen is a viewport into a document consisting of a network of nodes. And here is found an interesting connection to the desktop metaphor: Most document data models are networks of nodes: Web browsers’ data models of Web pages, for example. The iPod, therefore, achieves an elegant presentation of a document by being one step closer to the type of data model used to model many documents.
The iPod shows that MVC is not inextricably linked to the desktop metaphor: The iPod has a model, a view, and a controller, although each is simplified: The model doesn’t change until iTunes changes it, the view is a full-screen view of just one set of nodes which all are children of the same parent-node, and the controller provides no means of editing the content of nodes.
Not every element of the desktop metaphor is a success. The desktop metaphor is plagued by an innovation known as the dialog box. The dialog box is familiar to most users, and in its most florid examples brings no less joy than a long session of filling out tax forms. The dialog box was a feature, used sparingly, in early desktop metaphor user interfaces, to put a pressing matter in front of the user, in situations where the user could not proceed without at least acknowledging the matter, e.g. a serious error. Since then, user interfaces have experienced a metastasis of the dialog box as mediocre designers, armed with visual dialog box layout tools, have attached numerous multi-tabbed tumors to software. Pre-AJAX Web user interfaces brought the dialog box to its pinnacle of dominance: If you have ever filled out a multi-page “registration” for some Web site, you know it well.
The iPod does without dialog boxes, not least because text entry on an iPod would be brutally hard, but also because dialog boxes, like other overlapping elements, have no good visual representation on an iPod-sized screen. The lesson embodied in the desktop metaphor’s encrustation of dialog boxes compared with the iPods lack of such goiters is that designing the direct manipulation of the data model is hard, and widgets, dialogs, and menus are easy. The iPod escapes this damage by being an environment that is hostile to the concept and implementation of dialog boxes. The iPod is also a browser, not an editor, and therefore manipulation means viewing, not modification.
Can this simplified MVC user interface survive being extended into providing a first party call control user interface? Or a mobile commerce interface that brings iTunes Music Store into a connected iPod? While these are not small design challenges, there is reason to think this simple and elegant UI paradigm can encompass new functions without losing its qualities: First party call control is not document manipulation. It has its own very severe challenges, but it should not require a fundamental shift away from the iPod user interface. Similarly, shopping can be thought of as a series of database queries followed by the user browsing the results. This, too, should be possible to implement in the iPod paradigm without warping it out of shape. These examples are not randomly chosen: If there is to be a wirelessly networked iPod that includes a PLMN or VOIP telephony subsystem, these are the major components that would have to be added to the iPod user interface.
The iPod can also be categorized as a “one-handed” UI. One-handedness is also linked to the lack of overlapping elements in the iPod UI: If you don’t have a pointing device to access overlapping elements the way you would access papers on a desk, you should not have them in the UI. Failure to heed this distinction between one-handed and two-handed UIs leads to such kludges as “two level focus” and other severe compromises that are inherently incomprehensible and inexplicable to users. For examples, you can look to any mobile handset HTML Web browser that attempts to map the two-handed PC Web browser human interface to a one-handed handset interface. Microsoft still struggles to fully reshape the two-handed Windows CE user interface – which is a fine user interface if you assume the user is holding a stylus – into a friendly one-handed UI for mobile phones. Two handed UIs allow rich and ambitious interfaces, while the iPod’s strict observance of what the user’s thumb is capable of leads to an entirely different result.
The iPod, therefore, can considered to be a full-fledged example of a distinct user interface conceptual framework. It has all the characteristics of the consistent application of such a conceptual framework to an implementation. Graph or network traversal, one-node-at-a-time views, mapping of architectural aspects to the MVC design pattern, and extensibility to other application domains put the iPod UI alongside the desktop metaphor as something that we will likely see more of, in other types of devices, applied to other domains.