Work in teams based on a number assigned in class.
Chapter 12 goes to great lengths to tell you about the shortcomings of on-line documentation, including poor readability, increased paging, slow paging rates, reduced work space, and increased confusion for novices to whom computer interfaces are unfamiliar.
These weaknesses are, in part, the result of a phenomenon that we encountered last session: You can't always use new technologies effectively when you are thinking the same old way. Just as you can't become a truly effective user of C++ or Ada95 if you still think procedurally or a truly effective designer of hypertext documents if you still think linearly, you can't become a truly effective designer of on-line help and documentation if you still write paper documents and translate them into the new medium. This phenomenon is not limited to computing technology. Ask artists and architects about the media that they use...
Relles and Price (pp. 426-427) list eleven types of help for which on-line systems "open the door" to better help facilities. As a group, choose any two and do the following for each:
The tangible result of your work will be a list of examples and answers.
This exercise serves two purposes. First, it helps you focus on the topic of on-line help before you work on it in detail in Exercise 2. Second, it lets us think at a more concrete level about on-line help than the text provides. Because Shneiderman aims this book a bit more at researchers and grad students than at undergraduates, many of his sections can look like unsubstantiated claims. The citation of the Relles and Price paper is an example. We could read the paper itself and perhaps find more concrete examples (perhaps not!), but that isn't our focus in this course.
But we can work to make the list more concrete on our own time. That is a great way for us to study and learn the material. One simple way to improve this section itself in an on-line form would be to include links to the papers cited, since they will provide more detail on the topic.
Can on-line help make a qualitative difference in the user's experience? Probably: they can stay on task, with as little interruption as possible, which allows the computer to "disappear" as much as possible.
But we must remember that help of any sort, even on-line help, cannot be treated as a crutch for the design of bad interfaces. For instance, I am not eager to have a really good on-line help system for driving my car. For that system, "on-line" means while I am driving, and I certainly would not want to have to get help while operating a car at 65 MPH down a busy interstate...
Work with the same people as you did on Exercise 41.1.
A wise man once said:
"It's not that Unix isn't user-friendly.
It's just that Unix is particular
about who its friends are."
Imagine: You graduate from UNI and begin your first job, with Sun Microsystems, a producer and marketer of, among other things, Unix and Unix-based work stations. Sun is impressed that you have studied human-computer interface design with the famous Dr. Wallingford. (You know how these industry people gossip...)
The company would like to apply your HCI expertise to its thorniest problem this side of Microsoft: making Unix friendlier to its full range of clients, from beginners to the most experienced hackers. They ask you to design an on-line help manual for Unix.
Use the OAI model to design your manual. Shneiderman discusses this model again in Sections 12.3.1, and we saw last time that he covered it in Section 16.6 (web example) and Section 2.3 (in detail).
The tangible result of your work will be a design document that outlines the task and interface of your manual in terms of task objects and actions. Include simple screen shots and other images to augment your text wherever you think they help. Be prepared to present a summary of your design to the class.
Using the OAI model means that you must define the following components in your answer:
command-response cycle /\ / \ error command / | \ / | \ program args downstream / \ / \ connector command
create, modify, retrieve/modify/apply, apply
determine arguments, determine effect
What's the metaphor? Dictionary? Encyclopedia?
items needed include: history list, pipes and filters, redirection of I/O
We might implement help in-line or in a new window...
I loved the two metaphors we discussed in class: the subway and the advice column. You may have chosen these metaphors more for their humor value than for their design value, but they really do help us to think about help in a new and more exciting way. (Dictionary? Library? Please...:-) For instance, I had never thought very hard about the role that FAQ listings might play in an on-line help system, and how the FAQ listings interact with discussion lists that offer help. Dear Abby made me do so, though!