impact4: Look and Feel Specifications

Look and Feel Specifications, Design Philosophy

Philosophy: methods of interaction | usability and design concerns
Specifications: text | buttons | graphics and animations

impact4 was designed to be deployed on a variety of platforms, environments, and systems. Therefore, designers must be prepared for interaction from any of these methods:

Touchscreen
Only accepts mouse press and release events. No mouse movement, and limited dragging are available. Because of the imprecision of where a user puts their finger on the screen, mouse events should be based on release. It is also a good idea to make buttons at least 150% the size of the average fingertip. Generally, users will still have access to the keyboard.

Kiosk
Similar to a touchscreen, but without any keyboard access. If you are certain a program will go into a kiosk environment, alternative ways to enter free text, or text-based data need to be planned and implemented. Possible solutions include an on-screen keyboard, or sound recording if the data is to be analyzed later. Mouse events behave identically to Touchscreen.

Mouse
The standard keyboard and mouse setup is familiar to us, but can be confusing for new users. However, if users are comfortable using a keyboard and mouse, this is the best method for rich interaction. Capturable mouse events include movement, press, release, and drag. A keyboard, if present, can facilitate text input, but most interaction should be geared toward the mouse.

Trackball
The system setup is identical to Mouse, but a trackball mouse is often easier for new users to understand and use. It provides all of the same functionality as a mouse, but can be more difficult to use when dragging. If Trackball is going to be the primary input method, do not use dragging in any modules.

Pen-tablet Input
This is an easy, intuitive method of input. Once users have familiarized with how to use the system (keeping the pen close to, but not touching the screen, etc), it is equal to the Mouse in richness of feedback. Pen tablets can movement, press, release, and dragging. Also important is that dragging is easiest (and most intuitive) with this method.

Keyboard Only
This system hasn't been implemented yet in current tools, but should remain a possibility for user who can't use a mouse, or choose not to. There will be a system-wide keyboard spec, and runtime function to attach and detach listeners. For users comfortable with using a keyboard, this method is likely to be the fastest and most efficient way to interact with a program.

Since impact4 is designed to be used in a primarily clinical setting, it is important to design for the special cases that exist in a clinical setting. This environment can be challenging for design, but also very successful with proper design and planning. Several points in this vein:

Design for users who have never used a computer, and have limited physical mobility.
This means keeping mouse movements to a minimum, and never requiring advanced interactions (such as click & drag) from the user to complete the survey. (Note that this doesn't exclude such operations to make the survey easier for advanced users, but it can not be the only or primary method of interaction). The design should also ensure that a user is never required to use the keyboard at any time, if they should so choose. However, users who are more comfortable with using a keyboard should be allowed to use it exclusively; our goal is to allow users to use whatever input they're most comfortable with.

Keep the goal of the program in mind in your design.
It is important -- especially when presenting complex and sometimes confusing concepts to users -- to keep the visual and audio stimulus as clean and minimal as possible. If the purpose of a program is to elicit utility responses, design so that the ideas you're trying to explain to the user are a clear as possible, and keep extra elements that could distract to a minimum.

Use sound, animation, and graphical elements only when they help achieve the goal of a more usable program.
Flash and the i4 framework enables us to create very rich programs. But especially when asking questions that require user thought, it makes most sense to present exactly what the user needs to consider and nothing more. If the movie is understandable without a soundtrack, don't add one. If a still will do in place of an animation, use the still. The point is to accurately convey the concepts we're evaluating, not show off our coolness as programmers and designers.

Text specifications are fairly simple. Use Lucida Grande for interface text, and Lucida Sans for all other text. Font sizes should be 24 point for headers, 16 for body text. If necessary, other sizes can be used, but in no cases should fonts be smaller than 13 point.

Font color should be #0A0A0A for most text, #000000 for header text. Note that #000000 can often be used instead of bolding text.

Button Color and Shape
All colors in the i4 system should be simple, mostly primary colors, with high saturation, and medium brightness. Highlights and darknesses are achieved by changing color brightness, but not saturation. Highlights are generally 10-20% brighter, darknesses 10-20% darker. Also, gradients are generally not used.

Buttons should be monochromatic (grayscale), with two exceptions: first, buttons should become colored when the user mouses over and clicks. Second, if it is very important that a user clicks a button, or that they notice its presence, it can begin colored. In addition, any buttons or text that react to user feedback (missed responses, etc) should show up in #00FFFF red.

Regular buttons should be rounded corner box, at about 8 pts for the corners. Drop shadows can be used, but only for buttons that directly affect the screen (feedback, autoadvance / navigation buttons). Drop shadows should not be used for buttons that don't affect the screen dramatically (tools, widgets, etc.)

Button States (Up, Over, Down)
Mouseover state for buttons can also have a white line fill edge, in 4 point line or wider. The color should lighten as specified above. Mousedown darkens the color, and moves the button if it has a drop shadow (to cover the shadow and give the impression of a downward movement).

What triggers feedback
Since it isn't possible to reliably capture mouse movement (see methods of interaction), mouseovers should not be used to trigger script for essential events. on (press) can be used to trigger actions that involve press-and-hold, but not for much else. For one-time-click buttons, actions should be scripted with on (release).

Overall style for graphics and animation should be clear and clean. In non-photographic elements, there should be minimal use of color, and designers should try to stay in the same general palette (high saturation, medium brightness). In photographic elements, make sure to use high quality images, and import at a higher resolution than needed (scale for 1024x768, then shrink by 67% to keep the correct size at 800x600).

To communicate abstract concepts (life course, hypothetical persons), line drawings should be used instead of photo elements. However, in interface elements or navigation, use relevant photos of objects to make sections seem more tangible. Examples of this style are in the left side i4 bar, and in Mac OS X's dock.

In animation, it is important that animations do not have or need any navigation outside the i4 nav. If user input is needed to continue, split the animation into two modules. (Or one module with a variable indicating the start frame).

The overall philosophy behind the look and feel is to create an interface and program that is friendly, easy-to-use, and intuitive for first-time users. Keep in mind that users will often be using a program for an hour or more, so minor details that are visually or aurally irritating will grow to be a source of annoyance and dissatisfaction for the user. Ideally, the interface and tools should be completely transparent, and users should just feel that they're answering questions, and the computer is helping them do it.