[Draft] Module 7: Interaction and Feedback

• Prerequisites for students
• Prior Designer Modules
• Knowledge of:
  • Visual Design
  • Responsive Design
  • Information Design
  • Interaction Design

• Applied expertise in teaching:
  • @@@
• In-depth knowledge of:
  • Prerequisites for students
  • Visual Design
  • Responsive Design
  • Information Architecture
  • Interaction Design

Discuss standard keyboard interactions, such as the use of the tab, enter, escape, and arrow keys. Explain that providing custom keyboard interactions can favor efficiency, but can also disrupt the users expectations, thus these interactions need to be well documented and be consistent throughout the interface. Emphasize that defining the keyboard interactions is a designers’ responsibility, whereas implementing them is a responsibility shared with the developer.

Learning Outcomes for Topic

Students should be able to:

• design custom user interfaces that support operation with the keyboard
• identify situations when it is necessary to provide additional keyboard shortcuts, for example when designing a custom functionality that is not keyboard supported by default
• design user interfaces that avoid keyboard shortcut conflicts with the operating system, browser, and assistive technologies when possible
• define mechanisms to obtain information about custom keyboard shortcuts, for example those used to support efficiency or those used in complex application
• describe related requirements for developers to implement keyboard support for interactive user interface components

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Invite students to try standard keyboard conventions. For example, use of the tab to move through interactive controls, use of the arrow keys to move through list items, and use of the enter key to select an item. Explain that these interactions need to be preserved as much as possible when designing custom widgets. Custom keyboard interactions should be defined when these standard conventions are not enough to achieve the goals of the user interface. Explain that defining keyboard interactions is a designers’ responsibility, whereas implementing such interaction is a responsibility shared with the developer.
• Present some examples of keyboard shortcuts that may conflict with browsers, operating systems, and assistive technologies. For example, modifier keys and single letter keys that are used by browsers and assistive technologies to provide built-in functionality. Explain that these keystrokes should be avoided when possible.
• Show examples of help functionality to explain custom keyboard shortcuts used in rich applications and in complex widgets. Explain that, while custom keyboard shortcuts are preferred by some users for efficiency reasons, using such shortcuts alone can distract others who may not be familiar with such keyboard shortcuts. Explain that providing these mechanisms is a designers’ responsibility, whereas implementing them is a responsibility shared with the developer.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

• Practical — Present students with a user interface that can be interacted only with the mouse and ask them to define keyboard interaction patterns. Assess how students understand the need for alternatives to mouse input and how they use standard keyboard interactions when possible.

Show examples of labels and instructions for interactive user interface components. Explain that they are essential for people relying on assistive technologies and for people with cognitive disabilities to understand the purpose and intent of these components.

Learning outcomes for Topic

Students should be able to:

• provide clear and consistent names to help users understand the purpose and intent of interactive user interface components
• design user interfaces that allow to position labels where users expect them
• provide instructions about which input fields are required by:
  • including information about each of the required form fields before the form control
  • including textual and visual cues in the label of each of the required form fields that indicate that they are required
• provide clear instructions about changes in context before the control that originates such changes
• provide overall instructions about existing time limits in a form and about how they can be adjusted, extended, and turned off
• provide clear instructions about the current step and about the total number of steps involved in a multi-step form
• identify related requirements for developers to code labels and instructions appropriately

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Show examples of different interactive components (such as buttons, links, lists, and grids) across rich applications or complex widgets and emphasize that each should have a clear name that allows to identify its purpose. For reference on how to provide names for different user interface components, see technique G197: Using labels, names, and text alternatives consistently for content that has the same functionality.
• Demonstrate how labels for form fields are placed differently depending on the components, the language, and the user expectations. For example, labels for edit boxes are placed to the left of the field or above it in left-to-right languages, and to the right of the field or below it in right-to-left languages. Labels for radio buttons are placed to the right of the field or below it in left-to-right languages, or to the left of the field or above it in right-to-left languages.
• Show examples of required and non-required form fields. Explain that instructions for which of the fields is required should be provided using several mechanisms, including textual and visual cues.
• Present examples of time limits, such as those warning about session expirations. Explain that instructions need to be provided so that users are aware of the time limits, and mechanisms need to be implemented to stop, adjust, or extend time limits. Explain that defining and providing the instructions is a designers’ responsibility, whereas implementing mechanisms to stop, extend, or adjust time limits is a responsibility shared with the developer.
• Show examples of multi-step forms. Explain that overall instructions should be provided about the current step in a form and about the total number of steps involved. For reference on how to provide instructions for multi-step forms, see @@@

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

• Practical — Present students with a form and ask them to define labels for each of the fields. Assess how students provide clear and descriptive names for each of the form fields.
• Practical — Give students an application and ask them to provide names for each of the application subsections. Assess how students identify application subsections and provide clear and understandable names for each.
• Practical — Give students a form and ask them to provide the necessary instructions for users to understand each of the fields and fill in the form. Assess how students provide clear and concise instructions.

Show examples of user interfaces that react to motion, such as shaking the device to perform a specific action. Explain that some people may perform these motion-based gestures inadvertently, some others may not be able to perform them at all. Discuss some alternatives to motion-based gestures.

Discuss some gestures that require dragging and drawing specific paths on a touch screen. Explain that these are difficult (and sometimes impossible) to perform for some people with mobility impairments.

Learning Outcomes for Topic

Students should be able to:

• design user interfaces that support alternatives to device or user motion such as shaking by using user interface components that do not require motion
• design user interfaces that support disabling response to motion to prevent accidental actuation, such as undoing an action by shaking a device
• design user interfaces that support alternatives to multi-pointer gestures (such as swipe or pinch) using single pointer activation
• design user interfaces that support undoing or aborting an action carried out with path-based operations

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Show examples of gestures that require motion, such as shaking the device, to perform an action. Explain that users with mobility impairments cannot perform such gestures, so user interfaces need to have alternatives that do not require motion for these gestures.
• Show examples of gestures such as swipe or ping. Explain that users with mobility impairments cannot perform such gestures, so user interfaces need to have alternatives that do not require swiping or pinching to perform an action.
• Show examples of operations carried out using path-based gestures, such as dragging. Explain that people with mobility impairments may inadvertently initiate touch or mouse events, so user interfaces need to support alternatives for people to perform actions associated with multi-pointer gestures or to undo actions carried out inadvertently with multi-pointer gestures.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

• Practical — Give students an interface that uses a motion-based gesture to perform an action and ask them to provide alternatives to that gesture. Assess how students provide alternatives to motion-based gestures.
• Practical — Give students an interface that uses a multi path-based gesture to perform an action and ask them to provide alternatives to that gesture. Assess how students provide alternatives to multi-pointer and path-based gestures.

Show examples of notification messages. Explain that they need to be distinguishable by all users, including through visual cues and programmatically.

Explain that notifications may have different levels of priority when in the context of a complex application. Defining such levels of priority and which types of notifications each of them should contain is a designers’ responsibility.

Learning Outcomes for Topic

Students should be able to:

• design user interfaces with notifications that are easy to understand and that can be distinguished from any other user interface component
• provide meaningful and descriptive messages about errors, suggestions for corrections, and successes
• design user interfaces that support notification storage to allow notifications checking at the users’ pace
• design user interfaces that support mechanisms to queue and prioritize application notifications coming from different interactive user interface components
• describe related requirements for developers to code notification messages appropriately

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Show examples of different mechanisms to communicate notifications, such as through text messages, haptic and audio feedback, and popup windows.
• Demonstrate different types of error messages and explain why it is necessary to communicate the specific field where the error has occurred and, if possible, provide suggestions for users to correct the error.
• Show examples of overlapping notifications in the context of complex applications. Explain that some users may find it daunting to process several notifications at the same time, so a mechanism needs to be defined that allows to prioritize notifications based on their relevance.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

• Practical — Present students with a form field submission containing errors and ask them to provide notifications about each form field that contains errors, together with suggestions for corrections when possible. Assess how students provide adequate error messages for each of the wrong fields and how they provide suggestions for corrections when possible.