User Interface Design for Web Applications
It’s a Different World from Web Site Design
In: Articles
Published on November 12, 2003
This article could be also be titled “Things I Wish I'd Known Before Designing My Latest Web-Based Application.” You see, I had experience designing Web sites. I’d mastered the art of creating catchy content. I worked with Web-savvy graphic artists who provided masterful images. I knew the latest HTML coding tricks and could design around the various browser quirks and incompatibilities. Armed with these skills and experiences, I volunteered to design the user interface for one of my company’s Web-based applications—and dove right in.
OK, diving didn’t work. I learned quickly that the design choices one makes for a Web-based application are often quite different from those of a content-based Web site. Why? Because they are used for different purposes. Duh! (Mental head slap.)
I needed to look at each design choice from a different angle—because I was now playing by different rules. As I made my way through the maze of design decisions, I took note of the things I did differently from my Web site projects. This article explores some of the lessons I learned along the way.
Content vs. User Entry Forms
Think about the Web sites you visit. What do you find there? Content. You see lots of text, graphics, color, animation, and sometimes even glitz and gimmicks, right? Most Web sites are designed to encourage browsing, searching, and exploration. Most importantly, they are designed to attract visitors and keep them interested.
Now think about the applications (software products) you use. You use them to complete tasks. Rarely do you see exciting graphics or animation (well, OK, unless you’re using a graphics tool or a game). Rarely do you browse, search, or read lots of text—unless it’s the online Help. You are a fairly captive audience and don’t need glitz or fascinating content to keep you there. What you do need are quick and easy methods to complete your tasks.
The Web-based application I was working on was created for system administrators in an intranet environment. These administrators would perform tasks such as adding user-IDs, configuring network components, and generating diagnostics reports. Unlike the content-based Web sites I had designed, this user interface would consist primarily of user entry forms and the navigation elements needed to find and execute the forms. There would be very little text—just the labels for input fields and other form elements—and only the most functional of graphics.
The first lesson I learned was that each design decision is dictated by the focus of the project. The focus of my previous Web site projects was content; the focus of the application’s user interface was task-based user entry forms.
As I worked through the prototyping, usability testing, and implementation of this user interface, I was constantly reminded that even the most mundane design choice needed to be examined in a different light. Here are some of the design differences I encountered.
Visited links: Most Web sites use a different color for “unvisited links” than for “visited links”; this enables users to quickly identify pages they’ve seen. But when using an application, users don’t really “visit” pages; they perform tasks such as entering data into forms. A user might fill out the same form many times (for example, to add several user-IDs to the database), so it’s not important to distinguish which pages have been visited. In cases like this, it’s preferable to specify the same color for the unvisited links as for the visited links so all links look the same.
Frames: The use of frames is a hotly debated topic in Web design. Whether this is because frames have been poorly implemented in most Web sites or because they are inherently flawed, I’m not sure. Have you ever clicked on a link in the left frame of a Web page to display an article or story in the right frame, and then tried to bookmark that article using your browser’s menu bar? You can’t. Or have you tried to grab the URL of that article to send it to a friend? You can’t. (Well, OK, with some browsers you can do both of these things with the right-click menu or by calling up the frame in a new window—but both techniques are rather cumbersome and hardly intuitive!) As Jakob Neilsen points out in his classic article “Why Frames Suck (Most of the Time)”, frames wreak havoc with the user’s mental model of Web pages.
So what about using frames in a Web-based application? Some of the problems still apply—but not all. For example, most people wouldn’t bookmark a specific page within an application. (If they did, they might get unexpected results due to security features or additional application processing required for that page.) Same thing for grabbing a URL and sending it to a friend. So, although the use of frames is still subject to debate in the world of Web-based applications, the issues are a bit different. If using frames, you would be well advised to conduct thorough usability testing—well before full implementation.
Searching: Most content-based Web sites are designed with searching in mind. They use specific strategies to increase their relevance rank with the major search engines, and many have their own search capabilities. Well-designed Web sites provide navigation and contextual orientation cues on each page—in case a user searches the Web and lands on a page within the site. In contrast, applications (Web-based products) rarely involve searching—except in the online help system, of course. The skills and strategies used to craft search-friendly Web pages aren’t needed when designing an application. Instead, the focus is on ease of navigation and form design.
Page titles: In Web site design, it’s considered good practice to use a unique page title (the text that appears in the browser title bar) for each page—for several reasons. First, it enables users who bookmark the page to quickly identify it in their Favorites. Second, it provides context for users who land on the page from outside the Web site, such as from a Search engine or hypertext link. But as we’ve already explored, bookmarking pages within an application is generally discouraged. And the concept of landing in the middle of an application while on the Web generally does not apply. For that reason, it might make the most sense to use the same page title on every page—perhaps indicating the application name and version.
Hypertext vs. linear tasks: In most Web sites, users can jump from one page to another using hypertext links. Designing good hypertext requires some thought about how and when to link to related content. But with applications, users perform tasks, which may require linear paths through the pages and additional application processing when a user navigates from one page to the next. This requires a different kind of design, one that focuses on navigation among tasks rather than hypertext among pages of content.
Scrolling: Scrolling is another hotly debated topic in Web design. Would users rather see a small number of long pages or a large number of short pages? As you can see from the multitude of styles out on the Web today, there is no right answer. But how about for applications? The choice depends on how data-entry-intensive is the application and how long the pages take to download. A user who is content to scroll through a lengthy page of text and graphics may find it cumbersome to scroll through a form while filling out the fields. However, if moving from page to page requires lots of background application processing and the pages take awhile to download, users may prefer one long form. This design choice is best made with the help of some usability testing.
Cross-browser considerations: Most Web sites are designed to work properly with all—or at least the most widely used—Web browsers. Designers often use browser-safe colors, avoid browser-specific capabilities, and perform thorough testing of their pages on many browsers and browser levels. Designers of Web-based applications, however, may have more control over the target environment, depending on the situation. They can specify a required browser, much like they specify the required hardware or operating system environment. This gives them more freedom of design and more choices for implementing browser-specific capabilities.
Browser buttons: Web users have come to understand and expect specific behaviors for common browser buttons. The Back button displays the previously visited page. The refresh button reloads the page from the server. But using these buttons with a Web-based application could yield unexpected results. For example, although the Back button may return to the previous page, it might not execute the associated application code, which could mean some of the displayed data is no longer current. For this reason, some applications provide instructions warning users to avoid these buttons—and even to hide the standard toolbar on their browser. And the designers often provide alternate navigation methods so users can move among pages without relying on these browser buttons.
Pulldown navigation menus: Many navigation schemes use cascading menus: The top or side of the page lists choices that, when moused over or clicked on, open successive levels of submenus. This scheme allows users to access pages deeper within the site without having to click through intermediate pages. However, when considering this technique for a user interface that uses forms, designers may encounter a serious technical glitch. Some browsers always display certain form elements, such as dropdown selection boxes, on top of all other page content. This means that part of a navigation menu could be obscured by form elements, preventing users from accessing the pages available from that menu. Before implementing such a scheme, you should be sure to test it with all the form elements that may exist in the user interface to avoid a major SNAFU!
Home page: Typically the first page you see on a Web site is its home page. It often describes the content areas of the site, contains news stories, describes what’s new on the site, promotes a product or service, and so on. What should the Home page of a Web-based application contain? Here are some options, along with considerations for each:
- A “main menu” like that of many traditional applications
But note that the widely-used pulldown menu navigation schemes would likely negate the need for a whole page devoted to a menu. - Product overview information or online Help for new users
Although they may be useful for novices, these items would likely annoy advanced users. And this Help information should be readily available from all pages anyway, so taking up prime space on the home page may not be the best choice. - Typical “splash screen” content containing a product graphic, version level, and copyright information
These are typically available from the “Help” or “About” page, and possibly a splash screen that disappears after a few seconds, so including it on the Home page would serve no additional purpose. - System statistics or other live data, if appropriate
Depending on the product, additional application processing can add to the page download time, which is an important factor in deciding whether to include such data on a frequently visited page like a Home page. - Nothing—do not use a Home page
The concept of the Home page came about with the advent of the Web, but does not exist in traditional application design. The fact that an application has a Web-based user interface does not mean it requires a Home page. Designers may find it’s best to leave it out, assuming users can readily understand what to do on the default page that’s displayed and that there is intuitive navigation to other parts of the interface.
As you can see, each option has its drawbacks, and there isn’t one right answer. The decision involves many factors, including download time, ease of navigation, and of course, the purpose of the application.
Help: The online Help on Web sites typically takes the form of Frequently Asked Questions, a welcome/overview for first-time visitors, a site map, and possibly instructions for customizing or using the Web site. In contrast, the online Help for an application typically consists of conceptual or background information about the application and how to use it, as well as context-sensitive help for pages or individual fields of a form. Help can also be found in the wording of system messages and links to more information about how to correct problems. Overall, the online Help for Web-based applications is more like that of traditional (non-Web-based) applications than for content-based Web sites.
Major “Mental Head Slap”
Whew! After taking on this user interface project, I’m a lot more insightful about design issues and, well, rather humbled by the amount of design savvy I have yet to gain. Yes, the project was successful. But I owe its success less to my previous Web design experience than to my willingness to throw out (or at least amend) everything I thought I knew about Web design and look at it from a new angle.
Sometimes the toughest lessons to learn are also the simplest. Whether you’re designing a Web site, a user interface for an application, or anything else, your design decisions should be driven by the purpose of the deliverable and the needs of the user. Well, duh!
form here文章来源:http://jinweijie.blogspot.com/2006/09/softwareuser-interface-design-for-web.html