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 _______________________________________________ gnome-devtools mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-devtools
