Director, Computer and Information Literacy

Utah State University

0310 Old Main Hill

Logan, UT 84322

(435) 797-7050 (office)

(435) 797-0956 (fax)

stacieg@cc.usu.edu

Professor, Brigham Young University

Provo, UT 84602
(801) 378-4636

andy_gibbons@byu.edu

Included with the design of any product is the inherent definition of a user language. Often developers are so engrossed with the devising of the product, they are unaware of the existence of the user languages that allows the product to actually be used. Donald Norman (1990) describes in his book Design of Everyday Things how these languages exist within products we use in our everyday lives. This paper is a description and application of those principles. When applying the described principles, developers of instruction or products will design a product more conducive to the users’ world.

How does one use a key to unlock a door? The answer is obvious and most people are very familiar with the procedure -- one puts the key in the keyhole and turns the key. The more important questions are how and why do most people know this? The design of the key and keyhole concept is implicit and has a language which "speaks" to users and lets users know what they are supposed to do. This language is often overlooked, or its existence is not realized as designers develop products which are made use of in our everyday lives.

Whereas there is a design language used when designing products (Gibbons, n.d.), we propose that there is an additional language inherent in all designs, called a user language. It is the language that "speaks" to the user and describes what actions to invoke so that the product performs in the expected way.

Included with the design of any product is the inherent definition of a user language. Often developers are so engrossed with the devising of the product, they are unaware of the existence of the user languages that allows the product to actually be used. Norman (1990) describes in his book Design of Everyday Things how these languages exist within products we use in our everyday lives.

The human mind is exquisitely tailored to make sense of the world. Give it the slightest clue and off it goes, providing explanation, rationalization, understanding. Consider the objects – nooks, radios, kitchen, appliances, office machines, and light switches – that make up our everyday lives. Well-designed objects are easy to interpret and understand. They contain visible clues to their operation. Poorly designed objects can be difficult and frustrating to use. They provide no clues – or sometimes false clues. They trap the user and thwart the normal processing interpretation and understanding (Norman, p. 2, italics added).

 

The user language embedded in every designed product communicates the possible functions for that product. However, designers may not realize the significance of including an effective language within their product. Moreover, many designers are not cognizant of the user languages they create as they develop their products. In most situations this language is the result of the design instead of planned into the design.

Designers know too much about their product to be objective judges: the features they have come to love and prefer may not be understood or preferred by the future customers (Norman, p. vii, italics added).

 

Included in every design are the affordances, mappings, visibility, and feedback. Each of these has it own implicit language which speaks to the user. Affordances are the "perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used" (Norman, p. 9). Mapping is a technical term meaning the "relationship between two things, in this case between the controls and their movements and the results in the world. … Natural mapping … leads to immediate understanding" (Norman, p. 23).

In good design the attributions and functions of the product are visible. "There are good mappings, natural relationships, between the controls and the things that are controlled. Single controls often have single functions. There is good feedback. The system is understandable. In general, the relationship among the user’s intentions, the required actions, and the results are sensible, nonarbitrary, and meaningful" (Norman, p. 22). Feedback is the notion of sending back to the user information about what action has actually been done -- what result has been accomplished (Norman, p. 27).

In every instructional design there exists a language that communicates to the user all of the possible actions. Whenever a designer designs instruction, a user language is automatically created within that instruction. The instructional designer must be aware of this fact in order for the design to be able to communicate effectively with its users. This language allows users to communicate messages to the instructional system and receive messages back.

The purpose of this paper is to identify and define the terms of the inherent user languages within two existing software packages. The level of ease in understanding this language will be also be noted. Norman’s principles of affordances, mappings, visibility and feedback will be the basis of measurement. The first software package examined is a simulation game and the second is an online tutorial. Following the evaluation of these two products, the discovered user language terms will be applied to the analysis and design of a third software package -- a testing program developed at Utah State Universities. Failings of the languages included with this testing program will be corrected using the principles learned in the analysis and, thus allow for the development of a better product.

The simulation game Harry Potter and the Sorcerer’s Stone (Electronic Arts, 2001) was chosen for this analysis. The first author of this paper played the game to determine if the inherent communication language contained in the game was well designed. (She is not an experienced game player so no prior knowledge influenced the analysis.) "[Innovators] need to recognize that to overcome customers’ resistance, they must marry ease of use with ease of learning" (Schrage, 2002, p.23). This implies that the game should "speak to the user" letting him/her know what is expected without a manual to be read in order to figure it out. Norman (1990) contends that when simple things need pictures, labels, or instructions, the design has failed (p.9).

The first, and most obvious terms used within Harry Potter are those that describe the movements through the virtual environments. The first terms are defined by how the screen reacts to the arrow key presses. If the right/left arrow keys are pressed, the screen showing the scenery shifts to the right/left. These movement terms are defined further using the up and down arrow keys, which control the walking direction of Harry. The up arrow key moves Harry further into the scene and the down arrow key moves Harry out of the scene. The Harry Potter figure always remains in the center of the screen so using the arrow keys results in the scenery moving, not Harry. The Harry Potter figure only can move forward in a straight line so the scenery needs to be shifted accordingly (so that Harry will not run into a wall or when his path is not direct). This is an example of how the terms are combined to add more meaning to the way Harry is able to move. The list of terms found within the Harry Potter game is described in Table 1. This turns out to be a common language of control used in a variety of simulation games.

Aside from the basic movement commands, special situation commands, such as climbing and jumping, are also part of the user language contained in Harry Potter. These situation commands are presented on an "as needed" basis. As the user progresses along in the simulation, he/she needs to have additional terms added to his/her vocabulary to go any further. The teaching feature used in this program is hidden at key event points within the program. These new terms are not implicit, but are well defined explicitly by the program through interaction with Harry’s friends and instructors. For example, Fred and George Weasley "teach" Harry to climb and jump. Harry must pass a climbing and jumping test in order to continue in the program.

These terms are not constant throughout the program and only exist in specific situations. Harry cannot "climb" unless there is something which allows climbing. The term "climbing" is defined by "keep moving forward while in front of something the Harry figure can climb on, such as a bookshelf or small object." Without the clarification one would assume that if Harry kept moving forward while in front of a wall, he would climb the wall and this is not the case. Another situational term taught by Fred and George is how objects are collected. Harry "picks up" objects by running into them. The user adjusts the direction so Harry "walks" into the object to be picked up.

The tutoring feature of Harry Potter allows Harry to move throughout Hogwarts virtual environment and be met by friends and instructors who teach him, thus expanding the list of terms needed to be understood by the user. New terms include spells that force objects to "change" and definitions on how a game is saved. All of the terms discussed up to this point are included in Table 1.

The list of terms described in this table is just a small subset of the terms that actually exist in Harry Potter. The terms are all defined implicitly within the program and not difficult to find. However, not all of the terms were defined in the beginning of the game. One had to demonstrate understanding of previous terms before new terms could be added to the vocabulary. The user language found in Harry Potter was easy to understand and communicated effectively. If an aspect was not intuitive, instruction was included as part of playing the game so new functionality could be learned.

The Interactive Frog Dissection On-line Tutorial kit was developed by Mabel Kinzie (1994) at the University of Virginia in Curry to teach frog dissection without the use of real frogs. It uses images and video of real frog dissection and then presents them via the web allowing the user to perform the tasks of dissection as if the frog were real. Feedback is given telling the user whether the dissection step was performed correctly.

Finding a user language in a web-based tutorial is not as simple as in the Harry Potter simulation game. Although many terms are defined within the tutorial, how those terms are actually used varies. The first terms defined are the materials contained within the dissection kit. These are presented on an Information Page which is displayed before the tutorial begins. The environment consists of a"preserved frog" which was shown by graphics and video. The frog and its parts are pinned in the "Dissection Pan." Two terms, represented by graphical icons, are used to carry out program administration functions. They enable the user to select major instructional strategy treatments. These terms are described in Table 2.

Other terms allow the user to control and interact with the frog and set of dissection tools within a dissection procedure. The user is given standard tools to use, scalpel, forceps, scissors, pins and probes, to perform the dissection. See Table 2 for a description of these terms. The user language requires the mouse to be used as the input tool for the dissection task commands – to operate the scalpel, etc.

During practice the user chooses a tool and clicks on the frog graphic and attempts to use the mouse to simulate how the tool would be exercised in real life, e.g., using the scalpel to slice down the middle of the frog. Textual feedback displays indicate whether the task was performed correctly or not. Clickable hot links are included at the end of each step letting the user know he/she is ready to proceed to the next step of the procedure. The control language used to practice and traverse through the dissection process is explicit.

When using the web as the medium for delivery, it is possible that more constraints limit the choices for language use. For example, via modem, feedback is not always immediate. There is a delay between the communication (mouse click) and the result of that communication to the user. This can be compared to a pause in a conversation which further emphasizes there are a languages expressions being passed back and forth, between user and program in a kind of instructional conversation.

In both Harry Potter and the Interactive Frog Dissection On-Line Tutorial the user languages allow a user to navigate through a virtual space to perform specific functions. What differs between the two applications is the nature of the space and the nature of the functions. These factors constrain the set of controls offered in each package. Harry Potter affords the movement of a "frame of view" along a pre-set path within Hogwart’s school. This path meanders geographically and controls perform key "gate-opening" functions at certain event points (using Flippendo spell to move blocks to help Harry progress along the path). The Frog Tutorial achieves movement through space through the body cavity of the frog but the frame remains steady and does not move. Instead, the path of progress is in the direction of the frog’s inward parts and the "blocks" to progress are flaps of skin, muscles, and organs. The direction of the path of movement is into the frog. The frame of view maintains the user’s orientation with respect to this cavity. The inherent language within the Frog Dissection Tutorial is more of a procedural language – applicable to a tutorial package when tasks should be completed in a specific order.

These differences, though subtle, have a substantial effect of this on the user language employed in each product and increase the importance of certain kinds of controls in each software package. In Harry Potter, the well-timed use of movement and "gate opening" controls is paramount since the goal is navigation throughout a large, virtual space. In the Frog Dissection On-Line Tutorial the instrument selection controls, e.g., scalpel, forceps, etc., at the correct time and in the acceptable sequence is most important as well as the application movement for each selected instrument.

The list of the terms that exist within the Interactive Frog Dissection On-line Tutorial are very different that the terms listed in Harry Potter; however, both sets are essential to the use of the program. Without understanding these terms, one cannot use the program efficiently or effectively. Often developers are so encompassed by the design of the product that they do not realize the importance of the user language that allows the product to actually be used. Many do not even contemplate its existence. "The same technology that simplifies life by providing more functions in each device also complicates life by making the device harder to learn, harder to use. This is the paradox of technology" (Norman, p.31).

Norman suggests that when developing an instructional product all of the following should be included in its user language:

The concept of affordances mentioned previously is related to these criteria: an affordance must be visible, must correspond with the conceptual model of the use, and must map well between user intent and that model. Affordances are the "perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used" (Norman, p. 9).

An evaluation of how Harry Potter and the Interactive Frog Dissection On-Line Kit include each of these concepts is described in Table 3. Scores based on our subjective evaluation tell how well each tool measured up to Norman’s criteria.

With this better understanding of embedded user languages, we can examine an example of a testing system, called Netest, developed at Utah State University to administer the Computer and Information Literacy (CIL) tests. Using Norman’s criteria and lessons learned from Harry Potter and the Frog Dissection On-line Tutorial, we will question the appropriateness and use of the current embedded control language within the Netest software package. The audiences who use Netest understand computers on a very basic level. Nevertheless, these users must be able to completely understand the embedded control languages and administrative languages used within the testing system. Communication is essential since lack of communication could interfere with the user being able to pass the CIL test and it cannot be determined if the student did not pass the test because he/she did not possess the necessary computer skills or the software did not contain the correct affordances, visibility, mappings, and feedback necessary to communicate effectively with the user.

In order to apply Norman’s principles and lessons learned from the comparison made in this paper to the Netest interface, we must first evaluate the nature of the existing software package. Under the current configuration of Netest, students first log in to the system and select an option indicating they want to begin taking a specific test (which has been unlocked by a consultant). Before beginning the actual test, the testing interface is displayed for the user with instructions to explain to students how to use this testing interface. A screen shot of the current explanation is shown in Figure 1.

Instructions are given in the top, scrolling window. The test controls are shown as buttons at the bottom of the screen.

After a student begins the test (by clicking on the "Click Here to Begin Test" button), he/she is presented with test questions one at a time. Figure 2 shows an example of how multiple-choice questions appear in the current version of Netest. Directions specific to answering a question are given midscreen, answer choices are below, and, buttons at the bottom control navigation through the test. Using the test navigation controls the user moves sequentially through an unknown number of test items. There is no choice other than to follow this sequence, despite the fact that the tests can contain more than one hundred items.

Under this current configuration of Netest, the control language is problematic. Some aspects of this screen speak a well-defined and understood procedural language to some "experienced" users, i.e., "First," "Previous," "Next" and "Last" buttons. What about those users who have not been exposed to this language in a prior setting? It is assumed that "Done," "Go To," and "Status" are also understood by most users. In this interface the most confusing issue is the expected understanding of "Browse Answered," "Browse Unanswered," and "Browse All." The most experienced user struggles with the functions of these buttons. The implicit meaning of these terms is not inherently understood. Users must read, remember, and understand the instructions on the instruction screen that were presented at the beginning of the test in order to comprehend the use of the "Browse Answered" et al. buttons. This interface falls short in Norman’s areas of a good conceptual model and good mappings. Furthermore, as stated previously, Norman maintains that when instructions must be presented, then the design has failed. For us, this means that the terms in this control language are not well defined because they must be explained to the student.

More importantly, this interface lacks the whole concept of the virtual space of the test. The student does not know how many total questions will be asked or what type of questions (multiple choice, true/false, etc.) will be asked following this question. Additionally, each question has a corresponding point value. It would be in the students’ best interest to answer the questions worth the most points if a time constraint was included with the test. The entire test is not presented to students at the onset. Questions are presented sequentially and come as a surprise to the student. This methodology neglects the virtual space in which the test exists. This space would include the full layout of the test, every test question, their types and attributes.

Previously, we examined a procedural (tutorial) package (the Frog Tutorial) and a virtual space package (Harry Potter). The evaluation of the imbedded user languages within these packages provides insight and guidelines as we begin to design the new version of Netest. The goal is to include a better user language within the package. In the current version the test space was misrepresented. If the interface is a procedural or tutorial type software, then the navigation throughout the package should be systematic and a specific order must be followed. The user must understand what tasks are available and required and how each should be performed by the way the interface is presented. Furthermore, if the interface is similar to the Harry Potter adventure, the user should "see" all of the available choices at any given moment within the environment. The options should be available and obvious for users to traverse through the virtual space.

We argue that the Netest interface is both a navigation through a space and yet, procedural in nature. When a test is presented, the student should be able to see the "whole picture" of the test, e.g., all of the questions, their type and attributes, so the student envisions what the entire test looks like. Additionally, given that the test is also procedural, a specific navigational track is suggested. Thus, the terms used to navigate through the test environment must be presented to the user in a manner conducive to definitions described by Norman.

The programming team for Netest is currently undergoing a major revision and many new design concepts are being considered. We have reconceived the test space. The new test interface shares characteristics of the frog and Hogwarts Because of the research involved with writing this paper, the procedural and virtual space interface concepts learned are included within the new testing program. A sample model derived from these ideas is shown in Figure 3. (The new version is currently being programmed and a final graphic is not available at this time.)

Due to the influence of Norman and the understanding of embedded user languages, a revised page layout and operation allowing for virtual space and procedural languages will be included in the updated version of this testing program. Netest will have a more well-defined interface and, therefore, be a much better product.

When developing instructional products, according to Norman, instructional designers should:

1. Understand the causes of error and design in order and minimize those causes.

2. Make it possible to reverse actions – to "undo" them – or make it harder to do what cannot be reversed.

3. Make it easier to discover the errors that do occur, and make them easier to correct.

4. Change the attitude toward errors. Think of an object’s user as attempting to do a task, getting there by imperfect approximations. Don’t think of the user as making errors; think of the actions as approximations of what is desired. (p. 131)

 

The design of the instruction must change over time. The languages that users embrace today will not be the ones of tomorrow, but serve as a foundation for future languages. New user languages are being developed as new technology and designs arise. Often these updated languages are developed out of need. When existing "words" to do not adequately describe the desired meaning, a new word is created. It is essential instructional designers become aware and stay abreast of evolving languages so restructured languages can properly be implemented into new instructional products. The Netest programming team is cognizant of the lacking terms in its existing product and is currently developing new terms to render its embedded language more effective for the audience intended.

"The world is permeated with small examples of good design, with the amazing details that make important differences in our lives. Each detail was added by some person, a designer, carefully thinking through the uses of the device, the ways that people abuse things, the kind of errors that can get made, and the functions that people wish to have performed" (Norman, p. 28). These same "good" designers possess a realization and understanding of the embedded user language, thus ensuring complete communication between the product and its user.

Electronic Arts. (2001) Harry Potter and the Sorcerer’s Stone. Redwood City, CA: EA Games.

 

Gibbons, A., (unpublished manuscript) Chapter 3: Design Languages.

 

Gomm, S., Cooley, D. (2002) Netest. Logan, UT: Utah State University.

 

Kinzie, M. (1994) The Interactive Frog Dissection. Retrieved on November 4, 2002 from http://teach.virginia.edu/go/frog.

 

Norman, D. (1990). The Design of Everyday Things. New York: Doubleday.

 

Schrage, M. (2002). Ease of Learning. Technology Review. December 2002/January 2003, p. 23.