Conference noted::mswindows

4718.0. "consistency vs performance" by CPEEDY::BRADLEY (Chuck Bradley) Tue Feb 18 1997 17:53

I have a question about the balance between consistency of the
user interface and the convenience and performance of the user.

I've searched for a better place for this, but did not find any.
Moderator, feel free to move this.

I'm building an application that will initially be used by one person
or a few that I can train.  Eventually it might be used by many 
strangers.

The application includes a relational database as the back end.
Most of the application will definitely have the look and feel of
a normal windows application. Occasionally, the user will do what
is usually called database maintenance. I expect the maintenance will
be about 10% of the operations for a while and drop to about 1%
after a year or two. The complication is that the maintenance
will probably come in a bunch of perhaps 10 to 100 operations.

The database contains things and categories. Things can be in
one or more categories. Categories can be in one or more categories.
Abstractly, there is an acyclic directed graph with with two kinds of
nodes, and the things can only be leaf nodes.

For example, the thing roofing nails in 1 lb box can be in the
hierarchy of categories:
hardware
  fasteners
    nails
      rustproof
	galvanized
	  roofing nails

and in the categories reminders
			"things to take to Bob's"

and in roofing supplies.   caviar might be under food and under bribes.

I expect the organization to be mostly hierarchical, perhaps 75-95%.

Hang on.  I'm almost to the problem.  I need operations to create,
delete, change a thing. Ditto for a category.  I need to add a
thing to a category, and remove it. Ditto for categories in categories.
There will be about a dozen different maintenance operations.

Normally, this would be done by cascading menus.  It is easy and
straightforward.  Up pops a window with a browser for the categories
and a list for the things. In some cases there is a blank or two to
fill in.  Finally, the user clicks on OK or Cancel.

Each of the windows looks very much like the others.  I can tailor 
a general window at display time to reduce the programming maintenance 
if the users ever want them all changed.  That is not the problem.

I think I can cache the data so the window will be displayed quickly.
That is not the problem.

I'm bothered by the poor user seeing the window disappear,
going throught the same series of menus, and seeing essentially
the same window reappear.

Another approach would have maintenace as a menu item, and then one
window to do all maintenance.  It has a browser for categories,
a list box for things, a few boxes for typing in or remembering
a selection, and a bunch of buttons, one for each operation, and 
another to close the window.  This avoids all the mousing around
and the flicker, but it is an unusual looking window, and the
number of buttons might be intimidating.

If any of you have any insights on the problem, I'd like to see them.
How would you make the tradeoff?  Thanks in advance.

Hi Chuck,

I'd think you could get good mileage from an arrangement like the NT
Registry.  Your main window has a vertical splitter; the left side shows
a hierarchy and the right side shows values.  The hierarchy would have
collapsable branches and navigating would be fairly intuitive.

Beyond that you could put a horizontal splitter on the hierarchy side
so that you could browse and still have an item of interest visible. This
would make it easy to copy caviar from Food to Bribe.

The Win95 model of leftmouse=do and rightmouse=configure would apply.

Good luck,
Chuck

re .1, -< the registry? >-

Thanks for the suggestion.  I'll take a look at the registry.

I was thinking of only showing one level of the orgainization in
the list window of a category browser, and accumulate the various
categories passed through to get there in another window.
The splitters you suggest might be a nice extra touch.

Do you think the multiple command buttons will be preferred by
the users?