[Usability]one-persion usability study

[Sunnanvind Fenderson <sunnanvind fenderson com>]

I'm playing with gnome2 and here's some things I've come up with so
far:

When a program (gnome-terminal, in this case), is made full screen
from within itself, and I reach up for the menu, I have to stop before
I hit the edge because if I do, the gnome menu panel appears and
covers the terminals menu. Gah.

Oh, and about Fitts law with regard to the tasklist - it works when
the task list is in the menu panel! I could easily hit the buttons by
just reaching for the top of the screen. That's weird. It still
doesn't work at the bottom of the screen, though. Fitts law works for
well launchers, but not for the workspace switcher, or Wanda, the
gnome fish, or the clock, or the email notifying applet.

--

I ran into annoyances with gnome-terminals default keybindings
(pressed alt-f for readline's "move-forward-word" function gave me a
menu). This was solvable by the "edit keybindings dialog", but:

Here's how I would like it to work by default: pressing alt does
nothing (so people can use things like "alt-f"), but releasing alt
(*if no other key was pressed*) activates the menubar and makes the
mnemonics visible. Now, with the menubar active, the user should be
able to navigate the menu with arrow keys or with mnemonics.

The gnome-terminal version 1.9.6  I tried was like this:

 1) The mnemonics were useless when I were navigating the menus with
    the arrows (from F10 or from clicking once on a menu) if the mouse
    hadn't hovered over at least one menu option.

 2) The mnemonics were always visible, even when they weren't
    active. This makes the menus harder to read.

 3) When I pressed alt-f, both the mnemonics and the arrow keys worked
    (good) but I couldn't go right or left to other menus.
    
 4) Toggling the "disabling mnemonics" option also toggles the sorta
    unrelated option right beneath it. "Neat" I thought at first, but
    it soon became annoying.

 5) I couldn't figure out how to actually edit the keybindings in the
    keybinding-editor.

While I consider the above quirks to be warts, here follows an idea 
that's not meant to remedy something that's bad, but just make a good
thing better:

The "file -> new window" menu item is a submenu, but if there's only
one profile created, it doesn't have to be this way. How about just
making it a normal menu item (pointing to the one available profile)
in those cases? The same goes for "file -> new tab" of course.

--
--

Something different - this is an old, often nagged about item - I like
to have the menubar at the top of the screen, even for the apps, like
that old PARC wimp gui, and like Mac OS. It could be argued about
whether this should be the default or not, but since we're already
*having* some kind of menubar at the top of the screen, I think we
might as well go full mac OS style. One of my friends found a hack for
Windows XP that does this, as well, so it's finding it's way into all
GUIs.

KDE has this available as an option (when last I checked, which was
when kde 2 just was out) and it seemed to do it by having an xclient
"menu program" for every program, and putting the one belonging to the
active program at the top. I guess. I never read the code, but it
seemed something like that.

Maybe it could be done by having a sort of "menu server" in the menu
panel (or as a panel applet) that the gtk2-using xclients would
update? (And if it were visible, they would hide their own menus.) Or
something.

Or it could be done any other way. It's just that having a menu at the
top AND in every program is very crackrock. And unfittsy. And it
wastes screen space.

More crackrockitude: I notice that there are many programs with tabs,
like gnome-terminal and galeon. Shouldn't this be built into the
window manager instead? Like with fluxbox or pwm. I mean, if it's such
a big need that every one wants it...

Especially now in these gconf/metacity integration days, where we're
moving towards a future that more and more can integrates gnome apps
with the window manager...

---

Here's a little UI-snafu I found: I created a panel and put three
launchers on it, and I removed those hideous hide-buttons - now I
couldn't right click on the panel to add more launchers, just right
click on the launchers themselves! Danger. I can't easily change the
panel, I can't move it, add applets (except by dragging from other
panels), et cetera. In gnome 1.4, if I remember correctly, the panel
right-click-menu was available as a submenu to some (all?) applets,
including launchers. Though, I guess I'll just file a bug against this
(were?).

Finally, on configurability: a lot of the options on panel
configuration have disappeared (or have they just moved to gconf? If
so, ignore this complaint). Will they return? I really, really adore
gnome's new "spartan" look, it's much, much simpler to learn (I
figure). I'm glad to see that it's a far cry from the originals'
CDE-like default potpurri of launchers and foot-menus.

My view on UI simplicity is - try to have as good and simple defaults
as possible, but allow as much as possible to be reconfigured, while
never throwing this reconfigurability in the users faces.

Bottom line (in spite of all my whining (sorry)) is: I love it. I
really like the autoapplying dialogs (that's a big usability plus),
and well, the whole underlying philosophy. All my old problems with
gnome1 (bad keyboardability, cluttered default desktop, i18n problems)
is going away, along with problems I didn't even think of (like
auto-applying (I did ponder on the problem (how to best display
apply/OK/dialogs), but not the solution)). It seems also much faster
and less flickery.

Well, I'll keep on exploring/testing gnome2 now. I'm curious to see
the new Nautilus, the new control center, and especially to finally
see the fabled gconf.

I hope this isn't super-uninteresting. I'm new, so...

Sunnanvind