February 28, 2002, Illini Union Banquet Hall
Topic: Interface Design and Over-the-Shoulder Learning (OTSL)
Guest: Professor Mike Twidale of the Graduate School of Library and Information Science (UIUC)
Twidale began his presentation with a challenge by asking luncheon participants to identify the object in a black and white picture that appeared to be very amorphous. No one could identify the object. He then handed out the same picture but with the object outlined and everyone then immediately exclaimed, “Oh!” because they could then see what the object was. This was Twidale’s way of creatively illustrating the complex challenge faced by interface designers: “You as designers know the trick, but for the user, it’s impossible to figure out.” He also pointed out that once you’ve seen the object, it’s impossible NOT to see it. In the same way, once you know how a system operates, it seems natural to you and you forget that others don’t know how.
During the accelerating emergence of technology into mainstream culture, computer scientists were faced with the dilemma of making computers usable and accessible to consumers. Prior to this period, computer science experts were writing programs for other computer science experts and, therefore, did not design systems that catered to the nascent user communities. Unfortunately, computer scientists were unaware of this fact and were having a difficult time understanding why these user communities couldn’t “get it.” Twidale pointed out that this same “blindness” happens to all of us. Library catalogues designed by library cataloguers often fail to adequately keep the end-users in mind. The problem continued with automation of catalogues (online catalogues).
Usability specialists came in to sensitize computer scientists and other interface designers to help them see through the eyes of their intended users. Some of the things usability specialists pointed out as areas to watch were:
Language – Jargon: Terms like “Default,” “RTF,” “control-alt-delete,” “UNIX,” “LC,” “MARC,” “Charge” are familiar to those in the industry but totally foreign to others. Twidale pointed out that terms can be 1) incomprehensible gibberish or 2) have a common meaning and an expert meaning. For example, the term “charge” in certain contexts means that one has to pay for an item; but “charge” in the UIUC’s online catalog means that a book is being checked out freely with no payment requirement. The term “default” means totally different things in the fields of computer science and accounting.
A solution to this problem is to use language that everyone understands. Another problem arises when information systems are designed around existing organizational structures. For example, certain people close to the administration may be familiar with where the purchasing department falls within the hierarchy; but others may not. A web site that mirrors the organizational structure will be unhelpful to outsiders, so providing an organizational chart would be helpful when referring someone to a particular department. There should also be many links to the same thing to accommodate different paths of thinking in various user groups.
User Groups: There are end-users who are librarians, end-users who are non-librarians (e.g., students), web page designers and so forth. All too often, Twidale points out, the interface designer can be very egocentric (“me telling the world”) by putting up everything they think users should know about.
A solution to that challenge in meeting user information needs is to look to someone outside of the organization to assess what it is they really want to know about.
To do good web design one must:
- Think who the intended users are
- Ask how much these users know
- Ask, “Can I assume how much they know?”
- Ask, “Is it okay to just assume?”
Twidale cautions against over-reliance on “help pages” or “training” to get people through the interface because a huge requirement for use of them is almost an admission in defeat for web pages that are really efficient & usable.
We should watch people use the web and note their browsing tendencies. Studies have already found that people
- have short attention spans
- have low frustration tolerance
- skim web pages
Web sites like Amazon and Google are successful not necessarily because they offer different services but because they make it EASY TO USE. When they add features to their sites those features do not get in the way of what was there previously.
There are always trade-offs in interface design. We are trying to optimize not one but many things at the same time. It is not a matter of a “perfect solution” but of “what I can do within the limits of time, money and knowledge.” The design must be both easy and efficient, and there’s a constant struggle to achieve balance.
All in all, the design should be done from the perspective of the USERS’ priorities. A test of how efficient we are is to do a “digital world versus physical world” analysis. Take, for example, a letter from the CEO. In the digital world, that link might be on the home page. But in the real world, one would not walk into the reception of a building and be offered a letter from the CEO. It does not make sense. What is important to those internally might not be important to those visiting the site. We can turn to physical world scenarios to shed light on the sensibility of digital world construction.
A question & answer/discussion period followed where luncheon participants raised issues and concerns in UIUC and departmental web design. Twidale emphasized that, “We are not trying to produce the perfect system because priorities will change. We are trying to reduce the number of mistakes the user could make. A small change from 50-40 mistakes can make a huge difference.” For example, changing the name on a button to cancel located in the same spot where the user once pressed to submit can lead to a large increase in mistakes. But simply placing a cancel button on the opposite end of the screen and leaving the submit button in the original place can cut down those mistakes tremendously.
Over-the-Should-Learning (OTSL)
Most people do not learn on their own or by a manual but by asking someone next to them. While this seems obvious, there has never really been a study of how OTSL can be made better. Twidale and other partners are studying this spontaneous help giving and learning patterns in various settings, including businesses and libraries.
How does this apply to user education?
Different people have different knowledge sets. Like a jigsaw puzzle, some people catch on to this piece while others may catch on to other pieces of the learning material. Therefore, instructors can allow people to work together, letting them know it is “not cheating.”
Some individuals learn more by observing. Some are very sensory. Some are more analytical. So under this circumstance, an OTSL unit could be comprised of split roles where 1) points and clicks on the keyboard 2) one observes why the exercise is being done and 3) why the exercise is needed in the big picture in the first place.
The instructor can also help students learn by externalizing what students are supposed to know. One method is to help students “see” what they have just done by drawing out the sequence of steps in the learning/logic path.
On a web page, instructors and designers can be careful to avoid overwhelming individuals with too much text on the home page by just providing an overview and then adding links that can be expanded at the user’s option.
In conclusion, Twidale discourages pre-devised tests to evaluate what people can do because the test in itself can be biased (the developer invents a feature that real users don’t want and then the test has an implicit bias to force the use of that same feature). Instead, he encourages those in user education to watch what people REALLY do to arrive at what many specialists fail to see as obvious.