Writely or Wrongly, WebOS is Coming

Predating the first Internet bubble, there was the applet craze: It was thought that software would be delivered through the Web, on demand. Java was riding high on this fad, and lost a lot of credibility when the immaturity of Java technology (i.e. the unsuitability of AWT for making big, rich UIs on PC clients), low Internet connection speeds, high bandwidth costs, and Microsoft’s adverse reaction to hosting a potentially undermining technology in the bosom of their desktop OS, worked together to make applets less of the big deal than the pundits made them out to be.

Microsoft was able to contribute to blocking this disruption, but was not able to directly counter it or provide an alternative. .NET, like Java, became one of those dull gray tools of the IT crowd – a means of making multi-tier software systems without the hassle of understanding the complex threading implementations needed to make a middle tier that can serve thousands of users. This, despite the fact that .NET implemented code-behind-HTML and other features that made it quite a good tool for delivering user interface in Web pages.

Web hackers – the sort that don’t program in Real Languages like C# and Java - who never got the memo about server software, kept plugging away at making the Web user experience better.

“Better” means escaping the UI-as-form-filling paradigm that gave the Web a plodding, oppressive feel any time user input was required. The Web was born a hypertext system. Accommodating interaction beyond that required for hypertext is something that should be unsurprising in its difficulty.

Mapping MVC architecture onto multi-tier Web applications is not easy. In Web applications, the model is usually a relational database. The view is projected by middle-tier through a Web browser, which may include client-side code in Javascript. This complexity, and the hypertext heritage of the Web browser keep sucking Web UI back to a series of forms to fill out.

A rich Web user interface has to be debugged across multiple tiers, and, in the case of Javascript, across the client-to-middle-tier network connection. So, most Web UIs fail to grasp how to bring a consistent and highly interactive experience to the user and settle for the equivalent of what passed for UI back in the days of DOS, but with a prettier layout.

For an idea of the size of this problem and the value of simplifying the solution, take a look, on the one hand, at Enterprise Java Beans, even in its much cleaner 3.0 implementation, and, on the other hand, Ruby on Rails, which epitomizes the Web 2.0 ethos of productivity over universality. By focusing on solving exactly the above specific problem, which, while narrow in scope, vexes a large number of application developers, Ruby on Rails struck a very resonant tone, and has made an impression beyond the number of projects that actually use Ruby on Rails.

Ruby on Rails belongs in a spectrum of technologies we can call “Web OS.” Web OS is a system for running and building applications that run on Web servers and are used through the medium of a Web browser. Ruby on Rails is at the “building” end of the spectrum, while application suites like Writely, Gmail and Google Calendar, that have Web services interfaces but no SDK, are at the “running-only” end of the spectrum (although you can be sure Google has an impressive set of tools for their own coders).

We will soon see a lot more Web OS attempts, and, hopefully, some successes. Success, in this context, means making it possible for a large number of coders – not just those with Google's resources for toolsmithing – to create and run rich Web-based applications that truly break free from the “screen A -> screen B -> screen C” model of UI misdesign.

Whatever you may think about having your documents live on a server and editing them with tools that also live on servers, the WebOS future is likely to provide some interesting results: One easy prediction to make is that the mash-up culture will spread to all manner of applications, whereas the component document technologies that were supposed to put a spreadsheet inside your word processing document never really delivered. Maps, communication, auctions, translation, etc. will drop into Web OS documents naturally, because the data and communication that animates these document mash-ups will be available and compatible.

This is what makes Web OS interesting. If it stopped at implementing MVC applications in a particularly challenging implementation environment it would be only a technology curiosity, and probably not enough to motivate investment. But Web OS applications really can be better.

It's a good thing developers of these applications were never told how hard that is to do.

The Model-View-Controller Design Pattern and iPod-like User Interfaces

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.