Hannes Hirzel <hirzel at spw.unizh.ch> wrote:

> Yes, you are right absolutely. I should have written 'better usability 
> for beginners'.

Well, yes, sorta-kinda-maybe. You can make an argument _for_ menubars
(and lots of other unpleasant things) based on familiarity for recently
introduced users, maybe even for 'commercial' apps where you want to
fit in with the host OS as if you were an ordinary program. In certain
cases this is an ovewhelmingly strong argument.

However, this isn't the same as 'its better for beginners' in my very
strong opinion. 'Better for beginners' is often the same as 'good for
everyone' [with nods to the cases where there are very different needs
- better colour rending is not likely to be a help for someone with no
vision at all] with perhaps some extra initial affordances to provide
an extra reminder about where to start.

Menubars are something I get (probably unreasonably) cross about
because the earliest version most people know is from Mac OS circa the
time of the dinosaurs. The argument used in favour of them goes
something like:-
Fitz's Law (an observation about the time to be able to hit aspot on a
screen)  says that the target should be big, and the menubar area to hit
it quite wide and very tall since we treat 'off the screen' as still
on-target.
The screen is quite small and so the distance to move is not huge.
Having a single place to look is simple to explain.

Unfortunately, this was not great as an argument even in the days of the
Mac plus. It's utter nonsense now;
screens are huge and quite often double, which means moving the cursor a long
way from your focus of attention, sometimes even to another physical screen.
moving from your original point to a screen-top menu area is a _polar_
coordinate movement, not a _cartesian_ movement thus making it harder to
actually hit the right place.

Oh, and dear old microsoft really ruined the argument by having a
menubar per window that makes the menu area target both small and often
cluttered with multiple rows of menus/buttons/doohickeys. Though at
least the distance to travel can be less.

Smalltalk systems have had it much better since at least the era when
the strong and weak forces were unified. A menu that pops-up in the
place where you already have your attention involves almost no movement
and can be created to list the logical things to do related to that
focus of attention. I have to say that Squeak has done a pretty good
job of ruining that particular advantage by lousy menu layout and
innapropriate menu entries.

Did I say I was a bit obsessive about this issue? Well, I warned you...

> The additions should therefore be on by default but
> with a preference for disabeling them. This for people like you who are 
> used to the Smalltalk IDE GUI for 2 (2.5?, 3?) decades.
Umm, a long time, whatever it is. An important note I want to add about
preferences for this sort of thing is how they are implemented. Having
lots of methods with 'Preferences dumbOldWayForTim ifTrue:' scattered
around isn't the efficient way to do it. I claim that the smart
approach is to implement DumbOldTextEditorForTim as a class/subclass
and use the preferences to choose which for of texteditor to use. It
makes for cleaner code, faster code and more factored code. 


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: COMB: Straighten Wires