Bug#256539: ctrl-L

[Peter Moulder]

On Sun, Oct 17, 2004 at 08:16:57PM +0200, Lo=EFc Minier wrote:
> Peter Moulder <Peter.Moulder@infotech.monash.edu.au> - Tue, Aug 03,=
 2004:
>=20
> > I don't see a button for this, nor any text suggesting pressing c=
trl-L,
> > nor even a help button.
> > A sufficient fix for the bug would be to add a button or some tex=
t
> > suggesting pressing Ctrl-L.
>=20
>  This is pretty much standard in all GNOME apps, and is documented =
in
>  the GNOME HIG for example:
>     <http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard=
.html>

The above presents an argument that most users know that in this dial=
og
they could press Ctrl-L to enter a filename.  A more direct way of
ascertaining this is to ask some users.  The weak evidence available =
to
me suggests that most users are not aware of this:

  - Neither of the two people in my office (both long-time computer
    users and X11 users) were aware of it.

  - Discussion on a mailing list to which I subscribe (inkscape-devel=
)
    shows that a number of other people weren't aware of this.  It's
    hard to estimate a proportion from this fact, but does show that
    someone cared enough about it to write about it.

Some other comments on the quoted argument given:

  - Gnome apps represent a minority of the programs familiar to users=
 of
    this dialog box.

  - Documentation in GNOME HIG is relevant largely only as evidence t=
hat
    it is common among GNOME apps, rather than as independent evidenc=
e
    that users are aware.  I'd have thought that the number of people
    who have read the relevant table entry in the page cited would be=
,
    say, 4 * the number of gnome apps in existence, or fewer.

  - The bug is filed with libgtk2.0-0.  Some programs using this dial=
og
    box aren't gnome apps, and don't use Ctrl-L for this purpose.  (A=
nd
    no doubt some gnome apps don't use Ctrl-L for this purpose.)

The other relevant question is how useful the action triggered by Ctr=
l-L
is.  If there were some action possible with Ctrl-L but not otherwise
possible, then that would be a strong argument for either including a
button, or increasing the number of people who know about Ctrl-L,
perhaps by including a text label mentioning Ctrl-L.

I don't know of anything achievable with Ctrl-L that cannot be achiev=
ed
with the graphical navigator, though certainly the text field offered=
 by
Ctrl-L is much faster.

>  I think we can not clutter every dialog with unuseful keybinding
>  reminders like "arrows to move up and down" or the like.

A button (e.g. "Open Location..." / "Save to Location...") is less
clutterful than an equivalent text label describing a key binding.

A Help button is an even less clutterful alternative.

Usefulness is discussed above.

For balance, below is some discussion of the costs of including a but=
ton
or text label in the dialog box.  (I do not discuss other approaches =
of
increasing user knowledge of Ctrl-L.)  Costs:

  - Extra time spent reading / understanding the dialog box.  This ti=
me
    cost is largest the first time that the user sees the dialog box,=
 or
    if the dialog box isn't often seen.

    (The time cost may be offset by time saved wenn using the feature=
,
    of course.)

  - Extra space required, which involves either:
 =20
      - growing the window (and hence obscuring more of the informati=
on
=09behind the window, and possibly growing past the size of the
=09screen depending on user's choice of fonts); and/or

      - allocating less space to existing content in the dialog box,
        which typically reduces readability, or (if removing=20

    Related costs:

      - Possible intimidation upon seeing a large dialog box.

      - Possible aesthetic cost: where to put the new button/label?

  - Development costs:

      - Changing the dialog box.  If using a Location button, then
=09associate its action to the same as Ctrl-L.  A Help button may
=09involve a new action.

      - Translations.

      - Peer review, testing.

pjrm.