Summary

When developing applications or demonstrating prototypes, it's wise to consider a design approach that allows you to illustrate the working of harnesses in the application flow. This approach is sometimes referred to as using "situational awareness."

Suggested Approach

The user interface in an application is based on rules known as harnesses. Each Work- class (work object, cover, folder) comes with standard harnesses that control the associated user experience — the forms and their appearance, content, and behavior. A harness rule (with other rules it references) defines an HTML form for entering, updating, and reviewing work objects. Process Commander converts the rules into sophisticated HTML forms for users to enter, update, review, navigate through, and perform actions in an application.

This article provides examples of good form design practice.. All of them can be done with the standard out-of-the-box rules, or with a minimum of additional updates.

Situational Awareness in Software
The United States Navy defines situational awareness as "the degree of accuracy by which one's perception of his current environment mirrors reality."

In software interfaces, this means providing all the information the user needs directly on the work object form. Furthermore, it's useful to give hints to the user about what's happened up until this point and what's going to happen next. Said another way: Let the product communicate the situational awareness in prototypes and demonstrations - so that you don't have to do this . Someone watching who briefly turns away from a demonstration should be able to pick up again quickly when returning to look at the screen.

The following image shows a sample work harness that illustrates situational awareness. The letters A to E in the image relate to additional information given below.

(Sample work harness)

Item A: Status

The standard harness shows the work status in the title bar. The work status quickly communicates to an experienced user where in the flow the work object is. This may not be so clear to a line manager or untrained person watching a demonstration..

It is prudent to make sure that the status clearly represents what's happening. Above, the action to take is approval, so the status is explicitly set as Open-Approval.

This example includes one change from the standard harness: the work object ID is shown to the left of the status. This reads better, reflecting subject-verb-object word order in English.

Item B: The Where-Am-I Flow Pointer

The Where-Am-I flow pointer (also known as the golden arrow) is a feature that augments the status field. Clicking the arrow brings up a diagram of the flow, with a larger golden arrow pointing to the current assignment step of the work object.

This is helpful in single user mode. In demos, the pointer can shift attention from the current form. It also requires the active click of the demo presenter to access. A viewer of the demo may not perceive this. Furthermore, if the user is looking at a subflow, the diagram does not illustrate where the main flow is waiting.

Item C: The Who-Am-I? Bar

"OK, where are we?" is a frequent question from those viewing a prototype or demonstration. Another frequent question is "OK, who are we?" In this example, the latter is answered by the green bar added to the assignment harness. This bar is helpful in demos by making it easy to walk through without switching browsers. This example also illustrates how the user interface can anticipate situational awareness questions that users may have.

If the work object is assigned to a workbasket, the bar gives the name of the workbasket. This capability helps rationalize its usage in production as well as in demonstration and development environments.

Item D: The Mounting Shelves Approach to Form Design

In each application, as work advances through the flow, more data is added. Therefore, work object forms should grow throughout the flow. An analogy is in building a bookcase on a wall and mounting shelves from the top. A set of data shows up only when it is encountered in the workflow.

There's an added benefit to this approach: if data is added over many steps, the user can glance at the "shelves" after opening the harness and immediately see how far along in the process the work object is.

Setting the display conditionally enables this approach. An example from the section edit form is shown here:

(Setting adjustment example)

This example includes the section Controls. Using the header from the included section makes setting a header unnecessary. A header is added only after the Memo Details step. The When rule hasControls is set only when embedded controls are added to this work object.

Therefore, if that rule evaluates to false, the Controls block is hidden. In addition, the plus sign in the section header indicates that the section will show up collapsed by default.

An exception to this approach is the Notes section in the example above. Certain flow actions input a minimum of data, such as the time/date of an approval, plus a comment. These go into a single Notes section, not separate ones.

Overall, the shelves are compressed into a compact space at top, leaving room in a Perform harness to display the action section at the bottom. This should ensure that the user checks the work details prior to looking at the action section.

Item E: Action Spotlight

A concern for new users is making sure that they know the specific situation at any assignment. Specifically:

• Past: What just happened? (important if the work was just processed by someone else)
• Present: What role are you playing now?
• Future: What will happen after clicking the submit button on this form?

This is complicated information to bring together on the flow action display. For this implementation, the information is hard coded in each action section. However, finding ways to avoid hard-coded data is also important.

It is possible and probably more beneficial to use dynamic rules to display what just happened. For example, the Approval action form can give the name of the prior approver and reason for the action.

Give It A Try!

Each application has different requirements and structures of data that need to be displayed. The approach described here enables a user to have the information readily at hand, whether for the experienced, regular user or someone viewing a demo and walking through the application for the first time.