submenus & hiearchies (was the popup problem in os9)
bill at igame3d.com
Sun Oct 24 00:39:59 CDT 2004
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
> Because submenus add complexity to the interface and are physically
> difficult to use, you should use them only when you have more menus
> 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
> it its own menu.
Aaah, what do they know?
They did AWAY with that particular limitation in OS 8.6 (thats almost a
They've added so many irritating UI flaws in the past few years users
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
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
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
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
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
> 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
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.
More information about the use-livecode