With the Web now completely ubiquitous and familiar, and the frenzy of getting on the Web for novelty’s sake long past, companies routinely turn to the Web to address many types of challenges. A Web site can offer a simple brochure for communicating with customers, a way to disseminate information to people within a large organization, a tool for running complex business processes, and much more. Because different sites try to address different problems, creating them requires different kinds of planning and development.
Although it may sound like a truism, many people have a hard time talking about the distinctions between different kinds of Web development, which makes it difficult to decide how to proceed. This article offers a quick survey of various Web projects and of the techniques that address them.
Basics
All Web projects call for a measure of Web production: creating the HTML, images, et cetera that will manifest in the browser. Though basic, this work remains challenging, even with the many tools and skilled professionals available in the wake of the Web boom. Making appealing, readable pages that load quickly and work for readers with different browsers on different devices remains tricky and demands careful craftsmanship. This goes hand-in-hand with the planning of the site’s look, even if the site does not have ambitions toward flashy visual design.
Where Web projects differ is in the planning they require before production begins. What a Web site must accomplish determines the kind of planning effort it requires.
A company site facing customers or partners should present the company’s brand identity. Companies with solid brand guidelines must provide Web developers with these guidelines and give clear direction about how the site fits into them. New sites, new companies, or Web-oriented companies may call for Web-oriented efforts in developing branding, rather than just an extension of an existing brand identity. This may not require a major effort, but it will require clarity up front.
Any site with static content—in other words, any site—will demand not only the creation of that content but also the definition of the information architecture that defines the navigation for the site. Even the simplest site, with just a dozen static pages, demands a little thought about the information architecture before production begins. And almost any corporate site is more complex than a small online brochure.
Complex sites
Web sites grow complex for three broad reasons. A site may have a lot of content, which makes ensuring that people find what they want tricky. A site with dynamic content makes it difficult to ensure that changing information is current and that it goes to the right place in the site. Last, a site may enable users to take some action, which introduces the possibility that they will not succeed in taking the action they want.
Often, a site involves some combination of these three elements. A news site may have content that is both dynamic and plentiful. An online database may combine large amounts of content with the ability to take action by creating reports. An e-commerce site may combine all three, with a large amount of dynamic catalogue information and the ability to take action by placing orders. Each kind of complexity demands its own combination of planning processes, development skills, and supporting technologies.
Big sites and information architecture
Everyone has encountered sites where they cannot find the information they want, though they suspect that it must appear somewhere in the site’s many pages. Organizing large amounts of information presents challenges that did not start with the Web—authors, librarians, and file clerks have wrestled with these problems for centuries—but doing this on the Web calls for a unique set of skills in constructing “information architecture.” Pages must link to other pages in ways that make sense, allowing users to easily navigate the site and find what they want.
For a site with even just a few dozen pages, information architects perform extensive planning before their work goes into production. Choosing appropriate labels and categories for information can call for research into the information domain, analytical exercises applied to the content, and usability testing with potential users of the site.
Database technologies typically support the organization of a site; any major site today consists of content served through a database, rather than just a collection of fixed pages. While that database may simply make it possible to change the top banner of links on the site without changing pages individually, turning to databases creates the opportunity to do much more, including dynamic content.
Dynamic content and content management
Over time, a site’s content changes. This must happen in a way that doesn’t cause the information architecture to break down. In the case of a mostly static site, this may mean a periodic redesign to accommodate new content. But when a site’s content changes quickly—as on a news site, for example—the site needs to have a structure that accommodates that change in order to prevent the information architecture from degenerating into chaos. This requires its own kind of planning and supporting technology.
The database for a dynamic site must do much more than it does for a static site. For instance, it must know when content first appeared and when it will become “stale.” It may need to know rules for publishing bits of dynamic content to a homepage or other index pages, which requires planning for the way information will appear on the site, the decisions the site will make about what content to present where, and the supporting structure of data associated with content.
Planning for a dynamic site involves not only the basic visual look and information architecture but also logical structures for deciding what to publish where. Complexity arises from looking at how content changes over time or how it changes when personalized for different people; thus, creating a different kind of information architecture work than what goes into a large static site. A dynamic site becomes an exercise in “content management:” the system’s ability to choose the right information to present depends in large part on how people put content into the system.
Many companies have learned that when a site grows big enough, it starts to face many of the same problems as a smaller dynamic site. Information grows stale, authors no longer work directly together, and different readers need to see different elements. Very large sites become less useful as they grow if they don’t have a foundation of good content management in place.
Taking action and interaction design
The Web began as a medium for presenting information, but many sites actually provide something very different: tools for taking some kind of action. Many people miss this very important distinction, even though it dramatically affects the planning that will shape the site and the technology that will support it.
Creating a Web tool means programming software, just like with a desktop application or a client-server system. The more complex the behaviors of the Web tool, the more sophistication the software development group will require and the more your “Web project” will become a software project.
Though most people find Web browsers fairly easy to use, this does not necessarily mean that a tool delivered through a browser will be easy to use. Making usable Web tools presents the same challenges as making usable software or electronics. In fact, delivering a usable tool on the Web can be harder than in a desktop application. If the best way to serve users involves a dynamic drag-and-drop system, you won’t be able to keep them happy with a click-and-wait Web site.
It is imperative to consider usability from the beginning of the requirements-definition process. Doing so requires thinking about some basic questions in your planning, for example: Will people use this tool just once, or will they use it again and again? (If just once, you will want to focus on usability testing to analyze first-timers’ experience. If repeatedly, you will want to research your users’ working context in order to understand their real-world needs.) Will this tool serve customers or people inside your organization? If the latter, do you need to think about how you will train users?
Considering users and usability in early requirements clearly supports defining the behaviors of a Web tool, which in turn provides the software development group with a good picture of what the organization expects them to build. The result is a software development project that is speedy and effective.
No comments:
Post a Comment