This document gathers together brainstormed ideas about how to put together checklists to guide implementors.
Note that this is a WORKING DOCUMENT. No implementation intent is implied. No guarrantees are made about the sensibleness, coherence or good structure of ideas. The document is liable to constant change. I have written this quickly as a stream of conciousness, so please forgive any lack of clarity.
I start from the assumption that most people developing content (or other things for that matter) are typically trying to ensure they have met WAI or i18n requirements while they are already under pressure to deliver, and not only that but often see WAI or i18n stuff as an additional burden they are being told to take on. I also assume that few people remember everything they have to do after reading a book on a topic like WAI or i18n.
This leads developers to commonly say "I'm in the middle of implementing an X right now, just tell me what I should do at this point". At that moment they don't care too much about the theory, and they don't want to hear "go read this book", or even "go search through this set of pages". In fact the faster they can get to the information appropriate to the specific task they are performing, the better.
An ideal way of achieving this would be to make their editing tool or development tool check they always do everything correctly, and if desired propose what they should do at any point. It may, of course, not always be possible to work with such a system, so a backup should be provided in the form of documentation. My key concern is that that documentation should actively anticipate and to the extent possible, help the user find information at the point of need.
My approach would be to produce a document that could be read as a book and contained examples, explanations, etc. much like the current WAI stuff does. That 'book', however, should be produced from an XML master document (using XSLT). Applying another XSLT stylesheet to the same XML file produces an alternative method of getting at the data that is checklist based and dynamic. This checklist, of course, uses the same text for the wording of the guidelines and checkpoints, to reduce maintenance.
The checklist should start from the viewpoint of "What do you want to do right now?" The headings of the WAI HTML techniques document already do a pretty good job of presenting the information in this way. I'm inclined to use expanding lists to make the information seem less intimidating and to help the user see the whole range of options as much as possible. (This is particularly useful when there is a category that the user might not have thought of. For example, a designer might not think that 'text fragmentation & reuse' is a task they should look up, but they will realise they need to think about it if it is in a short list of items relating to 'creating source text' or 'designing screen layout'.) When the user gets down to the specific task they are involved with, they could be presented with a bare-bones, succinct-as-possible, checklist saying
These largely correspond to checkpoints in WAI.
For the expert user this is often enough. He or she can use the checklist rapidly at the point of need.
Others may want more specific advice. The page could then open up more detail, but still in succinct checklist form, that corresponds to the specific pointers in the techniques documents (these are part of the running text in the WAI techniques documents, but are broken out in green text my example page*). Anyone wanting more help or convincing wrt a specific point at this stage could then link to the specific part of 'the book' to get examples, explanations, etc. (So the book needs to organised at a task level in the same way as the checklist).
The checklists should have cross-references too, but I would typically repeat checkpoints and techniques under different categories so that the user didn't have to keep linking to different locations to find out what they needed. In some circumstances this may mean repeating information in 'the book', in others, just linking to more than one section in 'the book'.
The 'guidelines expansion route' is only one of several that the user could follow once they had defined the specific task they were trying to accomplish. Another would be to go to a list of (external) resources that give information about the specific topic in question - requirements, background reading, other people's techniques documents, etc.
Additionally, the checklist could provide information about who needs to be involved in accomplishing a specific checkpoint, what languages or types of disabled user are affected by this, which browsers support the features mentioned, etc. The more of this information that can be included directly on the checklist page, perhaps in columns to the right of each checkpoint, the better in my mind.
The wonderful thing about XSLT is that you can produce many different versions of the same material adapted to the needs of different users - scripted, served differently, WAI optimised, translated, etc.
In the past I used a lot of dynamic html scripting on top of the XSL generated docs to provide very quick, server independent filtering of information. This may limit interoperability, but some simple things may be possible, based on the DOM standards.
Another thing to consider, which I did in the past, is filtering all information on the basis of the user's profile. For example, a graphic designer may say "Show me only the things that relate to graphic design". This would mean tailoring all the information, even at the book level, to just that which is relevant to that type of user. This approach again reduces the time needed to work out what to do, and makes the material appear more relevant - and therefore more usable and interesting - to the user, increasing not only their speed in use, but their motivation to use it. The user's preferences should be remembered between sessions.
Note that these are ideas for implementation checklists. Review checklists would probably need to start from a different point (the Guidelines) and work down to a level that enabled you to say whether you conformed.
Also, implementation checklists for people developing new technologies would also need to start with the Guidelines, but wouldn't go down to the same level as review checklists.
These different checklists could still be generated from the same master XML document. They are just different views on the data.
A key objective would be to point a person looking for guidelines/checklists to the right place to start with, ie. "If you are interested in reviewing an implementation, go here; if you are implementing HTML, go there; etc."
* There is a very rough and ready implementor's cheat sheet for accessibility techniques that gives fast access to WAI's recommendations for those implementing HTML (it is still not quite finished, and still very badly styled, but works for most common things). I'm not recommending this as an appropriate approach for GEO, but it illustrates an interesting approach - organisation of information by task, and 3 levels of info depending on how well you know the material. General assumption being that less is better, but you can get more if needed.
Richard Ishida (ishida@w3.org)
$Id: impl-guideline-ideas.html,v 1.2 2002/11/14 19:11:45 rishida Exp $