GUI design check list

애플사에서 정한 GUI 디자인의 체크항목 이라고 함 ..

OK, so you're an HTML/web designer. Why should you keep reading? Well, with Javascript, embedded Java Applets, and ActiveX, web pages will become more GUI-like as the internet evolves. These checklists can give you an idea of the complexity of design for good GUIs, and many of the questions (for example, about wording dialog questions and buttons) are applicable on the web today. 
 
Portions © 1989, Apple Computer 
Interface Checklist: General considerations

• Does the application have the 'look' of the Windows Interface (including, but not limited to, desktop, windows, and menus)?
• Does the application have the 'feel' of the Windows Interface (including, but not limited to, pointing, selecting, and keyboard input)?
• If a metaphor is being used, is it suitable for the application? Does the metaphor have a 'real' visual and behavioral representation, as with the desktop, so that the users do not have to carry a 'map' in their head?
• Does the application always provide some indication that an activity is being carried out in response to a command?
• Does the user always have the option of finding an object or action on the screen (as opposed to having to remember and type)?
• Are the operations consistent with the standard elements of the interface; that is, if a user is familiar with standard applications, will the application seem like familiar territory?
• Is a printout a replica of what the user sees on the screen (that is, WYSIWYG)?
• Is suitable feedback provided during task processing? Is the completion of a processing task indicated somehow? Is the duration of the task indicated?
• Is an explanation offered if a particular action cannot be carried out? Are alternatives offered?
• Are there warnings about risky actions? Are there different warnings for different levels of risky actions? Are there enough warnings without being too many? Are users allowed to back away gracefully from risky territory?
• Is there a feeling of stability? Are there enough landmarks to remind the user what area of the application he or she is in?
• Can an operation be interrupted? Can Escape be used to cancel an operation that has a Cancel button?

 
Interface Checklist: Graphic design

• Do the commands, features, and parameters of the application, as well as all of the user's data, appear as graphic objects on the screen (as much as possible)?
• Are the graphics believable?
• Does the screen look 'clean' and free from clutter?
• Does the user have control over the design of the workplace, allowing him or her to individualize it?

 
Interface Checklist: Window standards

• Does the standard state of the window seem appropriate in EGA, 4 bit color ? On a larger display (VGA, 8 bit color; SVGA, 16 bit color?) ?
• Does the preliminary user-selected state seem appropriate in EGA, 4 bit color ? On a larger display (VGA, 8 bit color; SVGA, 16 bit color?)?
• Does the choice made to open in either the standard or the user-selected state make sense?
• Can each sizable window be made as large as the smaller of either the maximum document size or the maximum size of the displays?

 
Interface Checklist: Scrolling standards

• Does clicking on a scroll arrow cause the document to 'move' a distance of one unit in the chosen direction? (The unit should be appropriate to the application.)
• Does clicking in the scroll bar below the scroll box advance the document by a windowful? (A 'windowful' is the height or width of a window, minus a one-unit overlap.) Does clicking above the scroll box move the document back by a windowful?
• If the user drags the scroll box and then moves the pointer well outside the scroll bar, does the scroll box snap back to its original position?
• Is the function of the arrow keys different from the function of the scroll bar? (Remember: all these questions should be answerable with 'yes': arrow keys should not substitute for scroll arrows.)

 
Interface Checklist: Dialog box standards 
A modal dialog box is one that the user must explicitly dismiss before doing anything outside it—these boxes should be used sparingly. A modeless dialog box allows the user to perform other operations without dismissing the box first.

• Is the question posed in a straightforward and positive way? For example, 'Do you want to erase everything on this disk?' rather than 'Do you not want to alter the contents of this disk?'
• When appropriate, do buttons have descriptive labels, such as 'Destroy Power Supply' rather than 'OK'?
• Does the default button (if any) have a bold outline around it?
• Does pressing Escape indicate Cancel in a dialog box? (Pressing Escape should never cause the user to lose information.)
• When a command key equivalent is used, does the button highlight?
• Do modal dialog boxes not lead to other modal dialog boxes?
• Do modal dialog boxes that can be moved have a drag region (title bar), as well as the outline within the content region to signify that it is a modal dialog?
• Has room been left to allow the dialog box to grow during localization? Most languages require more characters than English to convey equivalent messages.

 
Interface Checklist: Alert standards

• Do the alert icon and message fit the situation?
• Is a beep alert accompanied by a flash (rapid inverting) of the menu bar so that people who can't hear don't miss the message?
• Does the alert message not only tell the user what is wrong but offer suggestions as to what to do to correct it?
• Is this alert necessary? Often, the user can be prevented from making an error. Example: if the application cannot handle an 80 character file name, don't offer them an 80 character field in which to enter it.

 
Interface Checklist: Menu standards

• Does the menu bar contain only menu titles?
• Are the standard menus—File, and Edit —present, with at least the standard items?
• Is there enough extra room to allow for the expansion that almost always occurs during translation into other languages?
• Do the unique menus of the application have names that are appropriate? Are the names sufficiently different from the standard menu names? Can the user understand and remember their meaning?
• Are frequently used menu items available at the top level rather than in a hierarchical menu or a dialog box? If not, can the user move them up?
• When an item in a menu is currently disabled, is it dimmed in the menu rather than missing from it?
• If all the items in a menu are currently disabled, is the menu title dimmed? Can the user still pull down the menu and see the dimmed names of the operations?
• Are the names of menu items appropriate? Can the user understand and remember their meaning?
• Are menu titles and items in caps/lowercase unless there is a compelling reason to have a different style, such as 'ALL CAPS' in a Style menu?
• Do menu items have an ellipsis (…) if more information is required from the user?
• Do hierarchical titles in a menu have a right-pointing triangle? Are hierarchical menus used only for lists of related items?
• Can the user see all the commands, items, and hierarchical titles in a menu without scrolling? Scrolling should be necessary only for menus that users have added to or for menus that spill over because the user has selected a large system font.
• Is the indication of a pop-up menu a drop-shadowed box around the current value? While the menu is showing, is its title inverted and is the current value checked? If the menu must be scrolled, is this indicated by up- or down-pointing triangles?

 
Interface Checklist: Keyboard commands

• Do keyboard equivalents appear where appropriate? Are the keyboard equivalents case-independent. (This second rule does not apply if the product uses both cases in the keyboard equivalents and enables the user to predict which case to use.)
• Does the application support Undo, Cut, Copy, and Paste?

 
Interface Checklist: Mouse standards

• If the user initiates an action by pressing the mouse button, does the action take place only when the button is released?
• Are there ways other than double-clicking to perform a given action? (power keys, key combinations)

 
Interface Checklist: Programming strategies

• Is there a clear visual indication of the current mode? Does the visual indication of the mode appear near the object most affected by the mode? For example, a paint pointer changes to a pencil in draw mode and to a paint brush in paint mode.
• Is each mode absolutely necessary? Do the modes within the application properly track the user's own modes? Do users consistently avoid the kind of errors caused by the program being in a mode other than what the user wants or expects? Making a mode visually apparent is no guarantee that the user will track it: test the application on users and find out what sorts of mistakes they are making. If the errors are modal, eliminate the modes.
• Can the user save a document or quit an application at any time, unless he or she is in a modal dialog box?
• Are the widest possible range of user activities available at any time? The user should spend most of his or her time in the event loop.
• Will a user unable to distinguish colors be able to use the application? Will someone without a color monitor be able to use it? The information conveyed by color coding should also be presented in another form, such as text, position, highlighting, gray-scale variations, or pattern. (These questions do not apply to programs in which the task to be carried out requires full-color vision on a color monitor.)
• Will a user with a hearing disability be able to use the application? Audible messages should be supplemented with visual cues or should allow the user to choose visible instead of audible messages. (This question may not apply to music programs.)
• For those who cannot handle book-form manuals, is any part of the manual available in electronic form?

 
Interface Checklist: Documentation

• Does the manual include a glossary of potentially confusing terms that relate to the application or to the application's topic?
• If the manual refers the user to another document, is the reference more appropriate than having the information in the manual itself?

 
Critical features of Great Multimedia

• Present a Useful Idea
• Provide Clear Navigation
• Use High Quality Images and Video 
  Compression degrades the pictures, so start with best possible images. Be smart about the source images and you will get better compression results. 
   
  
  1. Pay attention to proper lighting and shadows
  2. Avoid black backgrounds
  3. Use close-ups rather than long shots
  4. Minimize rate of change of scene content when panning or tilting
  5. If text is used, use large characters. 10 - 12 point will not be legible after compression, better to avoid text in the image and superimpose graphics during playback.
• Great Sound Matters: 
  Good sound can make up for poor video, and it is smaller on the disc than high-quality video files

[출처]http://cognitivevent.com/gui_checklist.html