To help in the exception process and in the evaluation process, it may be useful to assign different weights to the various rules, indicating which are more important than others. Such weighting will help resolve the trade-offs that are an inevitable part of the design process.
If guidelines are applied in the way described here, there are some significant implications for the role of guidelines in system development. Generally stated guidelines should be offered to designers as a potential resource, rather than imposed as a contractual design standard Smith, It is only specifically worded design rules that can be enforced, not guidelines. Design rules can be derived from the guidelines material, but that conversion from guidelines to rules should be performed as an integral part of the design process, serving to focus attention on critical design issues and to establish specific design requirements.
Once agreed design rules are established, those rules can be maintained and enforced by the managers of system development projects. Specific design rules probably cannot be imposed effectively at the outset of system development by some external agency -- by a sponsoring organization or by a marketing group.
It is the process of establishing design rules that should be imposed, rather than the rules themselves. A software design contractor might reasonably be required to establish rules for the design of user interface software, subject to review by the contracting agency.
Available guidelines could be cited as a potentially useful reference for that purpose. Some other cautionary comments about the application of guidelines deserve consideration here.
Guidelines in themselves cannot assure good design for a variety of reasons Thimbleby, Guidelines cannot take the place of experience. An experienced designer, one skilled in the art, might do well without any guidelines. An inexperienced designer might do poorly even with guidelines.
Few designers will find time to read an entire book of guidelines. If they do, they will find it difficult to digest and remember all of the material.
Guidelines cannot take the place of expert design consultants, or at least not entirely. A design expert will know more about a specific topic than can be presented in the guidelines. An expert will know what questions to ask, as well as many of the answers. An expert will know how to adapt generally-stated guidelines to the specific needs of a particular system design application. An expert will know how to trade off the competing demands of different guidelines, in terms of operational requirements.
For maximum effectiveness, guideline tailoring must take place early in the design process before any actual design of user interface software. In order to tailor guidelines, designers must have a thorough understanding of task requirements and user characteristics.
Thus task analysis is a necessary prerequisite of guidelines tailoring. The result of guidelines application will be a design for user interface software that may incorporate many good recommendations. However, even the most careful design will require testing with actual users in order to confirm the value of good features and discover what bad features may have been overlooked.
Thus prototype testing must follow initial design, followed in turn by possible redesign and operational testing. Indeed, testing is so essential for ensuring good design that some experts advocate early creation of an operational prototype to evaluate interface design concepts interactively with users, with iterative design changes to discover what works best Gould and Lewis, But prototyping is no substitute for careful design.
Prototyping will allow rapid change in a proposed interface; however, unless the initial design is reasonably good, prototyping may not produce a usable final design. Considering the system development process overall, guidelines application will not necessarily save work in user interface design, and in fact may entail extra work, at least in the initial stage of establishing design rules.
But guidelines application should help produce a better user interface. Because guidelines are based on what is known about good design, the resulting user interface is more likely to be usable. Certainly the common application of design rules by all designers working on a system should result in more consistent user interface design. And the single objective on which experts agree is design consistency.
Anyone involved in compilation of design guidelines must begin and end by acknowledging the significant contributions of other people. No one person, no matter how wise, can know everything about the complexities of user interface design. Nor will any one person have the perfect judgment and find the perfect words to express that knowledge to an interface designer.
Thus when we propose guidelines we must build upon the work of others. That is a good thing. All design guidelines are necessarily based in some degree on judgment. Thus guidelines development must properly be a collaborative effort. The collective judgment of many people will often prove sounder than the ideas of just one person. When many people contribute to guidelines development, we must find ways to acknowledge that contribution. One way is to cite previously published papers that pertain to the guidelines.
Citations in this report are represented in the reference list that follows. But in the next several pages we also try to acknowledge more direct contributions to our work. Many of the user interface design guidelines proposed in this report were not invented here, but derive from the ideas of other people. Where the idea for a guideline came from a particular source, an appropriate reference citation has been included for that guideline. Such citation offers credit where credit is due.
More importantly, cited references may permit a reader who questions a particular guideline to explore its antecedents, perhaps to gain a better understanding of what is intended. Citing an external reference in connection with a guideline does not necessarily mean that there is convincing data to support a guideline. Although the references cited here all contain worth-while ideas, only some of these references report results from systematic data collection.
Furthermore, citation of references does not necessarily mean that their authors would agree with the wording of guidelines presented here. In some instances, an idea has been borrowed intact. In many more instances, however, ideas have been modified, sometimes drastically, perhaps beyond the intent of their original authors. In this report, in both the text and the guidelines, citations of specific references are in conventional form, showing author s and publication date.
Those references are listed in the pages that follow. The particular format used here for citation and listing of references conforms in most respects to the standard referencing practice recently adopted by the Human Factors Society However, four reference sources are used generally throughout the guidelines. Those sources are cited so frequently that they have been indicated simply by initials:. These four general references share a common characteristic -- like this report, they are all collections of design guidelines.
None of these four general references provide supporting data for their design recommendations, and they need not be consulted for that purpose.
The two early reports EG and PR have served as a fertile source of ideas for our current guidelines; where those reports are cited here, it means that their early recommendations are still judged to be correct.
The two more recent reports BB and MS have drawn heavily from common sources, including previous editions of the guidelines proposed here; where those reports are cited, it means that their authors have made similar recommendations to those presented here. That report has provided inspiration and has served as a seminal reference for others working in this field. The BBN report by Pew and Rollins PR represents an admirable attempt to propose design guidelines for one particular system application.
Its recommendations, however, can readily be generalized for broader application. The report by Lin Brown and his colleagues at Lockheed BB is a good example of user interface guidelines developed for use as an in-house design standard, but which have also been made available for public reference. None of these three reports are distributed by government sources such as the National Technical Information Service.
However, these reports may be obtained by direct request from their authors. That standard has been cited here times, for guidelines. It is important to emphasize that guidelines do not carry the same weight as design standards. Guidelines are proposed here for optional application in system development, rather than to be imposed contractually. However, there is some considerable correspondence in content between these guidelines and the current military standard. Not all ideas for guidelines come from published references.
Some of the guidelines proposed here have resulted from discussion with professional colleagues. And the wording of all guidelines has been improved through critical review of earlier published versions. Over the past several years, a number of people have contributed suggestions for improving the guidelines material:. Some of these people have offered specific suggestions. Some have contributed more general comments about the wording or formatting of the guidelines material. But all have shown a serious concern with trying to improve the guidelines and make them more useful to designers of user interface software.
Probably not one of these people would agree with all of the guidelines proposed here; in matters of judgment we can seldom achieve unanimity.
But where the guidelines seem good, these are people who deserve our thanks. Several people on this list deserve extra thanks. Special thanks are due to Nancy Goodwin for her thorough revision of the guidelines on data transmission; to Jeanne Fleming and James Foley for their detailed comments on guidelines proposed for graphics entry and display; and to Dorothy Antetomaso for her review of the guidelines on data security. Special thanks for past contributions are due to Arlene Aucella who helped prepare the guidelines report; and to MITRE supervisor Marlene Hazle for her early encouragement and support of guidelines compilation.
Albert, A. The effect of graphic input devices on performance in a cursor positioning task. Aretz, A. Automatic return in multifunction control logic. Badre, A. Designing transitionality into the user-computer interface. In Salvendy, G. Amsterdam: Elsevier Science Publishers. Barnard, P. Learning and remembering interactive commands in a text-editing task.
Behaviour and Information Technology, 1, Representation and understanding in the use of symbols and pictograms. In Easterby, R. Chichester: Wiley. Bauer, D. The representation of command language syntax. Human Factors, 28, Bertelson, P. Vitesse libre et vitesse imposee dans une tache simulant le tri mechanique de la correspondence Self pacing and imposed pacing in a task simulating automated postal sorting. Ergonomics, 8, Bewley, W.
Human factors testing in the design of Xerox's "Star" office workstation. New York: Association for Computing Machinery. Bigelow, C. Billingsley, P. Navigation through hierarchical menu structures: Does it help to have a map? Bruder, J. User experience and evolving design in a local electronic mail system.
In Uhlig, R. New York: North-Holland. Bury, K. Windowing versus scrolling on a visual display terminal. Human Factors, 24, Butterbaugh, L. Evaluation of alternative alphanumeric keying logics. Campbell, A. Reading speed and text production: A note on right-justification techniques.
Ergonomics, 24, Carroll, J. Learning, using and designing filenames and command paradigms. Chao, B. Evaluation of a video storage system for intrusion detections. Cleveland, W. The Elements of Graphing Data. Cohill, A. Retrieval of HELP information for novice users of interactive computer systems. Human Factors, 27, Department of Defense Password Management Guideline.
Fort George G. Deutsch, D. Design of a message format standard. Implementing distribution lists in computer-based message systems. In Smith, H. Dray, S. Measuring performance with a menu-selection human-computer interface. Duchnicky, R. Readability of text scrolled on visual display terminals as a function of window size. Human Factors, 25, Dunn, C. The use of real-time simulation by means of animation film as an analytical design tool in certain spatio-temporal situations.
Ergonomics, 16, Durding, B. Data organization. Human Factors, 19, Dzida, W. Computer mediated messaging for interactive purposes. Ehrenreich, S. Query languages: Design recommendations derived from the human factors literature. Human Factors, 23, Computer abbreviations: Evidence and synthesis. Abbreviations for automated systems: Teaching operators the rules. Badre and B. Shneiderman Eds.
Norwood, NJ: Ablex Publishing. Elkerton, J. Strategies of interactive file search. Foley, J. Fundamentals of Interactive Computer Graphics. Reading, MA: Addison-Wesley. The art of natural graphic man-machine conversation. Proceedings of the IEEE, 62, The human factors of computer graphics interaction techniques. Gade, P. Data entry performance as a function of method and instructional strategy. Galitz, W.
Human Factors in Office Automation. Garcia-Luna, J. Addressing and directory systems for large computer mail systems. Geer, C. NTIS No. AD A Geiser, G.
Talking keyboard for user guidance in multifunction systems. Gilfoil, D. Warming up to computers: A study of cognitive and affective interaction over time. Good, M.
Building a user-derived interface. Communications of the ACM, 27, Goodwin, N. Cursor positioning on an electronic display using lightpen, lightgun, or keyboard for three basic tasks. Human Factors, 17, A user-oriented evaluation of computer-aided message handling. Effect of interface design on usability of message handling systems. Designing a multipurpose menu driven user interface to computer based tools. Building a usable office support system from diverse components. In Shackel, B.
Gould, J. Composing letters with computer-based text editors. Doing the same work with hard copy and with cathode-ray tube CRT computer terminals. Human Factors, 26, Designing for usability -- Key principles and what designers think.
Granda, R. The effect of VDT command line location on data entry behavior. Gregory, M. Even versus uneven right-hand margins and the rate of comprehension in reading. Ergonomics, 13, Grudin, J. The cognitive demands of learning and representing command names for text editing. Hakkinen, M. Synthesized warning messages: Effects of an alerting cue in single- and multiple-function voice synthesis systems.
Hamill, B. Experimental document design: Guidebook organization and index formats. Hannemyr, G. A network user interface: Incorporating human factors guidelines into the ISO standard for open systems interconnection. Behaviour and Information Technology, 4, Hanson, R. Process control simulation research in monitoring analog and digital displays.
Hartley, J. On the typing of tables. Applied Ergonomics, 6, Haskett, J. Pass-algorithms: A user validation scheme based on knowledge of secret algorithms. Hayes, P. A panel on the utility of natural languages. Hirsh-Pasek, K. An experimental evaluation of abbreviation schemes in limited lexicons. Hollingsworth, S. Implications of post-stimulus cueing of response options for the design of function keyboards. Hopkin, V. Keister, R. Making software user friendly: An assessment of data entry performance.
Koved, L. Embedded menus: Selecting items in context. Communications of the ACM, 29, Lee, A. Enhancing the usability of an office information system through direct manipulation. Liebelt, L. The effect of organization on learning menu access. Limanowski, J. By kayla knight in articles on january 21, Facebook Twitter. Search This Blog. Powered by Blogger. January 7 December 10 November 14 October 16 September Report Abuse. Spacing between two controls is important. The following screen shot demonstrates a poorly designed User Information entry form—the top two text boxes are too close, the list under them is too far away, and there is a lot of unused room on the form.
In the following screen shot, you can see a more professional-looking dialog with proper spacing and appropriately sized controls. This is the same form as in the previous screen shot, but it was modified to use the spacing recommended by the SnapLines. It is always recommended to align a label with the text baseline of the textbox or other control next to it, rather than the actual bottom border of the control.
The SnapLines turn a different color when that alignment is reached, usually just a few pixels above the bottom border. While there are no exact rules for spacing, the SnapLines provide extremely useful guidelines for proper spacing. Other tools to help you keep proper spacing are the Layout controls under the Containers toolbox group. The TableLayoutPanel is also very helpful for creating entry form style dialog boxes.
The same considerations apply to size. When you drag a button from the toolbox on to your form—it has the perfect height and width. The maximum width recommended barring any seriously important reasons is to double the original width. If you look at the Run window on the Start menu, or the Properties dialog of any Windows Explorer object, the button sizes are 'just right'.
If you have a very important function that you need your end user to notice without fail, there are other methods than using a large button or garish non-standard colors more on that later. In the following image, you can see three buttons. The first button is the most recommended size and is the size created by default when dragged or double-clicked from the toolbox.
Sometimes extra text requires you to make the button larger. The second button shows a large yet acceptable size. It would not create a mess for laying out other controls. The third button, however, is a completely unacceptable size. You can see that it even slightly distorts the theme bitmaps Windows uses to draw themed controls.
It will also make it hard to align other controls intuitively around it. Typically, an application contains many controls. Only by proper, intuitive grouping can you make all these controls easier to use. Function-based or categorized grouping is done best by Tab controls. For example, 'Accounts,' 'Reports,' 'Employees,' and 'Projects' would be perfect candidates for tabs in a typical business application. Sibling grouping—controls that contribute to the same end result—are best done by Group controls.
Using Panels with borders for such grouping is not recommended. Group controls save you the extra weight of a label control—especially if your sub-controls are self-explanatory. Group controls inside Group controls are not recommended unless there are no more than 2 or 3 of them inside one large Group control. This is the most important aspect of a great user experience. Intuitive UX lessens the need for explanations.
The user just knows what the controls do. An important topic in intuitive design is color-coding. A good example is presented in Windows XP which presented new soft-square buttons for functions such as navigation in themed applications, the Log Off and Turn Off Computer dialogs, and others. The coloring of these controls was determined based upon the severity of the result of that button being pushed.
Navigation is green, much like a 'Go' traffic light. Shut Down, which would result in a potential loss of work, is colored red like a warning sign. Semi-critical buttons such as Log Off or Hibernate are yellow. Neutral buttons that do not have any critical effects on the work processes of the user, such as Help, are a soft blue. When creating a skinned UI, these color aspects should be kept in mind.
A very good example of recognition of content by colors is Microsoft Office OneNote. The application's tabs can be set to different colors while still looking essentially like a proper part of the overall Windows XP style design. Another important aspect is the text in your applications. Recently, there have been various efforts to simplify the language used for the written instructions in Windows software.
The usage of text inside software will be discussed later, but please note the following small but important detail. In a recent version, they changed it to "My Webcam: Allow others to see that I have a webcam". This is perfect for the target audience that may not have technical knowledge and are used to simple language. While simpler language makes it easy to understand, there's also an added advantage. Scientific studies show that our mind works easier with simpler language when trying to understand something new.
Often, our brain processes words like 'it,' 'for,' 'that,' and other common words so speedily and effortlessly that more 'bandwidth' is allocated to understanding the words that stand out, like 'Webcam' or 'Others,' in the above example. Message Box titles, GroupBox captions, and other such text blocks make it easy for you to convey the function of a group of controls to the end user with just a few words. Intuitiveness is also born from familiarity. For example, the placement of the OK and Cancel buttons is so uniform and well placed in our minds that if a dialog holds these buttons in a reverse sequence Cancel , then OK ; instead of OK , then Cancel —you just might hit Cancel instead.
After using a particular standard for doing things—Windows-based applications for example—for more than a year, habits develop. Following industry standards however unstated they may be makes your software easier to use. In one of the early Windows Vista preview builds, the Minimize , Maximize , and Close buttons of any window became different.
In previous versions of Windows especially when using a single monitor , you develop a habit of moving the cursor in the top-right corner of the screen and clicking. This always resulted in the window closing. Now in this particular build of Windows Vista, there were approximately 8 pixels worth of space between the Close button and the right-most border of the window.
The extra space did make it look cool and was probably necessary for the cool glow animation the button sported , but was irritating because it did not allow users to close open windows as easily. Reconditioning your mind can be tough. Thankfully, in the following build, this issue was addressed.
Now, there still is space between the border of the window and the close button, but clicking that space also causes the window to be closed. A very important factor of intuitive design is the amount of 'mental bandwidth'—the amount of time it might take our mind to comprehend something—it uses.
The lower the 'bandwidth' usage, the better your user experience. These are small things that contribute to the "experience" of using a software application.
The following examples provide tips on improving your applications with real-world tips and tricks. The goal of a better user experience is to have a simpler, easier, functional UI that also looks good. These tips will help you shape your UI to be more effective. The established standards of any software environment—whether on the operating system level, brand level, or application level—are very important.
Besides the branding, the standards act as a proverbial schema in the user's mind. When the user spends long periods of time working with a software application, he or she will automatically increase productivity because of the growing familiarity. Before discussing standards, let's first discuss what exactly these standards are.
The standards include everything from the layout of controls in a particular manner on the dialog boxes—like the OK and Cancel buttons, the user interface's shape—rounded-corners of the top of the window as in Windows XP dialogs, styles of icons, styles of any other graphics, interactive behavior of your application, and the like.
If your application falls into a specific niche, then it may fare better to follow a different set of standards. For example, if your application supports, application or an add-on for, Office OneNote , it is wise to follow the styles of UI and interactivity standards of Office—and OneNote itself, in particular. This includes using the Office-style command bars instead of the standard toolbars, and other such things— both visual and behavioral. If your application is to be part of the Microsoft Visual Studio.
NET category, then you have a separate set of standards. In fact, for such add-on or support applications, companies such as Microsoft do release written guidelines. Also note that sometimes graphics and design concepts are protected intellectual properties.
Always check the proper documentation to make sure you have the license to create such designs. A third example of standards would be the Tablet PC environment. These standards cross the boundaries between operating system guidelines and application guidelines. In contrast to theOffice or Visual Studio guidelines, these design recommendations directly affect how the user will interact with your application and how it should behave in turn. For instance, if you have docking windows in your application, the documentation recommends that you make sure it can detect when the screen orientation is changed, and that the docking windows properly reorganize themselves in a portrait or landscape orientation as needed.
Even if you are not designing your application to be Tablet-specific, you should go over these guidelines. Each situation calls for a different or additional set of standards to be followed. When applications share the operating system-level or application-level standards, the users feel more at home with the software, which makes it easier to learn and use. This results is a direct boost to productivity.
Users want to be able to become productive with new software as quickly as possible. Sometimes you need to direct the user to the most important buttons even when you have four or five other buttons lying around it.
If you experiment with the size, color, or font, you would break standards—which is not recommended. Instead, you can use a couple of simple tricks to accomplish this. The first is to convert the other non-critical buttons into LinkLabels as shown in the following image. This way, the user knows that these links will perform a task, but their attention will go first to the button that stands out—without breaking standard design guidelines.
The second is to put the critical button first in line—either on the left for horizontal layouts as shown in the following image, or on top for vertical layouts. Do note that this may change depending on the target user's culture—you may fare better if you place the button in question on the far right if your application is any language that is written from right-to-left. The recommended option is to set to receive focus by default.
For example, on a delete confirmation dialog, the No option should be highlighted, as this prevents the user from accidentally deleting something. Icons—especially the Windows XP and Office icons and toolbar bitmaps—help speed up cognition of the UI and the task the user has to perform. For example, when you see the exclamation icon most often seen on the Message Box, you instantly become aware of the level of risk associated with the controls next to that icon.
Similarly, when your application puts up a lot of controls—no matter how properly arranged—it can be daunting to find the set of controls you are looking for. There are four options present—automatically download updates, download updates but let the user decide when to install them, notify the user if updates are available but do not start download, and disabling automatic updates completely. A new PC user may not be aware of what these updates are and might not know which option would be best to choose.
So, Microsoft has put a green shield icon with a big check mark on it next to the most recommended that signifies a "safe" option, and a red shield icon with a big "x" on it next to the one that would be potentially harmful to the user. This is very helpful in critical situations—especially when the user does not have time to read too much text.
In the same System Properties applet, each tab has multiple GroupBoxes with different controls for different tasks. A relative graphic is placed next to each group that would easily signify the task of the control group.
0コメント