Subject: Re: web page 101?
Tue Jan 26 19:52:28 1999



> I have been asked to teach the equivalent of Web Page
> Construction 101 to two of the top executives at a company for
> which I do quite a bit of consulting.
> 
> I know that some of you have done this, but I haven't -- as yet.
> Any pointers as to structure, agenda, curricula would be greatly
> appreciated!


hmm.. 

the first point i'd consider is whether that's actually the most
valuable subject for them to know.   i don't mean to suggest it
isn't.. it's just that in my experience, top-tier management
tends to think more in terms of the big picture than the details
of implementation.   "How To Do HTML Markup" is focused pretty
strongly on implementation, so there may be a mismatch between
the subject and the audience.   unless these execs have a clear
and specific understanding of why they need to know the
mechanics of page markup, it might be best to use a more general
approach.

it's a question of extracting the client's actual requirements
from what they've said they want.   the most common reason for
senior management to request this kind of information is that
they want a better understanding of what's going on with this
whole web thing.   being unfamiliar with the subject, they latch
onto the part which is easiest to identify, and ask for
information about HTML.   that's not really what they want to
know in the long run, but they don't know that yet.   the
consultant's job is to be able to identify misdirected requests
like that and point the client in the right direction.


if your execs are just trying to understand the nature of the
web, and their place in the information food chain, i'd suggest
that you steer them more towards information architecture than
HTML and Javascript.   you can certainly start them off with a
quick overview of implementation issues: markup, page layout,
graphical formats, dynamic content at the server side versus the
client side, and so forth.   just don't dive headlong into the
agonizing details of each subject.   give them enough to feel
justified in paying someone else to deal with it all, and they'll
be happy.

what managers really need to know isn't implementation per se,
it's how to allocate resources to make the deveopment 
process work.   they need to know how to identify a good
implementation, and have a rough idea of what the development
process is.   they need to know where the dependencies are in
development, what the costs are for each stage, and the
consequences of doing a stage incorrectly.


the ability to identify a good implementation comes from having
a good communications strategy, and being concerned about
usability.   the strategy identifies the site's target audience,
the types of communication the site should support, and how that
communication is supported by the rest of the business.
usability lets you decide whether people can actually find the
information they want within the site.

the development process ultimately boils down to the four
classic stages.. analysis, design, implementation, and testing. 
in human terms, those expand to:

    1. deciding what to do
    2. deciding how to do it
    3. deciding what resources are necessary
    4. collecting the resources
    5. putting them together
    6. making sure everything works


in web development, items one is the realm of information
architecture.   i strongly reccommend the O'R&A manual
_Information Architecture for the World Wide Web_ (aka: the
polar bear book) as an accessible but informative reference for
managers who have to make decisions about web projects.  i've
probably handed out a dozen copies of the thing myself.

everything the average manager needs to know about items two and
three can be summed up in three simple words:  ASK THE EXPERTS.
management owns the big picture, but the middle picture belongs
to the people who actually know how to make everything happen.  
unless a manager wants to become an expert on implementation,
their job at this point is to stay out of the way, except to
make sure the proposed implementation is consistent with the big
picture.   page designers shouldn't redefine corporate strategy,
and VPs shouldn't spec database engines.

item four belongs to management again, because it involves
allocation of resources.

item five goes back to the experts, because it's back on the
implementation side.

item six is where both sides sit down and agree that the product
does what it was intended to do.


the information which passes from side to side between
stages is what makes or breaks the project.   it's best to run
through the steps backwards, because it puts the dependencies in
context:

    5 -> 6:  if both sides are going to agree that the product
    does what they want, the product has to have been
    implemented correctly.

    4 -> 5:  if the implementation is to proceed correctly, the
    implementors need the correct resources.

    3 -> 4:  if management is to provide the correct resources,
    it needs a clear shopping list from the implementors.

    2 -> 3:  if the implementors are to deliver an accurate and
    detailed shopping list, they need a good design spec.

    1 -> 2:  to generate that spec, the need a clear, detailed,
    and approved description of what the product is supposed to
    do.


obviously, this is all tremendously simplified.   there are many
different types of development cycle, every stage will involve
negotiations between what's ideal and what's practical, and
everything in life involves a certain amount of guesswork.  
it should be enough of an outline to get your execs thinking in
the right direction, though.