See below:

On Dec 12, 2004, at 12:34 PM, Tim Rowledge wrote:

> 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...

Thanks for well articulated arguments.  Rather than just spouting 
opinion, you support it with your reasoning, and point out why the old 
arguments no longer apply.  I agree that a menu bar is getting old and 
hard to use.  My current monitor is 2560x1600!  Add to that that the 
mouse could be on the second monitor, and It can take seconds to just 
get the mouse in the general neighborhood of the menu bar. And when the 
window is offset from the menus by that much, it creates odd problems 
with split attention.  You can not see what the menu item is operating 
on when you are selecting the menu item.

>
>> 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.
>

Even better would be SmartClassWithNewFeaturesAndFasterThanTimIsUsedTo 
as a new editor class.

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