Re: process of a site development

----- Original Message -----
From: "Al Gilman" <asgilman@iamdigex.net>
> Please don't fail to make a valuable contribution that only you can make,
just
> because it is not the whole solution to the whole problem.  This is why we
> organize Working Groups.

By no means am I saying this flow shouldn't be worked out because it's
flawed. Actually, in my original response, I had a handful of refinements to
the outline Lisa posted.

> There is an analysis/synthesis process analogous to object oriented design
> that
> can right-size the map of activities for different scales of site
development.

Here's my issue here: someone's going to have to analyze and synthesize that
process, and we can't expect many of them, perhaps even the majority, to
glean what they need from a large-scale example process. I'm afraid that in
the struggle to create techniques to make sites accessible, something like
this could prevent the guidelines from being approachable by people who
might not understand or work within this kind of framework, but would
nonetheless comprehend and be able to comply with the principles of the
document itself.

Which is to say, a lot of people look at the guidelines thinking, "what do I
have to do to satisfy this?" I think we should be answering the "what" (and
the "why", while we're there), but not necessarily answer "how" in a
singular super-size process that smaller groups would need to deconstruct.
Those who are simply digging in to get what they need will look at a
document like that and think, "gee, I need to change my whole process? Never
mind." Or, "Wow. This is a lot of work. I/We can't justify that." When in
actuality neither impression is true.

> This requires input in the form of working examples at different scales.
You
> are not saying "This is what you have to do." You are saying "This is what
> works for us." Just tell what you know.  You are not obliged to solve the
> whole problem.

That sounds like a "best practices" (oh, how I twitch at that phrase)
document, which presumably has a larger scope than this working group. Good
accessibility techniques are an ingredient in development processes that
vary widely from group to group and sector to sector. A refinement, not a
refactoring. I'm not even certain that "what works for us" is something that
could be agreed upon even within this working group, outside of adherence to
the guidelines and techniques that are being produced.

So, here's what I'm thinking. Rather than focus on generalized processes,
might it be more effective to create role documents (techniques for
developers, techniques for designers, techniques for project managers,
techniques for test/QA, techniques for usability, maybe techniques for "I'm
the whole department") that outline what we think they should be thinking
about to build sites, whatever their process is?

----
matt

Received on Wednesday, 31 January 2001 11:51:50 UTC