Training Tool for the User Action Framework Explorer

Module 1: Introduction to the UAF

What is the UAF?

The User Action Framework(UAF) is a conceptual framework of usability concepts and issues formed by combining a model of the user interaction cycle with a knowledge base of usability concepts and issues. The UAF provides a unifying structure and basis for : Organizing, discussing, classifying and reporting usability problems and is the basis for a set of usability support methods and tools. These tools are listed below:

• User Action Framework Explorer
• Usability Design Guide
• Usability Problem Inspector
• Usability Problem Classifier
• Usability DataBase

Critical to the use of the UAF toolkit is the understanding of the structure and content of the UAF through the UAF Explorer tool.With the UAF and its toolkit, practioners and developers will be able to identify the root cause of a problem in the user-system interaction cycle and act to improve usability by fixing the problems in the design.

Basis of the UAF : The User Interaction Cycle

The User interaction Cycle is a picture of what users do and see as they interact with machines(especially computers) and consists of four main kinds of user actions and one system action as illustrated below. These include: Planning, Translation, Physical Actions, Outcome and Assessment.

The basis of the UAF lies in how it helps the usability practioner and designer organize questions about how an interaction design supports(or doesn't) the user in these actions. These interaction activities cover all aspects of user interaction with the system.

The User Interaction Cycle. Note that Outcome is shown as being disjoint from the interaction cycle because it represents a system action.

The five major top level categories (interaction activities) of the UAF along with a brief description are as follows:

• Planning : What to do/Design helping user know what to do

  Planning is concerned with the user's ability to understand the overall computer application in the perspective of work context, problem domain, environmental requirements and constraints. The primary focus is on the system model and metaphors, and the user's knowledge of system state and modalities.

• Translation: How to do it/ Design helping user know how to do something

  Translation is largely about cognitive affordances to support the users' ability to plan physical actions. The user translates intentions into plans for physical action(s).

  • User's ability to determine (know or not know) how to do a task step in terms of what physical actions to make on which objects.
  • Knowing what object to manipulate and how to manipulate it to accomplish an intention for a task.

  Example: A way to do intention ,making the way obvious,making the cues meaningful and effective.

• Physical actions: Doing it/Design helping user do the actions

  Physical action is about doing an action once it is known how to do. Executing the planned actions is the focus of the Physical Action part of the Interaction Cycle.

• Outcome: Result inside system

  Outcome is internal to the system. As a result of the user's physical actions the system changes state internally (Eg: performs a computation or retrieves information). The outcome within the system is not directly visible to the user, but must be deduced from the system feedback to the user. The outcome category is mainly about software bugs and other software issues but can have usability issues.

• Assessment: Knowing whether user did the right thing/Design of feedback and display of results helping user know if actions worked

  Assessment is about the user knowing whether he/she did the right thing. It's about the design of feedback and display of results helping user know if actions worked. While outcome happens inside the system assessment is about how outcome is rrepresented to the user by the interaction design.

• Independent: Usability issues and overall characteristics not related to a specific part of the user's Interaction Cycle and are general to the overall application.

  Independent addresses issues not shown in the interaction cycle. These are overall issues relating to the whole interface, are very general and not dependent on a particular kind of user action. These might belong to more than one interaction activity in the design space or to none at all and are generally characterized by their global nature. For example, overall look and feel, overall consistency and style.

  Each of the above interaction activites subcategories under them, that will be discussed in subsequent modules.

Touring the Interaction Cycle

To introduce the User Action Framework :

Consider a user working on the goal of printing a business letter.

In this example of Human-Computer interaction, the user executes a series of actions, each of which should fall under a category in the user action framework. Classifying the steps the user executes under the interaction activities in the UAF would result in:

Step 1: A new task, to print the document, arises in the planning part of the interaction cycle, expanding the work goal into a computer domain task. The first intention for this task is the "getting started intention"; the user intends to invoke the print function. This user does not do further planning at this point, expecting the feedback from acting on this intention to lead to the next natural intention.

Step 2:The user translates this first intention into an action specification in the language of the actions and objects within the computer interface. The user draws on experiential knowledge and/or the cues provided by display of the Printer icon in the toolbar create the action specification to select this icon.

Step 3:The user then carries out this action specification by doing the corresponding physical action, clicking on the Printer icon . The system accepts the choice, changes state internally (the outcome of the action), and displays the Print dialogue box as feedback.

Step 4: The user sees the feedback and uses it for assessment of the outcome so far. The dialogue box makes sense to the user at this point in the interaction; so the outcome is considered to be favorable (i.e., leading to accomplishment of the user's intention and indicating successful planning and action so far).

The user cycles back to planning to decide what to do within the dialogue box, beginning another turn through the cycle

Let us look at the case where the user faces a problem in a scenario:

Consider a user working on the goal of printing a businees letter. He searches for a visual cue to let him know how to print but there is no such visual cue.

Here the user executes step 1 as shown above but cannot complete step 2 as there is no visual cue to let him know how to print.Therefore he gets stuck in the Translation part of the interaction cycle and this is classified as a translation problem in the UAF.

Cognitive actions vs Physical actions

User actions in the interaction cycle are normally of two kinds : Cognitive and physical. Cognitive actions are all about knowing and thinking, not doing. In physical action it is about what the user 'does' after thinking. It pertains to the actual physical activities of the user with the interface. The translation activity covers the users cognitive actions while the physical actions category pertains to users physical actions when interacting with the system. This brings us to the concept of affordances.

Affordances are features that help the user do something and are of two kinds: Cognitive and Physical.

• Cognitive affordances help the user think or know about something and how it can be used. For example the label on a button is a cognitive affordance that helps the user know what the button is for. Examples of cognitive affordances: Visual cues (example: labels, data field formats, icons), wording used in a menu choice.issues with cognitive affordances are almost always associated with translation. The Translation interaction activity, which is a very important interaction activity is mostly about cognitive affordances.

• Physical affordances help the user make physical actions. Physical affordances are aids for actually doing an action. They are physical objects that convey a message to the user. While the label on a button is a cognitive affordance the button itself, as an object that can be manipulated (e.g clicked on), is a physical affordance that helps the user actually do the clicking to make things happen. Examples of physical affordances: The physical mechanism used to pull down a menu and make a selection.

The UAF Explorer

Now that the user interaction cycle has been explained , let us see the actual UAF Explorer which implements the interaction cycle and navigation features on a web based tool to classify usability problems.

Click here to see the actual UAF Explorer tool. Browse through it to get a feel of the explorer. Keep this window open, you will continue to use it through out the training modules.

Review of Concepts

• Planning - What to do/Design helping user know what to do
• Translation - How to do it/ Design helping user know how to do something
• Physical actions - Doing it/Design helping user do the actions
• Outcome - Result inside system
• Assessment - Knowing whether you did the right thing/Design of feedback and display of results helping user know if actions worked
• Independent - Usability issues and overall characteristics not related to a specific part of the user's Interaction Cycle.
• Affordances and Actions : Cognitive actions are all about knowing and thinking while Physical actions are about doing. Affordances can either be cognitive or physical. Affordances are features that help show the way to the user.
• If the affordances help the user find the way to do something, then they are cognitive affordances.
• If the affordances help the user to actually do a physical action then it is a physical affordance.