DevHelp usability

["Krzysztof Foltman" <wdev foltman com>]

I wrote this mail responding to reaction for my suggestion about how to
make DevHelp more usable for keyboard users. 

http://bugzilla.gnome.org/show_bug.cgi?id=118358

Because there was no significant usability-wise progress in DevHelp
since 2003, I'll try to give some reasoning behind why and how I think
it may (and should) be improved.

I like my keyboard. Especially during software development, which
already keeps your hand on the keyboard and off the mouse. However, my
attempt to use the keyboard in DevHelp ended up with a complete failure,
and that wasn't because of incompetence or lack of skills. In such an
application, there is no reason for the mouse to be used at all. Some
users may find it more comfortable, but it shouldn't be a requirement.

So, I'll try to give some arguments why the application may be better
than it is now, and how it can be achieved. While you may dismiss my
opinion as coming from someone who's not an usability expert, I'm one of
the target users and I know what I'm dissatisfied with.

1. The purpose of DevHelp.

What do we use the devhelp application for? Mostly, to find relevant
information in a set of hierarchically organized documents (devhelp
books), containing (mostly) information necessary to create software. Is
that correct?

How we are going to use it? We first need to find a relevant subdocument
about particular topic we're interested in, in a large tree consisting
of many subdocuments, then we need to read it.

Sometimes the information isn't exactly where we expect it to be, so we
need to navigate the tree a bit (or more than a bit) to find it (it's
hard to expect the documentation writers to make it intuitive for
everyone, because there's no such thing). Then we need to read the
topic, and use the information if it's there, or move to another
relevant topic if it's not. Right?

There's a search function too, but we can't rely on it as the sole way
of using devhelp books (otherwise, the contents tab would be
unnecessary). Because the contents tab is selected by default, I assume
it's intended to be the preferred way of finding information in the
documentation. Right?

To sum things so far, we may assume the content tab is supposed to be a
default way of finding the information in the books, and - because we
can't always assume the information is where we expect it to be - the
content tab should be implemented in a way that lets us navigate many
topics with minimal effort. Right?

The DevHelp application is a rather simple one, so it doesn't need a lot
of time to learn. What's more, a typical target user is a power user (in
most cases, a software developer), not a novice. Learning a few new
things in order to make her job easier and faster is not going to make
her too frustrated. Right?

On the other hand, if using Devhelp isn't seamless, it can keep her
distracted from the main task (finding the documentation and, possibly,
programming). Seamless may be hard to define precisely in this context,
but I think being able to achieve the goal (finding a topic) with
minimal keyboard use (just one hand, no wrist movement), and the
predictable and "goal-centered" behaviour (ie. optimized for the easiest
achievement of the expected goal), is pretty close to seamless. Is it?

2. Conformance to standards versus user experience

The conformance to standards is not meant to be a goal in itself, it's
meant to make user experience better. It's just means to achieve a goal
of usability. It was done to help the user, not to satisfy some
arbitrary criteria. At least that's the way I think of it.

And if the conformance makes user experience worse (to the point of
causing frustration), it doesn't lead to achieving any goals. It's not a
way of achieving a goal anymore. Then, you may think of sacrificing it
for better user experience. This argument may be a bit controversial to
the consistency purists, but how does it look from a practical standpoint?

[ Let me give an (exaggerated) example of conformance to standards
interfering with user experience: Unix man. It's surely a standard
conforming way of storing and displaying documents. But how does it
compare to true hypertext documents? It lacks contents pages (so we must
know the command name in order to be able to get more information), no
indexes related to topics and no true hyperlink navigation (there are
apps that try to guess that, but that's outside the discussion).
Authoring sucks. It's means-oriented, not goals-oriented ("read the man"
"but man what?"). But many developers still use it, because it's
standard-conforming. On the other hand, did anyone use a DOS text-mode
application called Tech Help!, which dates back to 1990 or even earlier? ]

3. Why the DevHelp UI can be improved

Let's first describe how do we navigate the content tree with the keyboard.

We start from the root. Then, using up-down arrows, we need to find the
book we expect to contain the required content. Let's assume we had to
place our right hand on the arrow keys, and the left one is resting. The
subtree description subdocument shows up.

Then, in order to dive deeper in the book, we need to open the subtree.
Currently, it can be done in three ways (let's ignore the Shift-=
combination for now). First, we may use left hand to press Shift, and
the right hand to press arrow. Second, we may use the right hand to open
the topic with Shift-arrow (just try that, not the most comfortable hand
position). Third, we may move our right hand to the numeric keypad and
press the Plus key. So far, there's no faster and more comfortable way
to do it. Or is it?

The keys that would be more comfortable to use, should be the ones that
are close to the up/down arrows (namely, left-right arrows and Enter).
But they're either unused (Enter), or already used for something that
isn't used as often as opening/closing subtrees (namely, horizontal
scrolling). How often (and when) is horizontal scrolling used, comparing
to expanding subtrees? In practice, not very often, usually only for the
long titles that don't fit.

Keeping that in mind, we can't rid of the ability to scroll
horizontally, currently occupying left-right arrows, because, when the
content window is narrow, the entries are truncated, and when it's wide,
it makes the document window smaller.

Now let's assume we've found a document and we need to read it. It would
be nice to move the focus to the document window. It would be also nice
to have a quick way of getting back to the content tree, just in case
the document proves not to be the thing we've been looking for. Would it?

Sometimes it's also needed to switch between several content pages, if
one contains a specific function and the other contains a structure
that's used by that function, or switching between several related
functions. It's currently done using history keys Alt+left and
Alt+right, however, it's incompatible with browsing the content tree
with a keyboard (it may clutter or truncate the history because every
movement in a tree is treated as opening a new page).

4. Proposed solution (the arguably optimal one)

Let's forget for now about any previous behavior of the application,
because it was already shown to lead to suboptimal user experience.

First, we need a comfortable way to navigate the content tree. We may
use the up/down arrows for up/down tree navigation (like in any other
tree view), and the right/left arrows for expanding and collapsing nodes
(books).

That has a drawback of removing a - sometimes useful - functionality of
being able to see the full titles of the books by scrolling
horizontally. The impact of the change is minimal, but even if it proves
troublesome, there are four different solutions that may be optionally
applied:

- Firstly, automatic horizontal scrolling may be implemented, which
would scroll the content window horizontally so that optimal part of the
information is displayed. It may confuse the user at first, but the user
the application is targeted at, can be expected to know what happened.
Reaching the parent nodes could scroll the window back.

- Secondly, in most cases the need of scrolling can be eliminated
altogether, by using shorter titles (Index of new symbols in 2.2 -> New
symbols in 2.2). At least some parts of the long titles are basically
redundant, shortening them would be beneficial, eliminating the need of
unnecessary horizontal scrolling - even if none of the current code is
changed at all!

- Thirdly, the horizontal scrolling, because it's meant to be seldom
used, may use a less comfortable key combination, like Ctrl+arrows like
in Microsoft software).

- Fourthly, the tool tips may be employed to display the full title of
the book the cursor is on (however, it's not even necessary, if the
document itself is displayed in the document panel, like it is now).

Frankly, the horizontal scrolling with a keyboard isn't even very useful
now, because the distance it scrolls by isn't always adequate, leading
to a "dead zone" in the middle of the scrollbar, that couldn't be
scrolled. All in all, even if no remedy is applied, it will be as good
as it is now.

Now that the left/right arrow keys were reassigned to expand/collapse
nodes, this still leaves the Enter key unused.

I think it could be employed to move the focus to the document window
(so that the document can be scrolled). The focus could be brought back
to the content window with Esc key. While it requires the use of the
left hand, it seems OK, because the feature isn't used even nearly as
often as tree navigation keys, it's close to intuitive, and it's better
than status quo of not having the feature at all.

You can imagine that to a quasi-modal "process" of viewing document,
which is entered by Enter and left by Esc. Easily learned and used, too.

To aid switching between contents and search tabs, a Ctrl+Tab
combination (or Ctrl+1/2, or Alt+1/2, all which are used to switch tabs
in numerous applications) can be employed. The problem of having to use
the left hand seems to be insignificant, because the functionality is
not used very often (not even as often as switching between document and
contents/search windows), and two hands will be used anyway for typing
in the search string.

Because the documents are rarely scrolled horizontally, the left/right
arrows in document window may be used instead of TAB key to navigate the
links. Again, horizontal scrolling - if needed at all - may be
reassigned to use Ctrl+Left/Ctrl+Right.

That leaves us with the history problem still unsolved. The only
solution I have is rather fast and comfortable to use, but it isn't very
"elegant". It involves a sort of history list box, invoked with
Backspace key (as in "going back" and as a key that is close to other
navigation keys), which is filled only when a topic is explicitly opened
by pressing Enter in a content tree or by clicking a link inside another
document. 

5. A conservative solution

Another solution (clearly inferior to what I described above, but still
useful) would be to keep the arrow keys to work as they are now (but
with fixed scroll amount of horizontal scroll bar), and employ the Enter
key to expand/collapse nodes of the tree. It requires more wrist
movement, though, and places the often used collapse/expand
functionality below the more rarely used horizontal scrolling.

An additional drawback of the second solution is not being able to use
any easily guessable key combination to move the focus the document
window and content window (TAB is taken by link navigation in document
window, using Esc to switch focus to the document would be awkward as
the quasi-modal document metaphor is no longer preserved, Enter is
already used to expand/collapse, the other nearby keys like Backspace or
Insert are not conceptually linked to switching windows).

6. Summary

To sum things up, all the proposed solutions have a potential to make
DevHelp more friendly to keyboard-oriented users in numerous ways:

- reducing unnecessary hand movement, by making the most used
functionality available instantly at cost of functionality used less
often or not at all
- keeping things simple and internally consistent (just a few very
standard keys: arrows, Enter, Esc and seldom Ctrl+Tab and Alt with
arrows, to access the WHOLE existing functionality!)
- allowing keyboard-only operation

It doesn't solve the already existing problems of long topics and
navigating the document history. But it's a consistent base to build upon.

Comments?

-- 
Krzysztof