CHI 96 Workshop: HCI and the Web, Position Papers
From working on the ui design of this environment, here are some observations of the types of problems the user interface community will encounter as web-based applications become more common. I expect to be one of the few people at the workshop who has worked with Java-enhanced web pages, and that gives me a different perspective.
The browser is taking on the role of the window system. (Almost) All interactions appear within a window that has all the browser "gadgetry" surrounding it. That gadgetry takes up a lot of space, and more complex applications run into screen real estate problems. I have seen this problem solved a couple of different ways: 1) cloning browser windows to show multiple views that are needed in parallel, resulting in much less of the screen being taken up with information relevant to the application and the user's task and more being taken up with window decorations than in a traditional UI, or 2) treating the browser as if it were a terminal, giving the user tools to switch between views, but no easy way to see two different views at the same time. Neither is a particularly good solution. I expect that relatively soon someone (perhaps the gnu folks) will invent a tiling mechanism that works within a browser, effectively creating a new windowing paradigm inside the browsing window (and it will probably conflict with the paradigm of the native windowing environment.)
The tools that are provided to create user interfaces are quite impoverished -- if the entire world switches to web pages and Java for its user interfaces tomorrow, we will set user interface design back at least five years. The two problems I have encountered the most often are the lack of widgets that we have come to expect (they can be created from scratch, but that costs time, and costs the user when each application writes its own version of the widget with slightly different semantics) and great difficulty dealing with simple aesthetic issues. When I make suggestions about issues like aligning text boxes along a single vertical line so the GUI looks a little less like a ransom note, I'm generally told how hard it is to get the browser to cooperate. All those aspects of html that make it "layout independent" make it very hard for the implementer to have the fine grained control needed to make certain types of user interfaces look professionally done. This set of problems may diminish over time, as more sophisticated tools become available, but I fear that if the interaction paradigm is developed while implementers are forced to "make do", we may end up with users having expectations for interface styles that aren't easy to use.
The general style of user interfaces for web pages is a "walk up and use" interaction style. This is due to the assumption that a user can be anyone, and get to the page from anywhere. Other than a few common UI conventions, mostly relating to navigation, users are expected to have very little expertise in the use of any web-based "application". As more complex applications appear in this paradigm, the need for efficient use will be as strong as immediate use. This has become very obvious in the design of a programming environment. To take the idea to an extreme, assume that the web becomes the dominant GUI paradigm of the future, and, as some pundits are predicting, all applications become browser-based. Imagine a browser-based CAD system, using today's interaction paradigms. (No, let's not.)
One of the earliest interaction problems to show up is the difference between the "click to select, double click to operate" paradigm of many traditional GUIs, and the "click to follow link, drag to select" paradigm that is the essence of web-based user interfaces. Trying to add select and operate gestures to a browser-based user interface is often confusing to users, who seem to forget for the moment that they are in a browser, where clicking on an item is not the way to select it.
A problem that is only going to grow is the "color map chauvinism" that browser-based applications exhibit. Because a browser can tie up the entire color map with photorealistic images, applications that need only a few colors feel free, or even compelled, to be color prolifigate. In the long term, this will be solved by better display hardware, but history tells us it will be longer than any of us expects before that better hardware will be commonly available. In the meantime, applications don't tidy up after themselves correctly (because the tools make it extra work to do so), and failures due to lack of available color cells are too common, both in browsers and in other applications who had the bad fortune to be launched after the browser commandeered all the colors.
Another web issue is the need to reinvent solutions to problems that were reasonably well solved in the traditional paradigm. Internationalization and localization are issues that currently have no institutionalized solutions for web-based applications (perhaps no solutions at all). Tools to produce catalogs or the ability to modify date and number formats can be done in web-based applications, but without well-designed tools available at the toolkit level, implementers are not likely to do the work. Currently, so far as I know, there are no methods to change the contents of web pages depending on the locale the browser happens to be running in, so its not clear how implementers would provide localized pages in any case.
I believe that the WWW offers many opportunities for new and interesting user interfaces, but it offers an equal number of challenges. I hope to learn in the workshop ways a tool provider can address some of these challenges.
CHI 96 Workshop: HCI and the Web, Position Papers