submenus & hiearchies (was the popup problem in os9)

[william griffin]

Wherein Bill rants On the subject of submenu limits, hiearchies,  
Apple's BS..erHIG guidelines.
>
> Date: Sat, 23 Oct 2004 17:41:14 -0700
> From: Richard Gaskin <ambassador at fourthworld.com>
> There's a reason Apple built that limitation into the OS -- from the  
> HIG:
> ----------------
> Because submenus add complexity to the interface and are physically  
> more
> difficult to use, you should use them only when you have more menus  
> than
> fit in the menu bar or for closely related commands. Use only one level
> of submenus. If a submenu contains more than five items, consider  
> giving
> it its own menu.
>
> <http://developer.apple.com/documentation/UserExperience/Conceptual/ 
> OSXHIGuidelines/index.html>
> ----------------
>
Aaah, what do they know?
They did AWAY with that particular limitation in OS 8.6 (thats almost a  
decade ago)

They've added so many irritating UI flaws in the past few years users  
and developers
are running around hacking Apples mistakes off the interface tree like  
a bug infestation.
There's plenty of examples where they break there own rules or  
suggestions, like the applescript menu, or browsing a CD of movies and  
stalling the computer for  minute while the selected file attempts to  
play in the wretched list view (how counter-productive). Look in your  
Application Services menu how many submenus? Right more than five, well  
it is in mine.

Photoshops filter menu has broken that submenu "suggestion" since 1991,  
and Abobe rules the UI universe (except on Sundays and Holidays, or  
where prohibited by operating system deficiency or lack of three  
monitors).

Last time I downloaded the HIG it said "This document is unfinished",  
to me that said "we realized we are totally full of BS and can't come  
up with anymore rules to make your life hell"

One of Apples best apps ever is Final Cut Pro, and it works and looks  
like NO other Apple application, because it was developed originally on  
Windows. They should have followed the theme and made Final Desktop  
Pro, and Final Developer Pro, oh yeah!

Following HIG my menu bar would look something like this

ð Application  File  Edit  Import  Levels  Make  Import  Mesh  Scripts   
Console  Windows  Help
(change to what is it, 12 point or 14 point type for full effect)

The File menu (which deals with files) would have all of maybe 4 lines  
in it
The Import Menu (which deals with files) would have 110 to infinite  
submenus in it
The Levels Menu (which deals with files) would have 110 to infinite  
submenus in it (or lines depending on how I use it)
The Make Menu (which deals with files) would have 100 to infinite lines  
in it
The Scripts Menu (which deals with files) would have 110 to infinite  
submenus in it
The Console Menu (which was made because menuMode bug broke my buttons  
in the stack) has three submenus
The Mesh Menu has 4 submenus

Whats the problem with all that? A massive spread of menu with  
redundant items (dealing with "File")  that are only relevant to the  
user about 3% to 9% of the time they are using the application per  
session, often for one hit selections (unlike say the edit menu where  
you might use copy/paste/undo 100 times a session, or the mesh menu  
where you might need to repeat some mesh actions two dozen times).
And there is zero room for menu growth should I go on a features  
bonanza (again).\

 From the HIG "or for closely related commands"...File Input items are  
about as close as you can get.

The desired UI is click the File menu, mouse over to the thing you want  
(Level,Make,Script,Import), view nice alphabetical list of either files  
or subdirectories > mouseover to selection > pick thing > RESULTS!
All that nicely where it belongs...under FILE. All with TWO CLICKS.
Thats efficient, not complicated or difficult to maneuver.

Compare to using file dialogue, my stomach rolls just thinking of it:
Open file dialogue, dig many many directories to your desired file,  
view any number of files and folders that have nothing at all to do  
with the desired result, click the file, click open. Repeat.
Oh how I loathe open/save dialogues in OS X. (remember when you could  
hit a key on the keyboard, and it selected the file with that  
character? those were the good old days)

> I'm generally first in line to blow off OS-specific edicts, but given  
> my
> own frustration with submenus I wonder if a hierarchical browser
> (multi-list perhaps, like the Finder's NeXT-style view) would be a
> smoother ride for the user....
>
You don't mean column view do you? *reaches for barf bag*
(oh damn this one is full after dealing with Applescript Library all  
day)

UI revision #3 started on that route, and it quickly became obvious  
that life became a "click, click click click, damn where is that thing  
I want click click" --living hell. The Multi-List takes up a lot more  
room and user work than its worth.

Finder's  list view coupled with drag and drop would be a desired  
method,( think XCODE or CodeWarrior  meets Ray Dream Studio meets Final  
Cut Pro), although its cluttersome with so many options/folders/ files,  
and many more clicks to get to the desired one shot option.

There is NO standard method or function for making this (hierarchal  
list view) efficiently that I know of.
I created something similiar a long while back, took me forever, and  
then it exposed just how inefficient the method was, trying to fit  
several hundred files in as small as space as possible, at least from  
my limited knowledge of rev. Therein lies a problem, the user knowledge  
level directly limits the user from being able to make a UI that  
replicates methods used by the OS and dozens of programs.

It amazes me that after 20 years of file browser list view, there is no  
simple method for viewing data this way. To me it seems there should be  
some control structure, like a button of kind disclosure, and you set  
the toggleDown data of that button to some data, and when you toggle  
down it exposes the data, and fits everything in the list nicely and  
cleanly, and when you click, double click or drag some content of that  
data, you can track what disclosure hierarchy that data belongs to  
without having to script every last thing.
For instance, 1,000 sub folders down I drag file A to subfolder  
500...it moves the file, no problems, no questions asked, I double  
click the file, it opens the file, no complications.

This re-invent the wheel stuff is counter-productive, and you end up  
with things like Goodyear tires or my n00b file browser, both hazardous  
to the health.

  I have,by the way, tried that XML file tree walking example and it was  
dog slow, so had to come up with my own method, which ended up, when  
all was said and done, dog slow too.

We've spent the past seven days or more just (and finally and at long  
last) creating a hierarchy
method for all the options that used to exist in several windows and  
groups of the application (now one stack to rule them all! I hope), and  
its no easy task.
Early preview : http://www.igame3d.com/igame3dhiearchyinspector.jpg

Ok thats my long winded opinionated rant for the season.
See you again in winter, when I will discuss why I  should be able to  
command the weather from a submenu, and access and change people's  
thoughts via drag and drop hierarchal lists.

Mr Bill