Re: process of a site development

My observations:
- I think the "requirements and scope" line item Robert brought up goes
before brainstorming, and it includes audience (intended and potential) and
the constraints of the system. If WAI is publishing this, it also needs to
convey the message that you need to set the bar for accessibility and
standards compliance before you start even high-level design. I can't
emphasize this enough: it's an order of magnitude more difficult to make
sites usable, accessible and standards-compliant with each step that's
completed without answering these questions.

- "Content" may belong anywhere (or everywhere, or nowhere) in this flow.
Content provision could happen before the site is designed (legacy content),
at any step in the process (e.g., media sites), or even after the site is
released (data entry apps). The information architecture that accommodates
that belongs in scope/brainstorming/storyboarding (but no later).

- Usability testing isn't a step, but an iterative process. (And I'm pretty
sure I'm not saying this so I as a usability person can get more work. ;) If
I were following this flow, I'd run usability on paper mock-ups after
storybook, again after prototype, alongside testing, and after release.

- I think "Release" should be a step in there, as well. Preferably before
"Promote", though there are companies I've seen who believe otherwise. :)

- I'm reluctant to put down too much practical (specifically, large
team-oriented) information into a flow such as this, because it would look
daunting to smaller design teams ("you must be THIS BIG to make an
accessible site"). One person can design something that's accessible, and
I'd hate to scare that one person off by saying s/he needs to hire an
information architect, development resources, QA, project managers, and
usability consultants, and buy a content management system, automated
testing suite, and four staging servers in order to make myquiltingpage.com
accessible. This kind of checklist would be helpful for larger
organizations, but I think that if it's done, it belongs as its own
document, rather than part of the intro; that there should be a miniaturized
version for smaller teams or individuals; and that an introduction for web
design should be written to accommodate both those groups.

-
m

----- Original Message -----
From: Robert Neff
To: Lisa Seeman ; WAI
Sent: Friday, January 26, 2001 8:20 AM
Subject: RE: process of a site development


Would add
define requirements and scope where this will discuss the players,
functionality, infrastructure, software and hardware.
Define deliverables for example, functional specification, test
requirements, quality assurance requirements, change request process
Define configuration management and file release process
either make a make a separate bullet for quality assurance or add a slash to
Testing and couple it there

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On Behalf
Of Lisa Seeman
Sent: Thursday, January 25, 2001 4:45 PM
To: WAI
Subject: process of a site development

Here is a  preliminary draft of a some type of diagram for Jason's
introduction to the guidelines.
We intend to discuss the process of a site development and were
accessibility can be incorporated into this process.
Try to imagine this as a flow diagram. Please add omissions comments.....
Cycle of Development: (flow down)
Brainstorm
Storybook
Prototype
Content
Testing
Usability testing
Promote
Evaluate
Maintain
Areas of Development: ( flow in parallel)

Server Side: Programming, scripting and installation

Client or Sever  Side: Graphical, text and semantic content (data models),
page design/layout,   markup, coding, scripting, formalization of languages,
templates,  style sheets and rendering information, coordination.

Received on Friday, 26 January 2001 14:03:28 UTC