Interaction Design Section   Living Section   About Bruce Tognazzini

Scaling Information Access

Hi Tog,

I am currently working on an HTML forms-based interface to configure an e-mail server. By filling out and submitting forms you can create and edit e-mail accounts and distribution lists, etc.

I think the quintessential desktop application approach would be to show a list of e-mail accounts on the main window. A user would browse the list, double-clicking on different e-mail accounts to see the properties of that user and edit them if desired.

Ironically I have found that this type of browsing is not possible with a web browser UI. Our e-mail system will have tens of thousands of users on one server. If you send out a list of users that large (along with the other data that make up a web page) over 28.8, you have a big time delay problem.

For now our solution is to NOT show any users on the main web page. Rather we force users to do a search for the user they are interested in, and they can get access to the user's properties from the search results.

Is there a better way?
-Patrick
---------------------------------------------------------------------
Patrick G. Curran User Interface Designer
patrick@Eng.Sun.COM Sun Microsystems -- Menlo Park, CA

Perhaps one of you knows a better answer, but I don't. Not over 28.8, anyway. The best you can do, Patrick, is to make it easy for people to learn, understand, and use the search mechanism, and to make it easy to modify or recreate earlier results. Store previous searches in a cookie, unless security does not permit, and offer them in a pop-up menu.

On the larger issue, we seem to feel it a failure when we scale up the quantity of information one or more orders of magnitude and then can't come up with quite as clean an interface. It isn't.

Certainly, we will have better tools for searching large data spaces--agents come to mind, and so do high-speed, high-resolution, high-bandwidth networks and displays.

in the meantime, we have to do the best we can to give access to information at each scale.

I still find individual icons superior for relatively small data spaces. Depending on screen size, users can view up to 100 icons simultaneously. Of course, little is gained if each and every icon is identical, like Finder folders. However, icons can carry rich information and, in the better designed systems, remain relatively constant in location, so that users can depend on motor and spacial memory for locating repeat information.

Icons soon break down, however, when either of two conditions exist. One, there is just a lot of information, and no amount of display space is going to enable users to see either the entire informaiton space at a glance or even discrete chunks at a glance. Two, the items are compound, rather than complex. If you have 100 different applications, each with their own specific icon carrying discrete information, icons really work. If you, however, have 100 address book files, where the differentiation is purely textual, icons make little sense.

Apple came up with a great way to organize icons, several years ago, in an object with the rather plebian name of "pile." You start a pile by dropping one document icon on another. You may then continue to add icons to your heart's content. The resulting pile is easy to read: click on it and drag up and down to see thumbnails of each document instantly appear adjacent to the pile. Clean, neat, and never, of course, implemented.

When icons drop out, visible lists begin.

Visible lists (as opposed to lists held on a remote server and never shown altogether on the client) work on perhaps up to 50000 clustered items, if they are accompanied with a fast, convenient search mechanism. As the count goes up, the value of the search mechanism increases, and, by 2500 items tops, users begin working with the list as though it were a local list produced by the search--they no longer make any attempt to browse.

What ultimately limits browsing of lists is ability to scan and find things quickly. Some applications, such as Quicken, open small windows on the display that show exactly where in a file the user has scrolled even as the user holds onto the scroll bar. This can make finding, for example, a check written on August 15, 1992, amazingly simple. Microsoft Office seemingly went one better by showing outline headings as the scroll bar is scrolled, but, unfortunately, it doesn't work, because they fail to keep the heading information updated properly. When you click on the scroll bar, it is random whether that information will be available or not. After getting spanked a few times for trying, most users abandon the feature.

Search-only cuts in when conditions or design make showing the entire list impractical.

Certainly displaying a list of tens of thousands of users via a 28.8 modem is an exercise in futility. Here, given today's technology, pure search makes sense.

Pure search of a small list is easy: Type a word, press Return, and see the results. Infortunately, such searches also don't scale up. Type in "travel" at AltaVista and you are likely to get hundreds of thousands of returns. So you have to get more specific. But how?

Perhaps the most crying need on the web today is standards for search criteria. When you get to a new website and they ask you to search, are they going to respect boolean logic? If so, do they require all ands and ors to be upper case? Lower case? Do they, instead, accept Regular Expressions (which, if you haven't come across them, are anything but)? Do they not accept anything, and, when you look for "Multimedia AND Design" cheerfully tell you they found 150 million hits for the word "and"? And how do you look for a word just in the HTML title, rather than the body, etc., etc., etc.

This stuff should be standardized and taught in every school around the world. It is as fundamental a skill as reading and writing.

In the meantime, researchers need to press on with solutions that will obviate the need for such crude methodology. Agents are a tough nut to crack, but we need to keep hammering on them. I proposed in Tog on Software Design that we put a lot more effort into adding a human element to the web, by hiring actual people to build indexes, not relative importance, offer portals. I showed, in the opening shot of Julie's office in Starfire, a rich, 3-D information space modelled after a city, designed for the user to sweep down into it to browse among the various information "buildings." Novel approaches are now beginning to crawl out of the lab, but a lot more works needs to be done.

What design issues are bothering you, and how can I help? Write me at:

tog

Don't miss the next action-packed column! Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com. return to top

Contact Us:  Bruce Tognazzini   Copyright Bruce Tognazzini.  All Rights Reserved