User Interface Design and Ergonomics - National Open University of ...

More documents

Recommendations

Info

This example brings up an important point about using the example tasks. It's important to remember that they are ONLY EXAMPLES. Often, as in this case, a decision requires you to look beyond the specific examples you have and make a judgement about what will be common and what will be uncommon. You can't do this just by taking an inventory of the specific examples you chose. You can't defend a crummy design by saying that it handles all the examples, any more than you can defend a crummy design by saying it meets any other kind of spec. We represented our scenarios with STORYBOARDS, which are sequences of sketches showing what the screen would show, and what actions the user would take, at key points in each task. We then showed these to the users, stepping them through the tasks. Here we saw a big gain from the use of the sample tasks. They allowed us to tell the users what they really wanted to know about our proposed design, which was what it would be like to use it to do real work. A traditional design description, showing all the screens, menus, and so forth, out of the context of a real task, is pretty meaningless to users, and so they can't provide any useful reaction to it. Our scenarios let users see what the design would really give them. "This sample task idea seems crazy. What if you leave something out? And won't your design be distorted by the examples you happen to choose? And how do you know the design will work for anything OTHER than your examples?" There is a risk with any spec technique that you will leave something out. In choosing your sample tasks you do whatever you would do in any other method to be sure the important requirements are reflected. As noted above, you treat the sample tasks as examples. Using them does not relieve you of the responsibility of thinking about how other tasks would be handled. But it's better to be sure that your design can do a good job on at least some real tasks, and that it has a good chance of working on other tasks, because you've tried to design for generality, than to trust exclusively in your ability to design for generality. It's the same as that point about users: if a system is supposed to be good for EVERYBODY you'd better be sure it's good for SOMEBODY. 3.4 CREATING THE INITIAL DESIGN The foundation of good interface design is INTELLIGENT BORROWING. That is, you should be building your design on other people's good work rather than coming up with your own design ideas. Borrowing is important for three distinct reasons. First, given the level of quality of the best user interfaces today, it's unlikely that ideas you come up with will be as good as the best ideas you could borrow. Second, there's a good chance, if you borrow from the right sources, that many of your users will already understand interface features that you borrow, whereas they'd have to invest in learning about features you invent. Finally, borrowing can save you tremendous effort in design and implementation and often in maintenance as well. 3.4.1 WORKING WITHIN EXISTING INTERFACE FRAMEWORKS 74
The first borrowing you should do is to work within one of the existing user interface frameworks, such as Macintosh, Motif or Windows. The choice may have already been made for you: in in-house development your users may have PCs and already be using Windows, or in commercial development it may be obvious that the market you are trying to reach (you've already found out a lot about who's in the market, if you're following our advice) is UNIX-based. If you want to address several platforms and environments you should adopt a framework like XVT that has multi-environment support. The advantages of working in an existing framework are overwhelming, and you should think more than twice about participating in a project where you won't be using one. It's obvious that if users are already familiar with Windows there will be big gains for them if you go along. But there are also big advantages to you, as mentioned earlier. You'll get a STYLE GUIDE that describes the various interface features of the framework, such as menus, buttons, standard editable fields and the like. The style guide will also provide at least a little advice on how to map the interface requirements of your application onto these features, though the guides aren't an adequate source on this. This information saves you a tremendous amount of work: you can, and people in the old days often did, waste huge amounts of time designing scroll bars or ways to nest menus. Nowadays these things have been done for you, and better than you could do them yourself. You also get SOFTWARE TOOLS for implementing your design. Not only does the framework have an agreed design for menus and buttons, but it also will have code that implements these things for you. We will discuss implementation in Module 3. 3.4.2 COPYING INTERACTION TECHNIQUES FROM OTHER SYSTEMS Another kind of borrowing is copying specific interaction techniques from existing systems. If the style guides were good enough you might not have to do this, but the fact is the only way to get an adequate feel for how various interface features should be used, and how different kinds of information should be handled in an interface, is to look at what other applications are doing. The success of the Macintosh in developing a consistent interface style early in its life was based on the early release of a few programs whose interfaces served as models of good practice. An analogous consensus for the IBM PC doesn't really exist even today, but as it forms it is forming around prominent Windows applications like Excel or Word. It follows from the need to borrow from other applications that you can't be a good designer without becoming familiar with leading applications. You have to seek them out, use them, and analyze them. The key to "intelligent" borrowing, as contrasted with borrowing pure and simple, is knowing WHY things are done the way they are. If you know why an application used a tool palette rather than a menu of functions, then you have a chance of figuring out 75
Page 1:
] NATIONAL OPEN UNIVERSITY OF NIGER
Page 4 and 5:
National Open University of Nigeria
Page 6 and 7:
Summary ...........................
Page 8 and 9:
UNIT 3 - GRAPHICAL USER INTERFACE (
Page 10 and 11:
Assignments File Tutor-Marked Assig
Page 12 and 13:
2 DESIGN and DESIGNING GOOD USER IN
Page 14 and 15:
need both the study unit you are wo
Page 16 and 17:
CIT 711: USER INTERFACE DESIGN AND
Page 18 and 19:
UNIT 1 FUNDAMENTALS OF USER INTERFA
Page 20 and 21:
3.3 TYPES OF USER INTERFACES Curren
Page 22 and 23:
3.5 USER INTERFACE MODALITIES AND M
Page 24 and 25: Table of Contents 1.0 Introduction
Page 26 and 27: 3.1.1 DESIGNING A GOOD USER INTERFA
Page 28 and 29: widgets properly is to read and und
Page 30 and 31: Figure 1:- Showing that alignment o
Page 32 and 33: 6.0 TUTOR MARKED ASSIGNMENT a. How
Page 34 and 35: A graphical user interface is a typ
Page 36 and 37: Operating System. It is easy for a
Page 38 and 39: A list of items from which to selec
Page 40 and 41: collaborative work. For example, sc
Page 42 and 43: MODULE 1 UNIT 4 HUMAN COMPUTER INTE
Page 44 and 45: 3.3 DIFFERNCES WITH RELATED FIELDS
Page 46 and 47: window blinds to automobile braking
Page 48 and 49: Wickens, Christopher D., John D. Le
Page 50 and 51: The International Ergonomics Associ
Page 52 and 53: approach, the Gilbreths reduced the
Page 54 and 55: 3.6 BENEFITS OF ERGONOMICS The thre
Page 56 and 57: Another key to reducing lumbar disc
Page 58 and 59: MODULE 2 - USER INTERFACE DESIGN TE
Page 60 and 61: methods include inspection methods,
Page 62 and 63: Determine time of each operation (b
Page 64 and 65: unable to understand new informatio
Page 66 and 67: M cones, or, misleadingly, green co
Page 68 and 69: Motor skill which is a learned seri
Page 70 and 71: MODULE 2 UNIT 2 UNDERSTANDING USERS
Page 72 and 73: The users of a system must be ident
Page 76 and 77: whether you want to have a palette
Page 78 and 79: Task analysis which includes identi
Page 80 and 81: MODULE 2 UNIT 3 USER CENTERED DESIG
Page 82 and 83: or small body text is also hard to
Page 84 and 85: Introduction to User-centered desig
Page 86 and 87: organizations themselves. Interacti
Page 88 and 89: After thorough analysis using vario
Page 90 and 91: Interaction design which is the dis
Page 92 and 93: In human-computer interaction and c
Page 94 and 95: The preferred method for ensuring u
Page 96 and 97: 3.4 ISO STANDARDS FOR USABILITY ISO
Page 98 and 99: In this unit, you have been introdu
Page 100 and 101: affect the way the command is execu
Page 102 and 103: • Guides the user via the predefi
Page 104 and 105: The term direct manipulation was in
Page 106 and 107: There are two important reasons for
Page 108 and 109: 108
Page 110 and 111: UNIT 1 PROTOTYPING Table of Content
Page 112 and 113: Figure 12: The iterative steps of p
Page 114 and 115: select print Figure 13: An interfac
Page 116 and 117: Ambler, S.W. & Constantine, L.L. (2
Page 118 and 119: 3.2 LOW-FIDELITY PROTOTYPES Low-fid
Page 120 and 121: Figure 14:- Example of Sketching II
Page 122 and 123: Much more important for features th
Page 124 and 125:
DENIM, an extension of SILK, is a t
Page 126 and 127:
• Encourage menu & forms style, r
Page 128 and 129:
Another problem is that native widg
Page 130 and 131:
interfaces, so that a realistic sim
Page 132 and 133:
UNIT 3 INPUT AND OUTPUT MODELS Tabl
Page 134 and 135:
Recall that perceptual fusion means
Page 136 and 137:
3.2 OUTPUT MODEL There are basicall
Page 138 and 139:
directly-mapped pixel image will no
Page 140 and 141:
Most stroke models also include som
Page 142 and 143:
UNIT 4 MODEL VIEW-CONTROLLER (MVC)
Page 144 and 145:
3.3.2 AS A DESIGN PATTERN MVC enco
Page 146 and 147:
The Views are XForms controls for s
Page 148 and 149:
UNIT 5 LAYOUTS AND CONSTRAINTS Tabl
Page 150 and 151:
3.5 CONSTRAINTS Constraints are rel
Page 152 and 153:
152
Page 154 and 155:
MODULE 4 UNIT 1 TECHNIQUES FOR EVAL
Page 156 and 157:
a. Card Sorting Card sorting is a w
Page 158 and 159:
Rapid prototyping is a method used
Page 160 and 161:
3.2.1 THE USE OF PROTOTYPES It is o
Page 162 and 163:
Dumas, J.S. and Redish, J.C. (1999)
Page 164 and 165:
the users' respect for you as a pro
Page 166 and 167:
the users will be and what kind of
Page 168 and 169:
speed whenever the average load was
Page 170 and 171:
Table 4:- Table: Average times for
Page 172 and 173:
phases: list the actions, and then
Page 174 and 175:
Nielsen and Molich used their own e
Page 176 and 177:
7.0 REFERENCES AND FURTHER READING
Page 178 and 179:
users. If you do not, you can be ba
Page 180 and 181:
If you are led to develop more and
Page 182 and 183:
It's very easy to shape the comment
Page 184 and 185:
a. Analyzing the Bottom-Line Number
Page 186 and 187:
you use. But then you need some way
Page 188 and 189:
ecruit test users with more similar
Page 190 and 191:
MODULE 4 UNIT 4 OTHER EVALUATION IS
Page 192 and 193:
3.2 CURRENT ISSUES CONCERNING EVALU
Page 194 and 195:
2.0 OBJECTIVES By the end this unit
Page 196 and 197:
It provides a real focal point for
Page 198 and 199:
3.3.4 CONDUCTING THE TEST Having co
Page 200:
The stages involved in usability te
show all

User Interface Design and Ergonomics - National Open University of ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?