[thelist] Re: site building

Techwatcher techwatcher at accesswriters.com
Fri Jun 21 13:16:01 CDT 2002


>
> 	All the suggestions that you've heard here are really good.
> Nothing beats planning. One thing that I didn't see mentioned was the
> use of a flowchart. I find this, in addition to the paper layout can
be
> invaluable in debugging issues later. Since other people have added to
> the pencil-on-paper-design part of it, I will go with the flowchart
> part.

Hi, Chris (et al),

Caveat: This approach is very unpopular with a certain type of "Web
designer" but it works for me. I regard the Web as a kind of document,
one which is ideally approached from the pov of what I call a "visual
organizational metaphor." So, first I think a lot about my client: What
sort of images would quickly clue in the user to what this client is
all about?

If I come up with something, can I make that an extensible visual
metaphor? For example, if I'm dealing with a writer (or publisher),
could I use a shelf of books and link from each book to excerpts, with
a link (or embedded form) to buy it? I want to come up with something
that a user will know how to use, but has SOME originality to it. This
can be very hard, however, so there's a second approach to fall back on:

Revert to my normal processing as documentation specialist, and gather
the usual information as if I had been hired to document
systems/programs/procedures for a corporate entity:
Who is the intended audience?

What do they need to be able to do with the finished project? (I.e., is
it for training? Then include examples -- links or not, internal or
not... Should people buy your product online? Do you give them preview
information -- what credit cards/payment forms you will accept once
they fill out the form and get to the point of paying? Is there a
visible link for returning product if there is a problem?)

What corporate resources are available, and what is the attitude of
high-level management to using/committing those resources to this
project?

Once I have an understanding of all of the above. I try to get a sense
of this client's budget. Then, the following criteria completely define
my development of the document: organization, formatting, and style.
Organization is embodied in the Table of Contents, or online navigation
aid.

Notice I said organization is embodied in nav or ToC, not determined by
it! Among the factors that determine ToC are audience and functions.
I.e., for upper-level management, you usually offer a functionally
oriented ToC; but for clerical staff, you might offer a synchronous
organization: Do this first, then this. (For actual documentation: this
happens on Mondays; this happens at end of month. For Web sites, is
there a cycle of whatever the site's main function is?) For an audience
of both, make sure there is a functional overview prior to the detailed
instructions (the clerk might skip it; the executive only reads this
and skips the details). You can usually find a way to impose a
narrative structure, although not many users will follow it in a linear
way. This "narrative structure" is useful to the mind; it helps us
organize/remember/chunk stuff. Your readers will find it easier to read
stuff with an "imposed narrative structure," too.

Can you use the problem/answer structure? Can you use the
first/then/next structure? Find something!

Once you have a working (DRAFT) ToC/nav aid, you are ready to draw up a
contract or schedule for deliverables. Do try to remember that this
will always have last-minute ("oh, I forgot!") changes, though. Since a
nav appears on all online pages (or, probably should, in some form),
try to put it in an SSI or template -- something where you can easily
update it, anyway, without updating all pages). Also, if not all pages
will have contact info built-in, make sure users can easily reach/link
to contact information, without too much effort. Sometimes I make my
banner.gif -- except don't use that name for this file any more, since
ad-avoiders will make it invisible! -- always a link to contact info.
(This content is normally in the running header/footer for off-line
documents, but online, it's up to you to be sure it's somewhere that
makes sense to the site's users.)

Since you, in particular, are working internally, rebuilding an
existing site, your ToC (or nav aid?) should be circulated internally.
Circulate it with strong encouragement to give you feedback. What would
they like it to do that it won't do as shown? What do they like? What's
missing?

We're not talking about HOW it works/neat gizmo's to click -- just get
a "good list" of what info should be there, somewhere. Btw, being
specific (and wrong) will bring in better feedback than being general
(or correct), so use this strategy if you have a strong enough ego.

Be explicit about not being think-skinned, make the rounds in person
asking for advice. Thank everyone, even if the advice is nonsense
(don't discourage anyone who might overhear your response -- they may
have great advice for you!).

Once you know what should be on the site, let your subconscious try
again at coming up with a good extensible metaphor, or just play with
images. Sooner or later, you'll come up with a design.

If nothing else, go play with a color selector, and then use the
default "tabbed magazine" sort of design every other Web site seems to
use these days. If you don't know anything about color, google for a
nice tutorial. (Contrary to popular opinion, this is not stuff ruled by
opinion -- colors DO have specific physiological effects.)

If you don't know anything about fonts, or readability, ditto. Finally,
read the standard stuff about writing for the Web (look up readability,
if all else fails), and make your authors (unless that's you) revise
their text to fit this hard-to-read-in medium.

Above all, HAVE FUN! Let your mind play, and it can do great things. (-8

Cheers --
Carol Stein
techwatcher at accesswriters.com





More information about the thelist mailing list