email kara reuter email patrick lavergne

Web Site Design 2 : Web Authoring Tools CLASS: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12

CLASS 1


THE PROBLEMS OF WEB DESIGN

Flexibility

Same old new medium?
The Web is a new medium, although it has emerged from the medium of printing, whose skills, design language and conventions strongly influence it. Yet it is often too shaped by that from which it sprang. "Killer Web Sites" are usually those which tame the wildness of the Web, constraining pages as if they were made of paper — Desktop Publishing for the Web. This conservatism is natural, ... but it is time to move on, to embrace the Web as its own medium. It's time to throw out the rituals of the printed page, and to engage the medium of the Web and its own nature.

Controlling Web pages
Spend some time on Web design newsgroups or mailing lists, and you'll find some common words and ideas repeated time after time. Question after question, of course, is "how do I?". But beneath questions like "how do I make my pages look the same on every platform" and "how can I make my fonts appear identical on the Macintosh and Windows" is an underlying question — "how do I control the user's browser?" Indeed, the word control turns up with surprising frequency.

Underpinning all this is the belief that designers are controllers ... Designers want to override the wishes of users, and the choices that they have made about their viewing experience (by "fixing" font size, for instance). Designers want to second guess platform differences, caused by different logical resolutions (for instance the Macintosh's 72dpi, versus the standard Windows 96dpi). Designers are all knowing, and will not tolerate anything less than a rendering on every browser that is pixel perfect with the rendering on their own machine ...

Where does this idea come from? I believe it flows from the medium of print. In print the designer is god. An enormous industry has emerged from WYSIWYG, and many of the Web's designers are grounded in the beliefs and practices, the ritual of that medium. As designers we need to rethink this role, to abandon control, and seek a new relationship with the page ...

Why does it matter?
The fact we can control a paper page is really a limitation of that medium. You can think — we can fix the size of text — or you can think — the size of text is unalterable. You can think — the dimensions of a page can be controlled — or — the dimensions of a page can't be altered. These are simply facts of the medium ... The control which designers know in the print medium, and often desire in the Web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the Web doesn't have the same constraints, and design for this flexibility ...

Adaptability is Accessibility
The flexibility I've talked about so far I think of as "adaptability." Everything I've said so far could be summarized as: make pages which are adaptable. Make pages which are accessible, regardless of the browser, platform or screen that your reader chooses or must use to access your pages. This means pages which are legible regardless of screen resolution or size, or number of colors (and remember too that pages may be printed, or read aloud by reading software, or read using Braille browsers). This means pages which adapt to the needs of a reader, whose eyesight is less than perfect, and who wishes to read pages with a very large font size.

Designing adaptable pages is designing accessible pages. And perhaps the great promise of the Web, far from fulfilled as yet, is accessibility, regardless of difficulties, to information. It's an important belief of the World Wide Web Consortium, and is becoming an imperative of Web design, as Web pages will be required by law to provide universal access, just as building codes around the world require access to buildings.

It sounds an impossibility, designing the universal page. Perhaps now it remains an aspiration, with browsers so broken, and many of the devices through which we will access the Web in their infancy, or not yet born. But there is a lot we can do now which will set the foundations for pages which adapt to the users wishes and needs, and so will be accessible ...

The Journey
Now is the time for the medium of the Web to outgrow its origins in the printed page. Not to abandon so much wisdom and experience, but to also chart its own course, where appropriate. The Web's greatest strength, I believe, is often seen as a limitation, as a defect. It is the nature of the Web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all. The journey begins by letting go of control, and becoming flexible.

— John Allsopp, A Dao of Web Design, A List Apart

Architecture

In the pre-[Graphical User Interface] (GUI) era, we had invisible navigation, often termed the "black cave metaphor." Users would eventually, if unwillingly, adapt to their surrounding, building in their minds elaborate mental models of the elaborate invisible navigational structures. This metaphor came about not so much as a function of the technology, but the technologists. Engineers were in charge, and engineers, with their superior ability at forming mental models, do well in black caves.

The GUIs released users from the discomfort of the cave, both by eliminating most traditional navigation and by making visible that which was left. Users were able to learn new software quickly and use it effectively, all without the uncomfortable task of building mental models.

...

The entire web approach ... returns ... to the old navigational model of the mainframe, abandoning the GUI's reversal to zero navigation. And users are no longer expected to build a mental model of perhaps forty or fifty screens. Now they're suddenly expected to be able to handle millions.

— Bruce Tognazzini, The Sorry State of Web Design, AskTog, October 1998

Navigation

For almost seven years, my studies have shown the same user behavior: users look straight at the content and ignore the navigation areas when they scan a new page. (Remember, users almost always scan — they rarely read carefully online.)

...

Some analysts conclude that navigation is useless and that navigation elements should be removed from Web pages. Don't try teaching users the site structure, don't try showing them where they are, don't try telling them where else they can go. Instead, just show people content. I don't fully agree with this analysis.

Hypertext research from the 1980s showed that structure does help users navigate ... [but] Web sites can be designed better.

— Jakob Nielsen, Is Navigation Useful?, Alertbox, January 9, 2000


PLANNING AND ARCHITECTING A WEB SITE

EX LIBRIS CANDY REVIEW
Site Plan

Goal

Empower candy-lovers with thoughtful, fun reviews to help them make an informed choice at the candy counter.

Audience

  • University of Chicago undergraduates
    • early adopters
    • savvy & hip
    • intelligent & single-minded
    • disposable income
  • Other patrons of the University of Chicago library
    • may have older computers/systems and slower connections

Usage Scenarios

  • User has a taste for some kind of candy (chewy, sour, chocolate), but isn't sure exactly what they want and want a recommendation they can trust.
  • User knows exactly what kind of candy they want, but can't remember whether Ex Libris carries it.
  • User just wants to find out what the "experts" think is the best candy.

Competitive Analysis

  • Fan sites:
    • The Ultimate Bad Candy Web Site
      • Tone: Irreverent, quasi-scientific
      • Content: Humorous personal narratives and ratings of candy (on appearance, smell, consistency, taste); includes scanned images of candy and packagining, as well as "re/action" shots
      • Look & feel: Busy, kitschy, graphics overload
      • Site structure: Organized by candy (16 total)
    • The Quasi-Comprehensive Candy Bar Wrapper Image Archive (With Semi-Useful Nutritional Information)
      • Tone: Earnest
      • Content: Scanned images of candy wrappers, including nutritional information; frequently asked questions
      • Look & feel: No-frills; self-described as "cotton candy color, sort of representing sugar, candy, and all things sweet"
      • Site structure: Organized alphabetically and by manufacturer; also searchable
  • Manufacturers:
    • Jelly Belly
      • Tone: Inviting, cordial, informal
      • Content: Online store, factory tour, company history, fan club details, "menu" and "recipes," gallery of jelly bean "art," etc. (available in 14 languages)
      • Look & feel: Clean, colorful, cute
      • Site structure: Organized into 7 content categories (About Us, Where to Buy, Fun Stuff, Legal Stuff, etc.)
    • Ferrara Pan
      • Tone: Official, old-fashioned, educational
      • Content: Candy store, company and candy history and "factoids," including video of manufacturing process, games; includes scanned candy packaging images
      • Look & feel: Rich, bright colors, somewhat retro
      • Site structure: Organized by candy (6 total) and content category (i.e., History, Fun & Games, Story)
    • Wild World of Wonka
      • Tone: Whimsical, lively, kid-friendly
      • Content: Games, puzzles, trivia, store, fan club
      • Look & feel: Brightly-colored, cartoonish, animated, multimedia-enriched
      • Site structure: Organized as a Candy Factory with "rooms": Planet Vermes, Loompaland, Willy's Office, Candy Garden, etc.
  • Other:
    • Candy USA
      • Tone: Promotional, ingratiating (presented by the National Confectioners Association & Chocolate Manufacturers Association)
      • Content: History of candy, candy statistics, trivia, recipes, nutritional information, etc.
      • Look & feel: Amateurish, mismatched
      • Site structure: Organized into 12 content categories (e.g., Trivia, News, Stats, etc.)
    • Candy, Candy, Candy, Inc.
      • Tone: Warm, nostalgic
      • Content: Candy store with scanned images of candy and descriptions
      • Look & feel: Old-fashioned, fussy
      • Site structure: Organized into categories related to shopping functions (bulk pricing, corporate accounts, gift baskets, etc.) and candy types (old time candy, wax candy, chewy candy, sugary favorites, lollipops, gum)

Site Content

  • Introduction/welcome
  • Reviews of candy
    • Text
    • Iconic ratings (in different categories?)
    • Images
      • Candy
      • Candy wrappers
      • "Action" photos
  • Overall rankings of candies reviewed
  • Links to other candy Web sites
  • Bios of reviews/about the project

Access/navigation goals

  • Browsable hierarchically by flavor category
  • Browsable on-demand with full menu of candy

Site Structure

  • Must be scaleable for addition of new reviews and new categories
  • See flowboard

Look and feel

  • Candy-colored, splashy, appetizing
  • "MTV meets academia": cartoonish and trendy without being childish

  1. Define your site's goals
    If you don't know what you're trying to achieve, why bother building a site? Establish a clear, well-documented idea of what you are about to do. Your statement may be broad or may seem simplistic, but it's important to have a goal guiding and backing up your design process.
  2. Define the audience
    Outline the type of audience you expect to be accessing your site:
    • Demographically (age, gender, income, etc.)
    • Functionally (users, viewers, readers)
    Add as many audiences as you can think of to the list. If the list gets too long, you may have to break it down into categories. List the primary audience first, followed by other significant user groups. Also keep track of the defining characteristics and special needs of each intended audience.
  3. Create usage scenarios
    Based on your site goals and your audience breakdown, think about how your users might access content on your site. Try to come up with a set of users who represent the majority of visitors. The size of the site and audience determine how many users you will write scenarios for. Usually three to six scenarios are sufficient, but you may need to come up with as many as 20. To get started on a scenario, you need to bring the user to life. Create a character for that user, and give him a name, a background, and a task to accomplish on the site. Then write a story about how the character uses the site to complete the given task. Scenarios will be important later on, when you are defining the content and functional requirements of the site and ultimately to validate the site's design once it's finished.
  4. Conduct competitive analysis
    Your users will have formulated their expectations for your Web site by visiting other Web sites and will likely come to your site after visiting others like yours or from a search that turned up several sites like yours. Do a few Web searches to make a list of your "competition" — or other Web sites that are like yours in terms of content, functionality, or scope. Generate a set of features and criteria on which to evaluate each site. Start with your goals, using them as the basis for a set of features in your competitive analysis. As you evaluate sites, be sure to add any features or functionality you find interesting. Criteria include things like download time, page size, layout, and look and feel. Every feature or criterion can be evaluated in two ways: a simple check mark or a number from 1 to 10. For example, if you are comparing whether sites offer free email accounts, that can be done with a simple check mark. However, evaluating the look and feel of a site is more subjective. Also, take notes and grab screen shots of each site.
  5. Define site content
    Using the list of goals, the needs of your audience, and your competitive analysis, start a list of potential Web pages or types of content that you can think of. Browse the sites of your competition, and add any pages that are not on your list. Also, identify the types of material you will need on each of these pages, including text and graphics. Together, this comprises your content inventory.
  6. Define access/navigation goals
    Think of the site structure as a skeleton that holds the body together. Without it, your site will be a jumbled up, confusing mess. A good metaphor can go a long way in helping users understand how to use and navigate the site. Consider approaching your site's structure with one of these three types of metaphors:
    • Organizational (rely on the existing structure of a group, system, or organization)
    • Functional (relate tasks you can do on the site with tasks you can do in another environment)
    • Visual (common graphic elements familiar to most people in our culture)
    Try to map out the major sections of the site by connecting elements from the content inventory to each metaphor. However, no metaphor is perfect, so don't feel that you have to adhere rigidly to just one. You could take the best parts of several metaphors and roll them into one. Or, you might not find any useful metaphors at all — think instead about the different ways your users might want to access your site's content.
  7. Define site structure
    After you've developed a rationale for the site structure, create a text-based, hierarchical map of the site in the form of a basic outline. Start with your top-level sections and fit them to your rationale or metaphor. Next, map out the organization of each section with items from the content inventory. Next you will want to visualize this list. Many people have a hard time seeing something like the site structure listing and translating it to the way the site will work. Try using a flowchart or storyboard — or "flowboard" — as a diagram showing how elements of the site are grouped and how they link or relate to one another. You'll need to make up a legend that defines how on- and off-site links, page components, pages, and groups of pages are represented in the diagrams. You might want to distinguish among parts of the site that perform a function or transaction, parts of the site that are generated dynamically, and pages merely comprised of text.
  8. Define look & feel
    Provide a statement about the character of the Web site you wish to create with the color scheme, style of graphics, and the like. Include sketches of graphics or mock-ups of pages — or "thumbnails" — to illustrate your vision.
— Adapted from John Shiple, Information Architecture Tutorial, Webmonkey


FURTHER READING

Defining Web Design

Site Planning


ASSIGNMENT

Prepare a site plan for the site you're going to build for this class, including a "flowboard" or other architectural diagram.


NEXT CLASS

Designing your Web site



school of the art insitute of chicago


division of continuing studies