10 Nov 2002
Sun, 10 Nov 2002
More on Web/GUI conundrum
Russell Beattie continues the thread on the Web/GUI interface design difficulties:
So here's my summary of what I'm thinking the way to design UIs are:
1. Document centric
2. No dialog boxes or "hidden" options
3. Able to describe any point in the application in a hierarchical manner
4. Minimal widgets
5. Minimal menu items
6. Data not tied to UI
7. Specific entry and exit points
No dialog boxes? Are the compromises worth it? If I don't have dialog boxes, the implication is that 1) I've got to partition the available screen real estate to acccommodate the dialog interaction, ie. much the way an IDE uses object inspectors to display and change characteristics of an object, or 2) I've got to have the main window be monopolized by the dialog interaction, like the web, or even worse... 3) I'm going to paint half the user interface off of the screen and force a scroll to discover navigation (my personal favorite in web apps) ;-> Keep in mind, those latter two options make document-centricity difficult because the dialog interaction gets mingled with the document.
Able to describe any point in the application in a hierarchical manner? While Randy Pausch at CMU's HCII lab will tell you that Bill Gates has ensured that everybody is comfortable with hierarchy, I still believe there's a time to flatten the hierarchy. The canonical example? Google. I think I heard Nielsen say that search is becoming the defacto navigation method; moving that into the GUI space is something that could yield real improvement.
Minimal widgets? While I'll admit that widget hackery has become an art-form practiced by a wide array of UI engineers, and that there's a point of diminishing returns on usability (discoverability?) when the number of UI widgets gets beyond a certain basic set, I still believe that the set in use on the web is not enough.
I think I understand what you're trying to get at but you have to watch that you don't throw the baby out with the bathwater. There are entire classes of problems that cannot be solved without some of these widgets.
For instance, how do you represent a multi-select list view on the web? You hack together your own table with checkbox for the item selection. That's certainly more intuitive than windows list view mouse semantics which conist of single select with a left click and ctrl and shift modifiers meaning add to selection and select range, respectively. However, with the web you have none of that. This leads every designer to invent their own table/checkbox row selection semantics and that's just for the single select case.
What about multi-select? Most designers implement a mother of all checkboxes checkbox in the checkbox column's title header which means select all. Random group selections are possible since you can select more than one checkbox but range selections are not. Don't think you need range selection? Think again. I've been designing GUI interfaces for over 10 years and I haven't worked on a single application that didn't require range selection for some collection of objects. In a list of 1000 objects, it would be painful without that capability.
Data not tied to UI? I'm not sure what you mean here. If the intended meaning is encapsulation, then I'm confused how that would impact the user interface. If the intended meaning is that you're not fond of the "data is the UI" school of design, then I'm not sure that I agree. I'll let this one go for a little clarification.
There are a couple things that I think can help with this design problem.
I've used the UI Design patterns on a variety of occasions and find them useful to clarify my thinking about interface design options in the same way that gang of four book did for the internal design of software.
A recurring theme in this discussion is that of designing for existing use precedent vs. naivete. That's a tough balance to strike. I believe Nielsen's view in the context of web design is that you should go with the precedent, if it's widely implemented on major sites, even if the resulting design is suboptimal.
A critical distinction may be that novice users (most users?) don't discern between memory and disk operations, ie. what is running and what is not. To the extent that the browser's page navigation model masks this distinction, it's useful. That's probably one of the advantages of homebase desktop. It's also the typical model that PDA's use. Why would a user care to distinguish? Because resources are limited.
What's needed is a stateless model that allows users to launch applications without worrying about what's running and what's not. The problem with existing desktop models is that the apps generally have state that will be lost if an app is closed prematurely which leads to the hideous save/close/cancel dialogs. Stateless and stateful applications are really the essence of the web/desktop dichotomy. Granted, there are examples that go against the grain, but they are in the minority.
In the long-term, it's my general view and hope that the web will remain intact for what it's really good at - displaying rich hyperlinked documents. I'd like to see applications that require database backends move toward a web services architecture which permits a variety of rich interface options beyond the browser's rather limited pallette. Fortunately, the tools, wireless adoption, and the proliferation of laptops are encouraging this migration.
In the context of the work that I do, we've been moving in this direction for some time, using SOAP interfaces that support HTTP GET and POST to provide a single set of interfaces that are easily addressable from both browser-centric applications and rich GUI applications. Then, the approach can be tailored to the application, and install/config headaches with rich GUI apps go down over time with approaches like java web start, .net, and XWT.
By the way, it's not a widely held view that user's experience with online banking is as smooth as your mother's. :)
Posted at: 08:27 | permalink
