Skip navigation

Hierarchical Interaction

One of the major problems encountered when building large software applications for corporate users is that the process never seems to be optimized to include the actual users.

So management finally gives the go ahead to build a new application for the back office people. Funding has been appropriated and a delivery date has been calculated to coincide with the budget. The project manager calls a kickoff meeting to inform everyone how important this application is to the company but unfortunately the schedule is very aggressive so we must work really hard to get this one right. All the new team members introduce themselves and are look forward to making a positive contribution to the effort. Soon after, the business analysts are busy in meetings with the users to discuss what functions the new application must perform. “Well”, they say, “it must automatically generate reports for all our different customers and we’d like to be able to look up the info for a particular customer, oh, and also give us estimates for the next three months”. The BA’s dutifully put together a functional spec and hand it over to the programming team. The programmers look over the spec and decide that yeah, that’s more or less what we already started to build and continue building a really great system for storing the customer data and crunching numbers to meet the requirements. The programmers make it super flexible and generic so it can handle any future customer accounts and all the possible edge cases they can think of.

Then after a couple of months the project manager has to report to management on this quarters milestones so asks “How’s the application coming along? Are we still on schedule?” The lead programmer says everything’s going great - a few little snags here and there but nothing we can’t handle. “Can you show me what you’ve got so far?” Well, we don’t have the UI completely done yet. Jim did the website for his home owners association and says the UI can’t be that much different since it runs in a browser. Here, take a look... “Umm, I think it would be better if Jim kept working on the stored procedures - that’s more his field of expertise. Tell you what, I’ll put in a request to HR to hire a UI person and see if we can’t get a better look and feel on the application”.

Despairingly, this kind of process goes on all the time. It’s not that there is a lack of talent, leadership or management - there really isn’t. It’s a result of an eagerness to jump right in a get it done because we’re on a schedule here. Interaction design? Usability? “Oh, we don’t have time for that stuff and it would be wasted on our stupid users anyway”. Well what if the application was being designed for neural surgeons or Supreme Court judges or NASA mission planners? The easier you make it for them to do their jobs and meet their goals the better off the company is going to be. And then, when the system is finally deployed, what do you think the users are more likely to be thinking about?

Users don’t care what the technology is or that you used some cool and interesting object oriented widget thingy. They just want to get their job done on time so they can take their kid to his baseball game.

But doesn’t it make sense to let the programmers build the system, including the UI? After all, they know how all this stuff works, right? Sure, they can build it; just don’t let them anywhere near designing the UI. Programmers are very comfortable writing software and some are extremely proficient at it. But many programmers never even meet the users and that is why interaction designers can make such a difference to a project. It’s not just look and feel that’s required; the system behavior must be defined for the users and programmers tend to design systems for how programmers would use the system.

A good example is the hierarchical menu system. Programmers love these things. Your mother-in-law hates them. Why? Well, because to a programmer, it makes perfect sense to be able to organize and access data in the logical manner that the data is actually stored in. Another example is the Windows Explorer. I was trying to explain the Windows file structure to someone the other day, and it occurred to me that there is really no need for most end users to be even aware of such a thing. I mean really, why do you need to know that your files are scattered around a disk drive, hiding in folders within folders like some Russian matryoshka? I opened the Windows Explorer to show how the files are organized and of course, that glazed eyes expression appeared on her face, instantly betraying her understanding of the structure. “Why can’t I just put my documents on the desktop where I can see them?” she asked.

Ah, you say, but isn’t Explorer a metaphor for the files and folders inside a filing cabinet? Not really. Take a look inside your filing cabinet and I bet you don’t see too many folders inside folders. Plenty of documents inside a single folder though.

Suppose you want to add an entry to your hosts file in Windows to redirect some advertiser to look on your localhost for its annoying advertisement instead of its own site, thwarting its efforts to display the ad on a web page. OK, go ahead and open Windows Explorer and navigate to the file called ‘hosts’... Or suppose you are software developer and you want to find out about, say, the CSS borderColor attribute for a web application you are developing. You go to the Microsoft MSDN Library site and are presented with this monstrosity of a hierarchical menu [assuming you use IE6. Netscape 7 and Opera 7 are sniffed out and simply don't work correctly]. OK, go ahead and navigate the menu until you find the information about the CSS borderColor attribute...

MSDN Library menu

The problem is that hierarchical menus do not allow you to locate information very easily even when you know exactly where the item of interest is located. You still need to expand and scroll, expand and scroll, expand and scroll until you get to the item. And if you forget which of the branches to expand, well it just gets way too confusing. I tried one of these controls in an application for a client once, and their users absolutely detested it. The account manager needed to locate information about a customer while on the phone with that customer and complained that it took far too long to find the information. The hierarchical menu is exactly the wrong control for that situation.

So what is the solution? Well, there are 2 options. Organize the data alphabetically, like this.

MSDN Internet Index

So you would click on ‘B’ then click on ‘borderColor CSS Attribute’. Or go back to the MSDN Library site and type ‘borderColor’ in the search box, but now you get to search through the search results, trying to identify the relevant result. This is why search on the desktop is going to be huge in both Mac OSX Tiger (Spotlight) and Microsoft Longhorn (WinFS).

June 2004