Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!adobe!heaven!heaven.woodside.ca.us
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.sys.next
Subject: Re: Edit App (command-G), user interface consistency
Message-ID: <538@heaven.woodside.ca.us>
Date: 18 Jun 91 03:32:18 GMT
References: <1991Jun17.135120.242@gacvx2.gac.edu>
Sender: glenn@heaven.woodside.ca.us
Lines: 109

Christopher Kane writes

> The importance of interface standards can be illustrated easily by looking  
> at the uses to which command-P is put.  In Librarian, it's Preferences..., in  
> Edit, it's Page Layout... (IMHO, what it should be), in NewsGrazer, it's New  
> Post..., and there are probably more examples.  Just think what a mess things  
> would be if everyone choosed there own key equiv. for Save.

I agree with all of this whole-heartedly.

As a developer, I have to say that it's difficult to keep track of all the
menu equivalents and to keep yourself from assigning the same letter to
two or more menu items.  Interface Builder could certainly help with this,
although the run-time binding problem is acknowledged.

The user interface guidelines tread a fine line between over-prescribing
(reserving so many key equivalents that there are none left over for your
own unique features) and under-prescribing, which leads to some doubling
up and unfortunate collisions.  I think they've done a pretty good job of
treading that line.  They are very tough about the important ones (printing,
saving, copy, cut, paste, bold, italic, new, open, revert, and so on), while
providing good guidelines for the others.  The problem comes with multiple
applications from multiple vendors, each of which is doing the
"most intuitive" thing for their product.

The only real solution, I believe, is to have excellent support for the
user to edit these for his or her own applications and system, as well
as providing good support tools for developers to come as close as possible
to doing the right thing.  The current support for editing key equivalents
in Preferences is not adequate, and expecting people to run "segedit" is
not acceptable, either.

To get a start on helping us developers do the right thing, maybe we
could collectively build a list of known key-equivalents in various apps
that already exist, as a reference point for implementing similar features
and also as a tool for finding interface problems in existing products.

Here are the current "non-standard" ones for TouchType, as a starting
point (ideally these should be sorted by key equivalent, too, but I'm
too lazy):

	Info/Preferences		k
	File/Save As Illustrator...	I	(capital eye)
	Edit/Fix Selection		G
	Edit/Redraw Screen		D
	Edit/Select Line		H
	Edit/Select All			a
	Edit/Deselect All		A
	Format/Align/Left		L
	Format/Align/Center		C
	Format/Align/Right		R
	Format/Align/Justify		J
	Format/Align/At Baseline	_	(underscore)
	Format/Align/At X-height	T
	Format/Word Space/Tighten	{
	Format/Word Space/Loosen	}
	Format/Word Space/Default	|	(vertical bar)
	Format/Leading/Set To...	l	(el)
	Format/Leading/Increase		.	(period)
	Format/Leading/Decrease		,	(comma)
	Format/Leading/Default		/	(slash)
	Format/Rotate/To...		r
	Format/Rotate/Default		!	(shift-1)
	Format/Rotate/15 Clockwise	#	(shift-2)
	Format/Rotate/15 CounterClockse	@	(shift-3)
	Format/Rotate/1 Clockwise	%	(shift-4)
	Format/Rotate/1 CounterClockwse	$	(shift-5)
	Format/Page Layout		P
	Font/Size...			F
	Font/Visual Selection		V
	Kerning/Touch Kern		K
	Kerning/Tighten			[
	Kerning/Loosen			]
	Kerning/Revert			\
	Kerning/Pair Data/Remember...	;	(semicolon)
	Tools/Colors			e
	Tools/Arrow			1
	Tools/Text			2
	Tools/Show Tool Panel		5
	Tools/Show Active Fonts		6
	Tools/Show Kern Panel		7
	Tools/Show Ruler Guides		g
	Windows/Zoom In			>
	Windows/Zoom Out		<
	Windows/Reset Window		0	(zero)
	Windows/Zoom True WYSIWYG	W

As you can see, being a keyboard sort of guy, I love command-key equivalents,
but there just aren't enough reasonable possibilities for all of them.

Also, I don't know if this affects this "study", but TouchType supports the
following Emacs-style editing commands:

	Forward one character		control-f
	Backward one character		control-b
	Next line			control-n
	Previous line			control-p
	Kill to end of line		control-k
	Move to beginning of line	control-a
	Move to end of line		control-e
	Delete next character		control-d

I hope this turns out to be useful, 'cause it was a pain to type it all
in :-)

--
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		NeXT/PostScript developers
 ..{adobe,next}!heaven!glenn		415-326-2974 (NeXTfax 326-2977)