Designing for Web Services

When information travels beyond your database and Web site, how will it affect your designs?


March 12, 2002
URL:http://www.drdobbs.com/designing-for-web-services/184414503

Designing for Web Services

Learn how to design a system that balances performance with user experience

by Victor Lombardi

April 2002

Many technology companies, consultants, and academics are hyping the future of Web services. But how will this background transfer of data between applications affect the user experience?

The idea of exchanging data among different computer systems isn't new; our bank statements are the result of information passed among credit card companies, automatic teller machines, merchants, and so on. But before the advent of XML, creating a conduit for information between systems was awkward and time consuming. The use of standards will speed development, making it less expensive to create and distribute new applications and information.

Design shops need to prepare for the challenges that Web services create. Designers should ask: What is the best way to implement design systems instead of a single design? Can we predict how people will respond to new customization and personalization options? Web services demand metadata, but who will provide it, and how? Finally, we need to figure out how to balance system performance with administrative effort.

Although Web services run over all kinds of platforms, it's helpful to focus on site-based examples because they offer the most straightforward comparison point when examining the shift in user-experience issues.

The Dynamic Layout

The fact that Web services let sites dynamically discover and display new information presents some design complexities. In traditional design, you can examine the content and create a specific layout. With Web services, you have to devise rules that let the Web site create the layout. For example, imagine a Web site that aggregates news stories on various subjects. This site could use Web services to constantly search for and find new information publishers, subscribe to their syndicated news feeds, and display the resulting stories. The whole process could be automatic.

Consequently, the user interface must morph to accommodate changing numbers and types of news stories. Flexible design is key.

Today's dynamic sites, such as commercial portals and e-commerce sites, work with known information types like news stories and product descriptions. With the advent of Web services, designers may not know in advance what type of information is available. So how do you design for content that's constantly in flux?

Several well-known techniques will help: liquid tables that use percentages instead of pixels, cascading style sheets, and the dynamic presentation that accompanies a content management system. Beyond this, you may want to design different formatting for two different news stories, using combinations of fields like headline, date, and author to create an algorithmic design. Designing for Web services may mean implementing design systems rather than a single design.

Considerations

Web services will change more than just layouts. You may build a page that displays different logos, each of which must adhere to its own branding guidelines. Considering all of the possible design fluctuations is a significant part of the design process. You'll need to consider criteria such as:

Information Channels. Try to anticipate all information channels that will use the data. For example, multiple Web sites, mobile phones, and PDAs. This helps determine how granular your information should be—in other words, how finely to break it up. Increasing granularity provides more flexibility, but requires more effort to tag individual pieces of information.

Design Elements. Pay particular attention to each element: typography, color palette, sound palette, the tone of the text, logos, and so on. Determine the possible ways that each element might change, and how you would want it to change. For example, logos may change in size, background color, and placement.

Design System. Prototyping the design system is crucial. Make prototypes that use various incarnations of each design element. Software testers test at the extremes: 0, 1, and 99,999..., you should do the same. For example, how does your design look if an information provider chooses not to include a logo? What if a partnership arrangement requires you to display ten logos?

A Good Start

You'll have better luck if you can influence the data format at the project's outset. For example, it will be easier to display various logos on one page if everyone agrees to include a version of their logo that looks good on a white background.

If you can, work with the technologists who are defining the XML-based description language that you'll be using. Participating in the process is the best way to ensure that your needs and user needs are met.

By now you've probably realized that designing for Web services will involve renouncing control over some elements. The good news is, once you've designed information components that work across many platforms and situations, they should require less maintenance and can be reused.

If you're an information provider, future reuse may mean more compensation for your work. Applications will discover and subscribe to your Web service, paying you a usage fee. It's possible that interaction designs and layout systems will soon be sold or licensed as stock photography is sold now.

Tech Constraints

Understanding technical constraints is a part of every design project. We don't yet know what all the constraints of Web services will be, but we have some early clues. IBM recently released the Web Services Experience Language (WSXL), an XML-based description language that offers methods for creating interfaces, accepting user input, and distributing these interfaces. It has facilities for displaying branding information and integrating with many other XML-based standards. Visit IBM's WSXL site for detailed information on WSXL (www.ibm.com/developerworks/webservices/library/ws-wsxl/).

Mozilla's method of interface customization is another experimental option. Mozilla uses XUL, an XML-based user interface language, to define its own user interface. Using XML, CSS, JavaScript, and RDF, you can make full application interfaces—not just Web pages—and experience the same kind of process you might have when designing a user interface for Web services. See Neil Deakin's XUL tutorial at www.xulplanet.com/tutorials/xultu/ for more information.

Personalized, Customized

Sometimes dynamic Web sites change based on information from users. Visitors to a portal like My Yahoo use customization to change their content and layout, whereas Amazon.com shows visitors products that they will probably like.

Imagine combining customization and personalization to create a portal that takes advantage of new services offered by various providers. Because new Web services can be dynamically incorporated into a site, you could let the user control the criteria for selecting new information, instead of merely choosing specific types of information.

Users could set up rules like, "I prefer to receive information about soccer, railroads, and long-term bonds; I will pay up to $1 per day for all content; I prefer information from the BBC, CNN, Rail Today, and the Wall Street Journal." You might then combine this rule with collaborative filtering and marketing plans to create a selection of available Web services. Predicting how people will want to use these systems becomes a new experience-design challenge.

Unfortunately, more automation means fewer opportunities for humans to perform quality assurance checks on the information. For example, will people trust unfamiliar news sources when they suddenly appear in a portal? You must foresee these events and shape the design to help build trust and appropriately identify resources.

Of course, user information can also be published more easily than before. Privacy concerns may rise to a new level. A solution is to offer users more specific control over their information, choosing information with a rule-based interface like the one outlined above. One such rule could be, "Never distribute my phone number; prompt me when a service requests my email address; do not prompt me when requesting basic demographic information used for personalization."

Multiple Platforms

When XML was new, our industry hailed it as the key to standardizing data across many platforms—Web browsers, mobile phones, personal digital assistants, and so on—without requiring a complete redesign for each platform. For the most part this has failed to happen because XML alone wasn't enough.

The new Web services description languages look like they may help realize this dream. Accordingly, designers must start thinking about which platforms might display their information. For efficiency reasons, it's helpful to create design elements that work across as many platforms as possible. Again, prototyping will be crucial. Only by testing your designs on each platform will you be able to see which elements work across platforms and which need to be customized for each platform.

For example, a news story headline should be short enough to be read quickly on a mobile phone. However, on a Web browser you may want to use a longer, more descriptive headline because you have more space. This might require authors to type in multiple headlines, so you should consider how to balance system performance with administrative effort.

A Common Language

Web services only provide the syntax for exchanging information; they can't specify its meaning. That's where experience designers, especially information architects, can play a role. For Web services to work, we need common vocabularies. Perhaps you run a site that lets visitors shop for and compare bicycles. Some manufacturers may use terms like comfort bikes and mountain bikes while other manufacturers speak of hybrids and off-road bikes. These terms need to be standardized, at least as far as the metadata is concerned, for computers to communicate without human intervention.

Information architects commonly collect diverse information and organize it into taxonomies, arranging information so that it can be systematically managed. Taxonomies rely on a controlled vocabulary, a standard set of terms, to normalize the information. Table 1 shows an example of how to normalize terms for three different bicycle manufacturers to create one category—bike types—in the taxonomy.

table 1: Standardizing content terms

Bicycle Brand 1 Bicycle Brand 2 Bicycle Brand 3 Standardized Terms
Road Bikes Racing Bikes Road Road Bikes
Comfort Bikes Cross Bikes Hybrid Hybrid Bikes
Mountain Bikes Off-Road Bikes Mountain Mountain Bikes
Tandem Bikes Two-seaters Tandems Tandem Bike

Designing for Web services will involve similar tasks, but instead of organizing the information for one Web site, the challenge will be to create a standard organization that will work for diverse platforms and uses. Yet the organizational methods we're used to, such as taxonomies and controlled vocabularies, are the same ones we can use to organize the information communicated by Web services.

Powered by Metadata

For Web services to work, one piece of information must be distinguishable from another. Metadata accomplishes this by providing information about information, such as labeling a particular news story a business story. Creating user interfaces for easy metadata creation will be a prosaic, but important, element of designing for Web services. Services can break if there is so much as a misspelling, so helping people enter accurate metadata will be important. While this can be automated in some cases, in many cases it cannot.

Also, because entering metadata isn't the most thrilling activity, humans can get sloppy. The user interfaces that collect metadata must balance the system's endgoal without overburdening users.

User-Centered Design

The standard user-centered techniques we use now in design research and testing phases will work fine for building Web services. All of the data that's exchanged and manipulated by these systems is ultimately meant for the benefit of humans, whether it's for transferring money or finding a rental car. Metadata that's meant to benefit users should be derived from research on those users.

Presently, Web services are considered a technical issue, the domain of programmers. But in the process of building the technical infrastructure, human needs can get lost. Designers must insert themselves into the Web services design process early and often to represent users' needs.

Making the Invisible Visible

Industry evangelists tell tales of computers solving problems on their own, effortlessly searching the Internet for information and piecing it together to answer our every need. Once the computers are exchanging information seamlessly, we can fully automate many tasks and never have to think about them, right?

At least in the immediate future, this isn't the case. In reality, most "automated" systems require some sort of user interface. For example, autopilot systems have contributed to plane crashes because they either didn't properly alert pilots to a problem or compensated for a problem so quietly that pilots weren't aware of it. While most of our applications don't have life-or-death consequences, they will contribute to lost productivity and frustration if users can't properly interact with the systems.

When developing Web services we should ask:

New Ways of Working

Because invisible, partially automated Web services don't exist as Web sites, they have the potential to change the way we design. Web services can go anywhere we can put a tiny Web server: in our cars, our phones, our televisions, or our wallets. Yet so much of our work focuses on Web sites, from the expertise we have, and the work in our portfolios, to the way we speak to clients. The advent of Web services means that design teams must stretch their skills beyond the browser.


Victor ([email protected]) is an information architect and experience lead at Razorfish, in New York City.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.