Figure 1: Scalable navigation -- Examples of primary (horizontal), secondary (vertical), and contextual navigation.

Business users fueled by personal experiences with the Googles, eBays, and Schwabbs of the world have come to expect a similar level of convenience and satisfaction when they log onto their company network. Further complicating these demands are corporate budgetary requirements to reduce training, support, and development costs in a never-ending quest to trim operational expenses. As software "suites" become portals and enterprise resource planning (ERP) packages become personalized "digital dashboards," the designers, developers, and owners of these systems have to pay more attention to their users. Failure to identify the ultimate benchmarks for success -- employee productivity and efficiency -- will result in added training, development, and support costs that these same initiatives were supposed to reduce.

The new paradigm

Regardless of what technophobes and expert prognosticators might say about its utility, the Web has impressed one undeniable fact on software designers: Usability matters. Usability, that sometimes discussed and rarely understood word, refers to the ease with which a person can learn and use a system. In the past, usability was an afterthought, as software developers' primary goal was to inundate users with features. The prevailing sentiment was that as long as you could achieve business functionality, users would be happy. And if they weren't, it didn't really matter anyway. It's not as if the user had the option of going out and finding an easier-to-use general ledger system to complete his daily accounting tasks. Users were stuck with whatever tools they were given.

Fast-forward to the late 1990s, and the impact of the Web begins to take effect. Although picking and choosing the easiest-to-use system was still not an option for the vast majority of business users, they did get a glimpse of what usable software was supposed to be like. As the intense competition for customers heated up, Internet retailers and service providers were forced to rethink software design in order to meet their financial projections for customer acquisition and retention. The Web made it far too easy for frustrated customers to purchase the same product or service from a competitor's Web site that delivered it easier, faster, and often cheaper. Unfortunately for most players, this was a lesson learned far too late in the game.

At roughly the same time the Internet boom was beginning, software vendors and corporate IT departments began to see the efficiencies in Web-based software delivery and worked to migrate their business functionality from client-server installations to Web browser deployments. Although they achieved successes in reducing development, deployment, and support costs, they encountered an unexpected challenge. Because the user was now launching the application from Internet Explorer or Netscape or navigating to it through the corporate intranet, the Web-acquired expectation for usability translated to the same expectation in the workplace.

Finally, fast-forward a few more years to a business climate characterized by IT staff reductions. What was once a largely unfilled user expectation has become a corporate requirement for reducing training and support costs. Thus, a new paradigm in software development was born.

Keys to effective browser-based software design

So how do software architects and programmers benefit from the mistakes of Web site designers? What lessons can you apply to designing business systems that will enable browser-based software solutions to meet the objectives of reducing training time, increasing employee productivity, and eliminating operational costs? Creative concerns related to intuitive iconography, visually aesthetic color palettes, and overall brand impression certainly play a vital role, and you shouldn't overlook them. However, the strategy and architecture components of design are where you can make the largest gains (or losses) in efficiency and productivity.

Personalization vs. customization
This is an often misunderstood differentiation that in most design conversations ultimately confuses the task of determining what's most important for the user. Personalization refers to the systemic delivery of user-specific functionality, data, or information. Customization, on the other, hand refers to the user's ability to set interface preferences for attributes such as content layout, color palette, or "style."

Personalization is an invaluable technique for creating workflow efficiency by limiting the number of user options to a select number of choices based on the specific tasks he has to complete. Although customization is available on many Web sites and most portals (i.e., Yahoo!, MSN, and AOL), it's rarely used by the majority of subscribers. In these cases, the time required to set personal preferences often outweighs the utility it provides the user.

In determining whether customization capabilities are right for your situation, there are two issues to consider. First, will your users take the time to adjust their customization settings? Second, if users see a benefit in customization, is the added time and cost required for you to develop these capabilities justified? If your answers to both questions are yes, then talk to your users and see if they reach the same conclusion. Customization capabilities are rarely anything more than "nice to have" features that a few select users have found useful in their personal experiences with Internet portals. Users often confuse the sense of self-control that customization offers with the true empowerment that comes with a systematic approach to delivering personalized functionality, data, and information.

Scalable navigation
Have you ever experienced the frustration of using a program that buries functionality three or four levels deep in a series of drop-down menus? Perhaps you've been infuriated by Web site navigation that uses dynamic HTML (DHTML) rollovers to make the entire site accessible from a single page. Sound familiar? Although these techniques have the user's best interest in mind, they typically complicate things. In an effort to make new functionality more accessible without redesigning the entire navigation system, software designers often take the approach of relational menu-driven navigation. Resist this urge!

A much better approach to designing scalable navigation is to layer primary and secondary navigation menus horizontally or vertically within the interface (figure 1). In many instances where the system contains a massive amount of information and functionality, it's preferable to integrate both horizontal and vertical solutions. If done effectively, this approach can result in an infinitely scalable solution. For instances where users have to navigate to multiple instances of the same data (i.e., purchase orders, materials requisitions), consider using contextual navigation within the body of the interface itself. This tertiary form of navigation should present users with short snippets of descriptive text/data to enable them to make better-informed, more efficient navigation choices.

Real estate allocation
When you're discussing the issue of screen real estate -- i.e., the horizontal and vertical viewing area -- it's important to understand the impact of monitor resolution. Although most monitors in use are able to support a screen resolution of 1024 x 768 pixels (or greater), many users have chosen to set their resolution to a smaller viewable area of 800 x 600 pixels. A failure to account for resolution in your design may severely impair your application's overall usability. In the controlled environment of a corporate network where users don't have permission to adjust screen resolution, this might not be an issue (assuming, of course, the software designer plans for it ahead of time). However, as portals and applications are exposed to business trading partners and customers, control begins to disappear.

To prevent these unknowns from impairing your software's usability, follow some basic rules:

1. First determine the resolution for which you'll design. In most cases, a simple poll of your users will point you in the right direction. If you're still not sure, a resolution of 800 x 600 pixels is recommended to avoid the frustrations of horizontal scrolling.
2. You'll have to understand the impact browser controls play on viewable area. Depending on which browser controls and settings the user has enabled (e.g., toolbars, status bars, text options, and icon options), you'll have more or less screen real estate with which to work. A good rule of thumb is to design for the default settings of the browser. A resolution of 800 x 600 pixels, accounting for padding within the browser window, translates to approximately 760 pixels of horizontal space and about 440 pixels vertically to the "page fold."
3. You have to consider the prioritization of content within the screen to determine where content will reside in relation to the fold. In general, you should place higher-priority content above the fold, and insert those items with less importance further down the screen. It's also a good practice to keep all form controls in as small a vertical layout as possible. This approach prevents the user from having to scroll the page as he completes a form with many elements.