Trees, menu commands, and UI design?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Mike Murphy wonders: <<We've been encouraging our developers to use tree
controls to represent data structure. When a user 
clicks a tree node, the appropriate fields appear on the window. For
example, if a user clicks the Contact node, the address, phone, e-mail, etc.
fields appear to the right of the tree.  The user can edit these fields. The
user can also right-click tree nodes to see a menu of commands appropriate
for a given node, including deleting the given node and adding sub-nodes.>>

This approach makes sense because it's immediately familiar to anyone who's
used Windows Explorer or similar hierarchical directory structures. It also
follows the approach "select the object you want to work on, then work on
it", which has been adopted by most modern software (e.g., "select text,
then copy, then select position of destination, then paste").

<<My manager showed me a custom web application that implements a tree
control in a different way. The top level nodes contain what you might
normally see on a menu bar: Enter Data, Validate Data, Print Reports, Help.
The sub-nodes under Enter Data are built in a typical representation of the
data structure. For example the Contact node would appear here. This 
implementation was a bit of a mental speed bump for me at first because it
gives the tree control a somewhat "mixed use" feel: a data structure
metaphor inside a menu of commands metaphor.>>

This approach sounds almost like a wizard, and has the advantage of being
more task based ("I'll decide what I want to do first, then I'll actually go
through the steps to do it). Although it might actually prove to be a
superior approach once users learn the metaphor, it doesn't follow the
familiar conventions I noted above, and that's probably why it poses the
"speed bump" you reported. That might be easy enough to address through
documentation, but you'd want some convincing evidence that the newer
approach really does offer benefits before adopting it.

As well, if users have already learned the other approach, you shouldn't
switch interfaces on them in midstream. One compromise might be to offer
them both views of their data: the classical view (based on the data
objects) and a new mode based on the tasks. If you track user behavior over
time, you may find a clear preference for one interface, and switch entirely
to that interface in future, but that requires a lot more developer time and
might be a difficult sell.

<<you could rename the Contact node in my first example the Update Contact
Information node.>>

But then you've got a mixed or inconsistent interface metaphor: if the node
represents the data structure, then naming it based on the task is
confusing. Would this pose serious problems for users of the product?
Perhaps not; this might be something easily learned and might have no
implications for other uses of the software. The problem with such
inconsistent metaphors is that they sometimes have unforseen implications.

The classic example of this involves the trash icon used by both Mac and
Windows systems; in the original Mac software, the trash bin got emptied
when you shut down the computer (thereby confounding users who thought the
trash would remain intact until someone specifically threw it out), whereas
the Windows recycle bin doesn't seem to store all deleted files or
permanently store all files that it does contain (thereby confounding people
who look for certain deleted files in the bin or who expect files already in
the bin to remain there indefinitely). Metaphors are tricky beasts...

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada 
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"Any sufficiently advanced technology is indistinguishable from a
personality, and an obnoxious one at that."--Kim Roper

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.