Re: User interface suggestions

["Blad, John Erling" <john erling blad aftenposten no>]

Time for some (ch)artworks..

This is from a GIS application I worked on some time ago.
Gess this is an orgy in misspellings and missuse of
-fix-width-*-*- whatever!

SPEED BAR
One of the implementations for an speed bar looked something
like the following. Replace icons everywhere a [*] is printed.

If something had been marked as "frequent use" then it went
into the speed bar in addition to it's usual place in the menu.

  +---------------------+
  | File Edit View      |
  +---+-----------------+
  |[*]| Paint blue      |
  |[*]| Delete          |
  |[*]| Set name        |
  |[*]| Merge           |
  |   |                 |
  |   |                 |
  +---+-----------------+

Text labels was only visible when the pointer was located in
the left column and then all labels was mapped. The text labels
overlaid the map area.

Pros&cons

  + very fast (as long as the list didn't change)
  - Lack of descriptive icons
  - Differences between users
  - Lack of good automatic algorithm as user changed "mode"
    while using the application
  - Not so good with rollerball (as dedicated keyboards)
  - The name itself created som amusing comments..

I also played around with a speedbar on the desktop, much like
the Windoze Office thing.

We tried also something similar on a horizontal toolbar. At the same
time we let the toolbar reorganize itself to fit within the window.
Our "users" didn't like it... (Actually they never used it because
they lost track of the icons/actions all the time.)

ACTION TREE
As a possible solution to the high number of defined actions
we tried a tree structure. The menubar structure could be
simplified as seldom used actions was put into the tree
structure.

  +----------------------+
  | File Edit View       |
  +------------+---------+
  |[*] Window  |         |
  | [*] Resize |         |
  |  [*] Height|         |
  |  [*] Width |         |
  | [*] Iconify|         |
  | [*] Explode|         |
  |            |         |
  +------------+---------+

Pros&cons

  + Simplifyed the menus
  + Could be tailored for special use
  + Looks nice...
  - Rater slow
  - Takes a lot of area from the rest of the application

To counteract the last it is easy to add handles to open and close
the pane. Autoclosing also helps alot. You manually open it and it
will autoclose after some time, alas you use it so seldom so why
leave it open.

In combination with the first, speed bar we got someting like
this

  +----------------------+
  | File Edit View       |
  +---+------------+-----+
  |[>]|[*] Window  |     |
  |[*]|[*] Window  |     |
  |[*]| [*] Resize |     |
  |[*]|  [*] Height|     |
  |[*]|  [*] Width |     |
  |   | [*] Iconify|     |
  |   | [*] Explode|     |
  |   |            |     |
  +----------------+-----+

When you clicked the [>] the tree list was opened, and then if
you don't continued to navigate inside the tree list it would close.

DRAG & DROP OF ACTIONS ;)
One idea I was messing with was attaching a menu in the tree widget
with options to place the selected action in the menu bar. I had some
problems with making a concise representation of "selected" vs "clicked"
as clicked would fire up the asossiated action. I belive I used rightclick
and the action right under the pointer. In Windoze I gess doubleclick
would be a prefered choice to invoke the action..
("Read my lips, no doubleclicks! Okey, okey, I remove it..")

Drag & drop would be prefered but out of reach at that point..
("Read my lips, no drag and drop! Ouch.. yess sirr! He, he..")

John