The Nature of Web Apps

How is a web application different from a desktop application?

Web apps are more document-like. They're more coarse-grained. A web view (the page) will typically contain relatively larger amounts of information than a desktop application's view. This stems from the nature of web apps: that they're remote, and thus must be more coarse-grained: less frequent round trips to the server but fetching more information per trip.

This gives web applications a different feel from desktop applications and also present different usability challenges. For example, all browsers I know support a word-processor "find" feature that lets you find a piece of text on a page. The browser will auto-scroll to the proper location and highlight the matching text on the page.

Mozilla is the example to follow in this case. One can use this feature without taking one's fingers off the keyboard. Simply typing the search characters automatically starts searching through the page. If the text is part of a hyperlink, then pressing enter will have the same effect as clicking on that link.

This feature validates something very interesting about the nature of web applications: they will often contain a large enough amount of information that it is necessary via various means or techniques to make the end user's job of finding information (within that page) easier. Thus the find feature. But it doesn't have to stop there. Furthermore, these techniques don't all have to be generic.

A web application developer can build little tools or ui widgets into the app that takes advantage of the developer's knowledge of the application's domain to make the usability of the application really shine.

Fortunately for us, CSS features such as visibility, font styling, color-coding can be employed with ease to provide a whole suite of such features. The samples you see in the sidebar are such techniques.

Let's quickly discuss each sample in view of this usability issue:

Show/Hide Error

Instead of displaying an error in its entirety, thus cluttering a page with lots of information that the end user may not be interested in, the error's details are hidden, and summoned only at the end-user's request by clicking on a button. They're just as easily removed or hidden again.

Scrolling

Sites are armed with headers, footers, sidebars, and menus for a very good reason. These areas are like the end-user's cockpit controls. They need to be accessible at all times. Unfortunately, most page bodies can be quite lengthy at times and scrolling the main body often results in these controls scrolling out of view. The header or footer or sidebar links will often be clipped when the end user scrolls to view parts of the page body. Simply scrolling the body and not the rest of the page is the solution in this case.

Master/Detail

The epitome of the web-based catalog is the idea of viewing a list of entries and then being able to drill down to the specifics of a single item. In the case of the two round trips to the server, one to fetch the listing, and another to view the details, we don't have the issue of the details of a different item cluttering the user's locus of attention.

But there are plenty of cases where both the listing and the details are on the same page. For example: javadocs. A typical class page template will show the details of each and every method on a single page. The master/detail sample shows how to remove from site anything but the one item that the user is interested in. Lots of information exists on that single page, yet the end user's view is a short, uncluttered page that quickly summons an item's details with sub-second response.

Color Coding

Color coding is all about exploiting our natural ability to filter information. One can so quickly "parse" and comprehend a fairly information-heavy page if that page were color-coded. There are many issues to address regarding color coding such as exploiting culturally or socially accepted conventions such as the color red implying an error or danger for example.

Legends

Again, this sample is about making information available to the end user when requested, and yet not requiring the screen "real estate" for it.

Tabbed Panes

In this case, we're exposing (or hiding) information by category.

Dynamic Tables

Another mechanism of filtering out information not belonging to a specific category. In this case, the structure of the information is tabular.

Trees

Finally, the trees sample, which makes the branch nodes dynamically expandable is more of the same: hiding information that the user is not interested in, enabling the end user's locus of attention on a portion of the tree.

What's really striking here is that all these features have the same common thread and solve the same general problem: that of distilling large amounts of content to help end users maintain their locus of attention. These are all good things for web applications, and begin to make them feel a little more like desktop applications.