4.
application design
A web application - a web-based piece of software that collects, works on, and
delivers information - is what makes a business-driven, goal-delivering website
different to a collection of static pages.
It stores information in a database rather than as static text in
HTML files, and web pages are assembled by the application in between rather
than being stored as complete pages.
Redpump's method is to write use cases that detail the customer
journeys into, around, and out of the site - and integrate them into
a conceptual model of database, application, and frontend website. A very large
website will contain some 60 use cases; a simple one about 1-5. Use cases are
an ideal base for creating the information
architecture.
A single use case specifies the inputs and outputs
of a single goal (such as 'sign up as a subscriber'.) It includes one diagram
of how actor and actions interact to produce the main result wanted, plus a list
of supporting info that adds detail. A set of use cases describe the totality
of what the site needs to do, and makes the process of creating the site far
faster and more purposeful. It's all about answering three basic questions: What
happens? Then what happens? And lastly, What else happens? That list is built
from this template:
Iteration
Facade, filled, or focussed? The stage of completion the use case has reached.
Summary
In one or two sentences, describe the interaction between user and system that
happens in this case.
Basic course of events
Describe the steps that the actors and the system go through to accomplish the
goal of this use case (the actor always takes the first step, and then the system
responds). This goes back and forth until the goal has been accomplished and
value provided to the actor. Include URLs of the pages the user would see on
his quest where necessary.
Alternative paths
If the basic course of events is the path most travelled, these are the paths
less travelled. Listing these separately from the basic course of events lets
us avoid using 'codey' stuff like IF-THEN-ELSE in use cases.
Exception paths
Unlike alternative paths, exception paths are the paths travelled when the user
does something 'wrong' according to the system's context. I.e. the sort of things
that'd normally throw a 404.
Extension points
An extend relationship shows an association between use cases. It's best to avoid
these since they lead to the dreaded hierarchies which use cases try to defeat.
If there's anything in here, it's a clue to try and do the use case a different
way.
Triggers
These are the entry criteria for the use case - a list of the conditions you
expect to be true when the actor enters this use case, such as the completion
of another use case.
Assumptions
Things we expect to be true in the outside world when the actor enters this use
case, such as knowing how to click on links.
Preconditions
Things that must have happened in order for the actor to enter this use case.
Different from triggers triggers refer to conditions within the system that
drive the actor's interaction along, whereas preconditions simply create the
opportunity for the actor to enter this use case. They're part of the 'contract'
between this use case and the outside world, and are outside the scope of the
system being built - for example, the actor must be a human.
Postconditions
Postconditions are also part of the contract between this use case and the outside
world. They're the result of a user's successful interactions with the system,
such as a project being completed or team members being introduced to each other.
Related business rules
These are the business conditions (not system rules) that give rise to the need
for the system, such as people needing to work in a team. They provide background
for the coder, letting him fit his work into the broader context.
Author
Whoever's responsible for writing and maintaining the use case.
Date/edit history
A list of updates and revisions with dates.
From a set of use cases it's possible to design the web application -
all the 'moving parts' of the site and how they fit together. It means working
out how information is gathered (a signup form) how it gets filed away (database
reqs) what happens to it (business
rules) and how it's used by the customer (saving his profile.)
I use XHTML/CSS web page mockups, hyperlinked together, so the user experience
and content strategy are incorporated early.
Use cases are hard, but ten days spent on them may save a hundred
days of execution time. Next user
experience.