OT: Mark made my day!

Eric Dunbar eric.dunbar at gmail.com
Sun Apr 17 21:43:24 CDT 2005

On 4/12/05, Cameron Hutchison <camh+ubuntu at xdna> wrote:
> Once upon a time Thom Holwerda said...
> > > 1. I disagree with this and happen to dislike macos style of menus. I
> > > also question there overall usablity (a bigger issue)
> >
> > Well, I happen to agree with him here for the full 100%. I've never been
> > fond of the
> > "every-window-needs-to-have-a-menubar-for-no-reason-other-than-it's-
> > the-current-paradigm-whether-it's-the-right-paradigm-or-not" ;).
> One problem with the menu-bar-at-the-top-of-the-screen paradigm is it
> conflicts with a standard and common focus model that many X window
> managers use - focus follows mouse. If you need to pass over other
> windows to get to the menubar, the application for which you want to use
> the menubar will lose focus and the menubar will change.

"Just because that's the way it's always been done" is a really bad
idea for keeping something.

The menu-bar-at-top is the undisputed champion of menu bars for the
majority (perhaps even vast majority) of computer users. Because <ta
da> it uses a *fixed* target *and* it uses the *edge* of the screen.
Occasionally you see other interface elements use the fixed target,
edge-of-screen rule (most visibly the GNOME toolbar and Windows Start
Menu). And, when it's used it makes mousing around the screen a much
more efficient operation.

This is a GUI design problem that is beyond the scope of the Ubuntu
designers for now (it's a serious problem in GUI design but Canonical
has bigger fish to fry since "it works" (albeit less than optimally)
and there are lots of things that aren't anywhere near "it works"
(even if less than optimally)).

When I see Windows users "use" that GUI at work, I *consistently* see
successful mouse use with the Start menu and the task switcher, and
consistent *failures* to select menus on the first attempt (resulting
in frustration) because menu-in-window offers a randomly located
target (if not maximised) and a poor target if maximised (because it
is not at the edge of the screen).

> Having used both click-to-focus and focus-follows-mouse, I find the
> latter to be more useable and efficient. Click-to-focus also has the
> problem of being modal. That first click in a window can have different
> behaviour to a second click in exactly the same spot, depending on where
> the focus is. Being a focus-follows-mouse person for most of my GUI
> experience, I find click-to-focus unnerving - I always have to find a
> benign spot to click when I want to change focus due to the cognitive
> dissonance caused by clicking on something but have it do nothing.

Focus-follows-mouse is a "niche" market which will never catch on
simply because it adds too much clutter to the computer using
experience. And, the "exception" or "niche" should never be that which
drives GUI design.

Please note, I am not, nor will I ever advocate the "niche" design NOT
happen or be STOPPED. I merely argue that default(s) (design) must be
targeted at the "lowest common denominator" OR at the "largest user
group". The bulk of users will never set their preferences or install
new software, EVEN ON LINUX. This is what OS designers in the case of
Ubuntu are apparently targeting, and thus defaults must be sensible
and usable by as many as possible -- an "advanced-user" (like someone
who uses focus-follows-mouse or uses more than a three button mouse)
will change defaults anyway. GUI and OS design should be about making
the lives of the majority of users as easy as possible. What a
minority do with their computers should not be the concern of

For example, most people will not ever use focus-follows-mouse and,
thus, focus-follows-mouse should never be default. Likewise, most
people (NOT ALL) are ill-served by menu-in-window, and, thus it ought
NOT be the default. If desired, fans of these paradigms ought to be
able to turn them on, BUT, since they hinder most other users they
should not be the default.

The way I work with mice would drive most people nuts -- I'd love it
if I didn't have to configure Linux to do the things I want it to do,
BUT if that were the case, few other people would enjoy the

> I'm not arguing, just presenting another point of view.

Not arguing either ;)... Just pointing out the reasons (which, BTW,
are backed by extensive research into the merits of menu-in-window vs.
menu-at-top (m.a.t. wins hands down)) why menu-at-top is the better
paradigm, even if that's not "the way it's always been [in the Windows

There's one situation I can see *some* utility for menu-in-window and
that's in a mega-, multi-screen situation... but, even there it seems
like Mac users aren't poorly served by menu-at-top (you've still got a
fixed target that never moves).

Although, even then I'm not sure since I NEVER, and I mean NEVER see
Windows users use non-minimised windows at work -- it's simply too
complex a task to try to click-on and navigate menus in a random
location on the screen.

I myself find that I prefer to use the alt key to navigate menus in
non-maximised windows on Windows computers than fight with their
poorly designed menu-in-window system (and, I'm more computer-literate
and interface-use capable than the overwhelming majority of my
Windows-only peers (if you'll pardon my modesty :) :) :).

Granted, the menu-at-top paradigm poses its own problems in that the
menu at the top of the screen does not necessarily belong to the
window the user sees. (although, I see this happening to Windows-only
users on Windows computers so it might simply be something about the
typical Windows user <evil grin> ;-) However, this is a relatively
minor problem since my experience is that people generally figure out
what's going on fairly quickly.

Anyway, given that we've seen Microslop use their muscle power to sell
poor software for twenty years (DOS was pretty damn bad from a user's
POV) I'm not surprised that we're left with the legacy of their poor
design decisions (the best solution/product does not necessarily mean
it's the most popular solution/product).


More information about the ubuntu-devel mailing list