What kind of objects are these?

The kind of objects that we care about are just chunks of text, with associated art, sound, video-a single unit of meaning, with all the necessary components.

Unlike programming objects, an informative object has a limited function, which is to respond to a question or need of a consumer by providing some kind of information (no calculating the interest on a bank loan, or figuring out the extended price). The main activity your informative objects perform is to display themselves, when told to.

When should we display these informative objects?

To figure out when and where to display an informative object (and for whom), you develop little scenarios called use cases. You sketch out little scenes in which one or more actors get involved in tasks, leading up to an event, which is handled by one or more objects.

For programmers, these tasks, events, and objects can be quite complex. But for writers, the picture is crude.

1. Someone comes to the site with a goal in mind, and starts acting to attain that goal.
2. Those actions set off various alarms, signals, and activity in the software. These events trigger the software.
3. The software compares the person's profile with the relevant business rules.
4. If a rule matches the situation, the software displays a new object.

You probably don't care about the subtleties of event handling, triggers, or object methods. You just want to know: who comes to the site and does something that deserves special content, wrapped up in an informative object? The story describing the situation is a use case.

A use case, then, offers the following information:

• A story, often with screenshots and imagined conversation, and internal dialog.
• A description of a complete and meaningful experience from the consumer's point of view.
• A focus on the goals of the user, rather than the mechanics of the software
• A way of figuring out how to improve your site, not just record the current process

Sort your use cases

Once you have developed a few dozen use cases, you can start shuffling them:

• Which ones are the most important to the consumers?
• Which ones really involve offering substantially different content?
• Which ones cause the most problems, raise the most questions, and require the most support?

Use cases live most comfortably in an environment of content management software built on top of a database full of objects that get assembled on a moment's notice to form pages for a particular visitor. But use cases make sense even if you are hand-coding your pages.

Cautions on use cases

Unfortunately, unimaginative use cases often end up describing current practice, suggesting no need for new content.

And even when the team focuses on problem areas, the theme is often just usability, with the subtext of action and transaction. But that encourages the team think about what is doable rather than what consumers really want. In the world of objects, people can easily become stick figures.

Use rules to identify content to deliver to each group or person.

Example: Your demographic database tells you that most people who live in ZIP code 87107 own horses, and belong to a demographic segment known as "Rural Red White and Blue," sharing country values such as patriotism and 4-H clubs.  So you could make up a rule saying that anyone from that kind of ZIP code should get information on horse care and feeding.
 

Make inferences from the user's choices, behavior.

For instance, if the user chooses to view the Overview of the Developer Edition, then chooses to view the Schematic, and probes down to the Specs, you may compare this behavior with other people who made the same sequence of choices.  All those people ended up going to the Developer Reference; most went to the Developer Discussion; some asked for the Design Guidelines; and a few asked for Developer Tips.

So we arrange a sidebar menu offering those topics in that order.