View source for The Battleground: Software Consistency and Ease of Use

''by [[Joe Pesot]] and [[John Sweitzer]]''

This is the second article in a series on achieving usability through integration. The series focuses on areas you need to understand to develop usable software and how The Developer Connection for OS/2 can help you.

Note: The first article in this series, "Evolving the Blueprint for Usability Through Integration," is in The Developer Connection News, Volume 7, on your accompanying Developer Connection for OS/2 CD-ROMs. 

==The Expanding Marketplace==
Users of today's software are becoming more and more numerous and diverse. As their numbers increase, their relative computer literacy, skill level, and general computer interest decline. As a group, software users are becoming less and less interested in the complexities of working with a computer. More and more, computer software is viewed as one of many potential tools for completing specific personal and job-related responsibilities, or personal and family-related entertainment activities. Where once computers were the domain of the technical elite, they are now becoming the domain of the average individual.

The effect of this situation is twofold. First, the good news: It creates an expanding marketplace in which new customers provide new revenue opportunities. On the flip side, this situation has created a very competitive environment in which many software vendors are fighting for leadership. And in almost every situation, the battleground is usability.

With so many choices, new users of software systems expect these software tools to provide an almost immediate return in productivity or enjoyment. Rarely are they willing to delay gratification by dealing with tutorials or training programs. They have work to do right now. The have bills to pay. They have reports to write. They have data to analyze. They want Madonna's latest CD running in the background. There is very little time for them to "waste" on relearning how to do tasks they already know how to do without a computer. 

==User Interface Consistency==
User interface (UI) consistency has been an ongoing area of discussion (and debate) in the software industry for quite some time. In general, an inconsistent user interface can be described as one in which the software performs in ways that are not anticipated or predictable by the user. As part of their focus on trying to create software systems that are, some companies and standards groups have developed fairly extensive UI guidelines for both internal and external developers to use when creating user interfaces. In addition, many "in house" software development activities are directed by "home-grown" UI standards.

In general, much of the discussion and debate on this topic can be summarized as follows: UI consistency, when applied effectively, can be good for end users. It can help them learn how to use a system. It can also let them experience a positive transfer of training from one software product (or environment) to another. However, if the particular focus on consistency impedes a user's movement from novice to expert, then the user will be left at a level of performance that is "consistently below" what they desire. As a result, what we can say about UI consistency is that it is important to the user, but must be applied in ways that the user will find effective. So how do you do that? 

==Understanding Pervasive End-User Tasks==
To examine your product's level of UI consistency and to get an idea of whether or not you've succeeded, you need to understand three key points regarding each task that users perform when using your product:
* At what level is the task (micro-level task <---> macro-level task)? 
* To what extent do users view this task as central to their work? 
* How pervasive is this task across products used by your users? 

For example, clicking a push button is a micro-level task. In fact, it is usually a subtask within some larger task the user is trying to do; it's not central to the user's work. That is, the relationship between "clicking a push button" and the user's primary work objective (say, creating a status report) is fairly remote. Clicking push buttons is not the reason a user purchases software. However, the task of clicking a push button is highly pervasive--it is found in almost every product today that has a graphical user interface.

In contrast, creating a bar chart is a macro-level task. It can include subtasks such as selecting a data file, clicking the Open push button, selecting the chart type, and so on. A task like creating a chart usually has a very close relationship with the user's objectives--it may even be the reason for buying the software. Yet this task is not terribly pervasive in today's software. It appears in some products, but not in most.

The following matrix examines the various tasks and UI components in a product based on the three points listed above (gauged as High, Med, and Low, for simplicity). You could call it a list of "candidates for consistency." The matrix shows the various tasks ordered from micro level to macro level down the left side.
{|
!Task/UI Component !! Central to Work !! Pervasiveness
|-
|Click a push button|| Low || High
|-
|Use a toolbar || Low || High
|-
|Delete text || Low || High
|-
|Open a file || Med || High
|-
|Change fonts || Med || Med
|-
|Draw an object || Med || Med
|-
|Create a chart || High || Med
|-
|Send data to another || High || Med
|-
|Mail merge || High || Low
|-
|Analyze data || High || Low
|}
''Table 1. Candidates for consistency''

As described in the first article in this series, one of the key issues in creating usable software products is ensuring that you have provided easy and effective ways for users to complete the key tasks associated with their work. Yet, in much of today's software, even the simplest tasks are made excessively complicated and must be relearned within the context of each software product in which the task is performed. The result is that users must spend time, energy, and attention focusing on micro-level tasks that are not the central focus of their work. This reduces their efficiency, productivity, and satisfaction.

If you review the software products available today, you'll find that many tasks and UI components are pervasive from product to product. What you will also find is that:
* Users rarely view micro-level tasks as central, and 
* The tasks that would be considered highly central are rarely highly pervasive. 

In a sense, those tasks that are central to a user's work are often what give our products a competitive edge. So, almost by definition, these are rarely pervasive. 

==Developing Powerful and Consistent User Interfaces==
The general approach, then, is to start with the micro-level, pervasive tasks and work down the table--making the tasks consistent. This approach lets users learn a consistent way to complete those tasks that are (a) small and usually subparts of larger tasks, and (b) not central to their work (and, therefore, aren't terribly interesting to them). As a result, your users benefit from consistent approaches to simple tasks and can place primary focus on their more important, central tasks.

We want developers to focus their innovation on providing leading-edge function and capability to make products more powerful and compelling. Yet developers often end up expending time, energy, and attention developing the code associated with many medium- and low-level, pervasive end-user tasks. As a result, they can't focus on the tasks that are central to a user's objectives--or to the product's purpose. So what's the solution?

Those who have participated in the "never-ending struggle" to improve the ease of use and consistency of software products can probably tell you that two of the most important factors to success are user focus and tools:

* A key component of user focus is understanding which tasks your audience wants (or needs) to perform. This will help you create a matrix like the one shown above, so you can determine which tasks to implement consistently, and which will require innovation. 
* For those tasks where you need consistency, you'll want to reuse as much existing code as you can. That way, you ensure that your UI is consistent with what users already know. And that means you need tools that have UI consistency as a key focus. Such tools can help you stay focused on the leading-edge aspects of your product.

==A Specific Example--The Open Class Toolbar==
One of the pervasive UI components mentioned earlier was the toolbar. In recent months, this particular element has become more and more popular with software users. But adding a toolbar to your application is no picnic.

[[Image:Battleground-Fig-1.gif]]

''Figure 1. Open Class Library toolbar''

So you have a choice. Either you can create a toolbar from scratch, or you can reuse the one supplied in IBM's Open Class Library (see Figure 1). If you use the toolbar supplied by Open Class (IToolbar), you'll get standard buttons and consistent behavior, including drag and drop support. And you can reduce your development time on this line item from as much as five person months to less than one week (estimate based on actual reports, not including the time involved in graphical design). Sample Code 1 shows toolbar code as it would appear in an application:
<PRE>
// create toolbar
toolBar(ID_TOOLBAR, this),

// create toolbar buttons
openButton      (IC_ID_OPEN,         &toolBar,   &toolBar),     
saveButton      (IC_ID_SAVE,         &toolBar,   &toolBar),
cutButton       (IC_ID_CUT,          &toolBar,   &toolBar),
copyButton      (IC_ID_COPY,         &toolBar,   &toolBar),
pasteButton     (IC_ID_PASTE,        &toolBar,   &toolBar),
boldButton      (IC_ID_BOLD,         &toolBar,   &toolBar),
italicButton    (IC_ID_ITALIC,       &toolBar,   &toolBar),
underscoreButton(IC_ID_UNDERSCORE,   &toolBar,   &toolBar),

// Add the buttons to the toolbar
toolBar.addAfter(&openButton);
toolBar.addAfter(&saveButton, 0, true);
toolBar.addAfter(&cutButton);
toolBar.addAfter(&copyButton, 0, true);
toolBar.addAfter(&pasteButton, 0, true);
toolBar.addAfter(&boldButton);
toolBar.addAfter(&italicButton, 0, true);
toolBar.addAfter(&underscoreButton, 0, true);
toolBar.addAfter(&fontCombo);
</PRE>
''Sample Code 1. Toolbar code segment''

==Conclusion==
The battle for usable software is raging. We will be focusing on determining which tasks and UI components are "candidates for consistency" and then working to provide you with as many as possible through IBM's Open Class Library. In the meantime, you might want to figure out where your software stands in this battle. 

==We Are Not Alone==
How many software products do the users of your software have on their systems? How many do you have?

If your answer to both of these questions is one, you can skip to the next article. But everyone else should read on!

In today's software market, if your software can't peacefully coexist with other software on the user's machine, don't be surprised if it lives alone, with other dusty software on the back shelves at "Apps-R-Us."

Below are some examples of consistently used dialogs. How do yours compare?

[[Image:Battleground-Fig-2.gif]]

[[Image:Battleground-Fig-3.gif]]

[[Image:Battleground-Fig-4.gif]]

[[Image:Battleground-Fig-5.gif]]


'''Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation'''

[[Category:Developer Connection News]][[Category:Miscellaneous Articles]]