Presentation

Presentation

It's all just dialogs and data.

—Mike Cohn

Presentation: it seems so simple. Just toss up some dialogs, some buttons, a few list boxes and scroll bars, and it'll be obvious to the user what's going on, right? Take the users' input, scrub it, send it back to the server, and we're done.

For many developers, building the user interface is quite possibly the most fun part of the job. Part of the reason lies in the fact that the user interface, unlike much of the rest of the system, is a visible, tangible, measurable indicator of progress. This morning, I had an empty window—this afternoon, I have a screen that a user can interact with (even though it does nothing under the hood). The user interface is also one of the few parts of the system that users can understand and appreciate. Very few, if any, users will be able to look at your transactional-processing logic and say, "Oooh, ACID transactions. Way cool—you guys rock." But show average users a slick GUI in a progress meeting, show them how we can automatically populate a UI form with data based on a field they've just entered, and watch an entire room melt with love for the programming team. Given the choice between a "ho-hum, whatever" reaction and an expression of undying love and respect, is it any wonder that many programmers prefer to build the user interface?

Unfortunately, perils lie in wait for the naïve UI programmer.

Many developers discover, usually just days before the project is scheduled to ship, that users have a very firm mental model of what the system was supposed to do, and if the user interface doesn't reflect that mental model, the users' appreciation will quickly degenerate into scorn. User interfaces tend to be the most heavily modified part of the application, as developers try to placate the user community with last-second changes that seem to be based on nothing more than whims.

Also, as many users learn over time, programmers are not always the best ones to design the user interface in the first place. Alan Cooper, father of Visual Basic and author of UI books The Inmates Are Running the Asylum [Cooper99] and About Face 2.0 [Cooper03], has made a career out of consulting with companies on customer-oriented UI design. He cites UI research from some of the most heavily user-centric applications (particularly those from a large software company in the Pacific Northwest) in his examples of botched UI design. What seems obvious to us as developers tends to be cryptic and obscure to those who don't write code for a living.

And as if those two traps weren't enough, for Web-based applications things get even worse. While the Web brought millions of casual computer users together into a huge, interconnected community, the principal portal of communication for those users—the Web browser—took user interfaces back by at least a decade, returning us to applications whose fanciest UI idiom was the graphical push button. What's worse, the HTML-based application depends entirely on the server; while this means that no special software is required on the end-user machine to execute the HTML-based application, it also means that everything must be conveyed over the network, adding significantly to the bandwidth consumption requirements. For applications that need to scale out to millions of concurrent users, greater bandwidth consumption is exactly what we need to avoid.

The net result? There's more to building the presentation than just slapping some HTML on a JSP page.