Re: Review of Keybindings [Re: Dia's user interface]

[James K.Lowden <jklowden speakeasy org>]

On 23 Apr 2002 14:33:23 -0500 "Lars Clausen" <lrclause@cs.uiuc.edu> wrote:

> On Tue, 23 Apr 2002, James K. Lowden wrote:
> > When I start a program, the last thing I want is hints about how to do
> > something I'm not thinking about.  It's self-important.  I want to
> > open my file or plop a few shapes onto a new one, thanks.  If I want
> > to read the docs, I'll do that.  If I have to read the docs, the UI
> > failed.
> 
> The only thing I *really* want to see in the start-up hints is mention
> of the right and middle mouse menus.  I've seen reviews of Gimp
> complaining about how little you could do because the reviewer never
> figured out the right mouse menus.  Can you think of a better way to
> indicate this?  Though perhaps the use in Windows of right mouse menus
> has made this concept well-known enough.

Lars, 

The standard answer to the "but the user has to be told..." line, as you
know, is to make it easier for her to guess.  Now that you mention it,
there are a few things that hurt Dia on an accessibility scale, as I've
outlined below.  My comments are based on 0.88.1; please disregard if
something's been changed in CVS.  

Menus

The menus on MB2 (middle) and MB3 (right) should be conveniences,
shortcuts to the main menu.  I don't know what the Gnome usability folks
have to say about that, but it doesn't matter.  The menu is the menu is
the menu: it contains the full set of options/commands to use the program.
 Feature-rich programs have big menus, oh well!  I think most
accessibility guidelines would suggest something like:

	* Duplicate the whole right button menu on the main menu.  
	* Add an "Object" menu item to the main menu, to reach the
"Properties..." dialog and any object-specific (MB2) actions.  

Granted, a bigger menu consumes screen real estate, but that's OK when
someone is getting started.  It tears off, after all, and we can toggle it
with a preference.  If the user finds the preference, we can hope she'll
have found the MB3 and MB2 menus in the meanwhile, or can guess there is
one from preference text.  

Because double-clicking is hard for some people, it shouldn't be the only
way to do anything.  The MB2 (object) menu should include a
"Properties..." item, too.  

> Though perhaps the use in Windows of right mouse menus has made this
> concept well-known enough.

Question:  Is there really any reason to distinguish between the right on
middle buttons?  MB2 doesn't do anything to the diagram, and MB3 doesn't
do anything to a shape.  We're getting one button's worth for the price of
two at the moment, as far as I can tell.  

I think more people would "guess right" if MB3 brought up the object menu
when pointing at a shape, and the diagram menu when pointing at the
canvas.  That would leave MB2 for the "Edit" menu, perhaps.  I think Open
Look or Motif or DECwindows or something worked that way.  Besides, there
are still plenty of folks with two-button mice, too.  The need to "chord"
for a basic operation is hard to guess, hard to do, and as such is an
important accessibility flaw.  

Preference Rot

After reading some of the earlier comments and Joel's book

(http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html)

I looked at Dia's preferences with new eyes.  Using Glade, I mocked up a
new preferences dialog

 http://www.SchemaMania.org/dia/noodle/dia_preferences.glade.

As you can see, I was able to reduce the size of the dialog by 3x (mostly
by using standard checkboxes and a tighter layout).  By putting everything
on one page, it's easier to see what's what, IMHO.  What do you think? 
(BTW, it's my first time using Glade.  Darned if I can get right-justified
labels to work: I want Width, Height, and Zoom to be right justified, but
Glade just refuses to display them that way.)

I dropped three preferences and made a few other changes:

1.	The Grid size is square; you can't set X and Y to different scales.  I
understand why you'd want to in a graph, but I think it's more a
hinderance in Dia. 2.	No undo level setting.  Who needs it?  Please
don't answer! :)  Anything less than infinite undo is just silly today.  A
technical shortcut would be to set it to 1000 internally.  That's close
enough to "infinite" to fool most people.  3.	"Reverse dragging selects
intersecting objects"  Huh?  

I changed "Close" to "Cancel", because "Close" should never discard
anything.  Better still, "Apply" should be greyed out unless something's
changed, and "Cancel" should be "Close" unless "Apply" is active.  That
way, you can Cancel from a dialog when changes are pending, and Close one
when they're not, and you can't Apply anything when there's nothing to
apply.  Whew!  At least "OK" is self-explanatory!

Cleanup includes dropping all the colons, removing unnecessary precision
(magnify to 88.345%, perhaps?), and using frames to collect things
together.  I left color as "colour" for the sheer exoticness of it.  ;)

I should think an experienced GTK programmer could wire up my dialog in
place of the existing one pretty easily, if I make my widgets have the
same names and respond to the same signals.  If anyone's eager to get at
it, I'll do that.  If not, well, it'll just take longer, that's all.  

Sorry for the length; I hope it's a contribution.  

Regards, 
--jkl