Publishing Web for Students' Final Papers

Home Post Search Contents

Evaluating Human-Computer Interface in Children’s Software

 

From: David Scott
Email: cogito@cats.ucsc.edu
Course: Psych 101: Informal Learning and Technology
College: University of California, Santa Cruz
Instructor: Eugene Matusov
ClassWeb: http://www.ematusov.com/psych101
ChildrenObservations: Yes
Date: 08 Dec 1996
Time: 01:54:39
Remote Name: hustle.ucsc.edu

Abstract

In this paper I will discuss many of the factors one should consider when evaluating whether or not a computer program (or "software") is "good" or not. This information could be useful when making software buying decisions, especially children’s educational software. My focus will be on how well a program accounts for the needs of the typical user. The most important criterion is that the program provides "constructive guidance" to help the user understand to goals of using the program and the methods to achieve these goals. Guidance is dispensed through the program’s "human-computer interface", which is how the human gives commands to the computer and how the computer displays information to the user.

Paper

In this paper I will discuss many of the factors one should consider when evaluating whether or not a computer program (or "software") is "good" or not. This information could be useful when making software buying decisions, especially children’s educational software. My focus will be on how well a program accounts for the needs of the typical user. The most important criterion is that the program provides "constructive guidance" to help the user understand to goals of using the program and the methods to achieve these goals. Guidance is dispensed through the program’s "human-computer interface".

Any time a person looks at a computer, everything he sees is "interface". How the user communicates his desires to the computer, which happens through devices such as the mouse and keyboard, is "input interface". How the computer provides information for the user, through such devices as the monitor screen or printer, is "output interface". The interaction between input, output, and the human mind is what "human-computer interface" is all about. The mark of a good interface is high "usability". Tom Carey (Hix, 1993, p. 3), an authority on the subject, describes usability as, "If your computer were a person, how long 'til you punch it in the nose?" A computer program needs to provide a useable interface in order to be entertaining and/or productive for the user.

Unfortunately, for most of the history of computers, they have been accessible to only a small number of highly trained people considered experts in the field. The reason why is because traditionally the design of computer systems has been the responsibility of computer programmers. These people posses extensive technical knowledge but rarely any human factors awareness, so design decisions have been made intuitively or to the liking of the sophisticated tastes of the programmer, not the typical user (Galitz, 1994, p. 39).

Since companies realized there was a large non-expert market for software, there has been a push to put usability on par with other software engineering goals. However hiring psychologists and other human factors personnel is and added expense to an already costly software development process that many manufacturers feel is expendable (Wixon, 1995, p. 31).

Companies need to realize that there is an economic advantage to making their products and services accessible to a wider variety of people, including younger audiences. For example, the Prodigy on-line service, among others, has made a deliberate effort to tap into the child market by providing areas of their system that are specifically tailored to be of interest to them. They have also incorporated a simple and "child friendly" interface for exploring (or "navigating") the system. This is an example of what can be achieved if the needs of the typical user are considered during the design process (Heim, 1995).

For children's programs, there are several important factors that need to be considered when deciding if the interface is appropriate or not besides mere simplicity. The age of the user plays a large part in determining the user’s motivations for using the program. While an adult may be motivated to use a program because it facilitates their work, a child will mainly be interested in the computer as another form of play. Software that is considered by the child to be a game is far more demanding of interface requirements because the user of a game usually feels no compulsion to play it. If the game's interface is clumsy or confusing, the goal unclear, the action frustrating or boring, or rewards are not forthcoming, the player simply abandons it. The user interface must be not only be functional and easy to use, it must also be fun (Laurel, 1990). One noted authority on software, John Dvorak (Dvorak, 1995), has written, "with most CD-ROMs, no matter how they are marketed, the rule is: 2 hours of boredom, and it is never used again."

One of the educational games I have experience with is "Oregon Trail II", which was rated as one of the top ten CD-ROMs of 1993 by "MacWorld" magazine (Martin, 1994). In the game, the user takes the role of a hopeful prospector journeying across mid-19th century America. It involves many factors, including communicating with other prospectors, making tactical decisions about which routes to take and how to care for the passengers in your wagon train, and evaluating your supply needs and trading appropriately. However, as I have seen repeatedly, children tend to focus on the hunting aspect of the game, the interface of which resembles a fast-action arcade video game. This is an example of how an interface can be considered fun, but when misapplied, directs the user’s concentration to one specific area of the program. Teachers have expressed frustration when students have focused on shooting buffalo and ignored the other historical, strategic, and educational features of the game, even when that resulted in the members of their wagon train dying (from starvation or sickness) well before they reached their destination (Logical, 1996).

Another motivating factor in entertainment software is that they incorporate a point reward system. Competitions often occur between players only so that one of them can boast of having the highest score. Most games also incorporate increasing levels of difficulty as play continues, with the corresponding point gains increasing appropriately. This implies the conclusion that the human mind reacts favorably to rewards and challenges. Maybe more software (including application programs for adults) should incorporate point systems and sub-goals. Imagine a word-processing program that would give the user points each time a new command is learned and effectively used (Laurel, 1990).

A fact of human learning that has been little realized by program designers is that people prefer to be active in their environment, so they will often operate using a "trial and error" approach. They will devise tentative solutions for a problem, test them out, and if unsuccessful, revise their solutions taking this result of their last test in mind, and try again with greater chance of success. In fact, some studies have shown that as high as half of the typical user's commands are done in error (Galitz, 1994, p. 40). However, for too long, programs have been designed with the assumption that the user will not perform an action without high confidence. Experimenting on a computer set up in this way can have disastrous results, putting the user in situations that are difficult or impossible to escape. A user will often become frustrated and stop using the program. Better interfaces follow the design goal that people requirements always take precedence over technical requirements. They allow the user to experiment with the program by giving them a way out of difficult situations. The program should be designed so as to not allow the user to make errors whenever possible. One way to do this is to remove (or "gray out") buttons from a graphical interface that may not be pressed at the current time. When errors do occur, the computer should be as tolerant and forgiving as possible, and should provide constructive messages that help the user to understand the system better. A very useful device is the "undo button", which reverses the last action made by the user, in effect providing a graceful way of escaping a flawed plan. Following these guidelines will make for a happier and more productive user who will feel more free to experiment with the software and who is able to better learn from his explorations (Galitz, 1994, p. 28).

The use of informative error messages is an example of how the human-computer interface can provide constructive guidance to the user. For a system to be learned and understood well enough to be used, the user must be able to understand what needs to be done, why to do it, and how do it merely by looking at the screen. Preferably this can be done without extensive thought or effort on the part of the user. A good human-computer interface does not give the impression that understanding the program will require more time than a user would want to commit, or that the system is too complex to be understood at all (Galitz, 1994, p. 24).

The traditional answer to a difficult to understand program is "documentation", instructions either in the form of an on-screen help system or an accompanying user manual. However, they truth is you cannot fix a usability problem with documentation! It is rare that a complex design can be clearly explained on paper, even with the aid of diagrams (Wixon, 1995, p. 11). Also, the typical user wants to spend time using the system, not learning how to use it. Here is an excerpt from an article written by an adult teacher who was working with an 11-year-old boy who was trying to use the program "Treasure Cove" that illustrates the typical way that a child deals with program documentation:

"[The child] skipped right past the story. He didn't want to listen to it, he just wanted to play the game. But when we got to the game, he couldn't figure out what to do. He asked me, but I didn't know either. I told him he needed to listen to the story in order to know what to do. He reluctantly agreed to do that. Then, unfortunately, we still didn't have enough directions to understand the game. So [the child] and I tried to figure it out on our own again, without success. I suggested we click on help in order to get more direction. [The child] was adamantly opposed. He would rather just move around in the game not knowing the point than take the time to look through the directions. Finally, he gave up on the game, deciding it was boring. So I said I would look at the directions under the help icon. I read them but they didn't clarify very much. They told what to do, but not how to do it." (McDevitt, 1996)

One can imagine the frustration that both the teacher and child felt when they had to end the game they were playing to read the instructions. Even worse, after they had read them and started the game over, they still did not know what to do! This example illustrates an important point: programs are easier to learn if they are designed so that the user does not need to know the entire system before they can get anything done. Rather it is preferred that the user can get things accomplished with only a basic knowledge of the program functionality. It is also useful if a user can be motivated to learn more about the features of the program as he goes along because they understand that will lead to superior results (Galitz, 1994, p. 42).

There are other reasons why children do not usually tolerate traditional forms of program documentation besides their eagerness to start using the program. As mentioned in the discussion of user motivation, a child will not continue in a boring play activity. An exciting program can be considered boring by a user when it is not understood well enough to be fully used. Wilbert Galitz (Galitz, 1994, p. 45) has written that, "The perception of having to learn huge amounts of information is enough to keep some people from using a system." This often happens when a child is presented with a text screen full of instructions upon starting a program. They will press buttons randomly trying to skip past it as soon as possible. When the game starts they might be looking at a screen that provides no clue as to where they should begin activity.

Another important factor to consider is that children have had fewer positive experiences with reading than the average adult. Obviously, they function at a lower reading level, and preschool age children often cannot read at all. At the very least, text given in children's software should be made short and simple. A better solution is to design the system so that a lot of reading (and other forms of higher-level comprehension) is not necessary. One successful way this is implemented in the game "Oregon Trail II" is to have the instructions presented during the course of the game action by animated characters you meet during your travels. When you talk to them, their advice is printed on the screen and you can hear their voices through a speaker. Also since the advice they give ranges from helpful to suicidal, resolving these puzzles gives players an added incentive to think and pay attention to the instructions. Providing a context where learning is valuable because the information gained is immediately applicable is an important key to motivating users to understanding the system (Strommen, 1993, p. 351).

Guidance can come in forms other than instructions on how to play the game. Especially in children’s software, there is a need for immediate acknowledgment and feedback for actions. Graphics and sound effects provide rewards for successes and indication of failure. Educational games for young children might have a sound effect for every action or animated faces that tell the user what to do (Galitz, 1994, p. 30). However, as is the case with documentation, poor interface design cannot be solved by only providing feedback. This can be illustrated in an example where a teacher is working with a 7-year-old girl using the program "The Magic School Bus Inside the Earth", the point of which is to teach geology by having the child conduct experiments manipulating different elements found in the Earth:

"She absolutely didn't understand the meaning of the game, because the underlying logic requires some knowledge that she just doesn't have. She only wanted to play on the surface where she could click on some things and be rewarded by some animations or sounds." (Schulze, 1996)

In this case the child was not working towards the intended goal of the game, but acting somewhat randomly in order to get anything interesting to happen. During my own observations with this game, I have noticed how children would play with the character-creation screens that appear before the game really starts. Here the user can how his character looks by changing his hair, eyes, nose, etc. Every time the user clicks on a different feature, there is an entertaining noise as the character’s appearance changes. It must be fun because I have seen children continue experiment with different faces for their characters for several hours without ever actually starting to play the game!

Another useful guidance tool is a "template". A template provides a skeleton structure into which a user can fill in the blanks. For example, the program "Print Shop Deluxe", which allows you to create custom banners, sign, and greeting cards, simplifies its design interface by providing many examples of finished signs that the user can alter to use as his own. This program also employs "wizards", which are on-screen messages that guide the user through each step of the creation process and prompt for information at the relevant times. This type of guidance helps to combat frustration that can occur when there is an inability on the part of the user to convey his intentions to the computer. The user’s concentration should be focused on the goal of using the software, not on jumping through all of the hoops the computer holds up. (Holzberg, p. 1994)

It is to be hoped that the importance of well-designed human-computer interface has become clear, not only in children's educational software, but in any kind of program used by anyone. The role that constructive guidance plays in getting a user to understand how to use a program should not be overlooked when evaluating the effectiveness of educational software.

REFERENCES

(Dvorak, 1995): "Is Bob Really a Kidsworld?", by John C. Dvorak, in "PC Magazine", volume 14, number11 (June 13, 1995), page 89.

(Eiser, 1994): "Kid CAD. (Davidson & Associates' educational software provides computer-aided design tools that enable elementary and middle school students to design three-dimensional structures)", by Leslie Eiser, in "Technology & Learning", volume14, number 5 (Feb, 1994), page 8.

(Francik, 1995): "Rapid, Integrated Design of a Multimedia Communication System", by Ellen Francik, in "Human-Computer Interface Design", edited by Marianne Rudisill, Morgan Kaufmann Publishers, Inc., San Franciso, CA, 1995.

(Hill, 1993): "A Wizard of Oz Study of Advice Giving and Following", by William C. Hill, in "Human-Computer Interaction", 1993, volume 8, number 1, pages 57-81.

(Galitz, 1994): "It’s Time to Clean Your Windows: Designing GUIs That Work", by Wilbert O. Galitz, John Wiley & Sons, Inc., New York, 1994.

(Heim, 1995): "Best Online Services", by Judy Heim, in "PC World", volume13, number 6 (June, 1995), page141.

(Hix, 1993): "Developing User Interfaces: Ensuring Usability Through Product & Process", by Deborah Hix, and H. Rex Hartson, John Wiley & Sons, Inc., New York, 1993.

(Holzberg, 1994): "Instant printouts. (The Software Toolworks' Card Shop Plus, Maxis's Print Artist and Broderbund software's Print Shop Deluxe educational printing software)", by Carol S. Holzberg, in “Technology & Learning”, volume15, number 2 (Oct, 1994), page12.

(Laurel, 1990): "The Art of Human-Computer Interface Design Book Review", author unknown, (http://www.his.com/~pshapiro/art.of.human.html).

(Leslie, 1994): "Creative Writer", by Leslie Eiser, in "Technology & Learning", volume15, number 1 (Sept, 1994), page17.

(Logical, 1996): "Putting the 'Logical' into 'Technological'", author unknown, (http://www.ncte.org/standards/sip/sip3-51.htm).

(Martin, 1994): "Top 10 CD-ROMs (best multimedia discs of 1993)", by James A. Martin, in "MacWorld", volume 11, number 3 (March, 1994), page 90.

(McDevitt, 1996): "Kids Don’t Want to Read Directions!", fieldnote of Annie McDevitt, found in the class Web discussion at http://www.ematusov.com/psych101, for Psychology 101: Informal Learning and Technology, Fall 1996.

(Miller, 1995): "The Xerox Star: An Influential User Interface Design", by Lawrence H. Miller and Jeff Johnson, in "Human-Computer Interface Design", edited by Marianne Rudisill, Morgan Kaufmann Publishers, Inc., San Franciso, CA, 1995.

(Olson, 1995): "Mapping the Method Muddle: Guidance in Using Methods for User Interface Design", by Judith S. Olson and Thomas P. Moran, in "Human-Computer Interface Design", edited by Marianne Rudisill, Morgan Kaufmann Publishers, Inc., San Franciso, CA, 1995.

(Schulze, 1996): "Geology, Different Levels of Understanding the Game", fieldnote of Jakob Schulze, found in the class Web discussion at http://www.ematusov.com/psych101, for Psychology 101: Informal Learning and Technology, Fall 1996.

(Strommen, 1993): "Is it Easier to Hop or Walk? Development Issues in Interface Design", by Erik F. Strommen, in "Human-Computer Interaction", 1993, volume 8, number 4, pages 337-352.

(Wixon, 1995): "Usability for Fun and Profit: A Case Study of the Design of DEC Rally Version 2", by Dennis Wixon and Sandy Jones, in "Human-Computer Interface Design", edited by Marianne Rudisill, Morgan Kaufmann Publishers, Inc., San Franciso, CA, 1995.

Last modified January 12, 1997