Re: Organization of techniques document

Jutta Treviranus wrote:
> 
> Ian,
> 
> Sub-checkpoints is possibly a misnomer, in conversations I've had with
> potential implementors of the checkpoints, they frequently ask "what is
> meant by this for my application, can you be more specific?" The goal for
> the guidelines was that they have good longevity, that we don't need to
> change or update them every six months. Therefore they needed to be
> somewhat independent of present technologies. The techniques are a
> technical note and are therefore much easier to update. So the criteria I
> described would explain " what does this mean right now in a practical
> sense with the technologies under development." It would also be more
> explicit for people who don't have the context or the background
> information needed to fully understand the intent of the checkpoint. The
> criteria would not add new requirements or even new information, they would
> simply be more explicit.

If you want to say "Do this", it should be a checkpoint. If you
want to say "Do this today", it should be a technique.

 _ Ian

> 
> Jutta
> 
> At 3:05 PM -0500 3/8/00, Ian Jacobs wrote:
> >Jutta Treviranus wrote:
> >>
> >> While acknowledging that the primary task is to get some content for the
> >> document, we have been giving some thought to the structure of the
> >> Techniques document.
> >>
> >> Here are some thoughts. I propose that each checkpoint in the document have
> >> the following sections:
> >>
> >> 1. Criteria for Implementation
> >> The checkpoints in ATAG are still fairly high level, in talking to
> >> developers, several of them mentioned that they needed further specifics
> >> about how to comply. These criteria would be the verifiable criteria that
> >> apply to all tools. They would differ from the suggested implementations in
> >> that they are not suggestions, they are all actual "sub-checkpoints."
> >>
> >> Examples of these would be:
> >> The same fonts, text sizes, colors, symbols, etc. that characterize other
> >> program features should also characterize those dealing with accessibility.
> >
> >I don't like the idea of sub-checkpoints. If you know what you
> >want specifically for conformance, create a checkpoint for it. If you
> >don't really know what you want, leave the checkpoint vague and clarify
> >in the techniques document. The ATAG 1.0 has few checkpoints and they
> >are high level. If more concrete checkpoints are required, add them as
> >first-class checkpoints.
> >
> >If a checkpoint is so high level as to not be useful, make it a
> >Guideline.
> >
> >If possible, I would like all the guidelines to use the same model:
> >guidelines/checkpoints/techniques. I don't know what a level
> >of subcheckpoints adds. It may confuse readers further.
> >
> >> 2. Suggested Implementations
> >> These would be examples we imagine of really good implementations. Ideally
> >> we should illustrate in this section how the checkpoint would be
> >> implemented in various classes of tools. For example how would you
> >> implement this checkpoint in a conversion tool, a courseware tool, an HTML
> >> editor or a WYSIWYG tool. These are not actual implementations, so there
> >> would not be any compromises or gaps in the implementations. If at all
> >> possible we should try to include illustrations.
> >>
> >> 3. Sample Implementations
> >> Here we would discuss and illustrate real world implementations of the
> >> checkpoint. Within this section we should critique what is done well and
> >> discuss what could be done better.
> >>
> >> 4. Relevant Documents
> >> Here we would link in other relevant documents. However, we may link to
> >> other documents in the other sections if those documents provide the
> >> content for the sections e.g., the ERT document for Suggested
> >> Implementations of 4.1 and 4.2.
> >>
> >> Since this is going to be a fairly hefty document, I also propose that we
> >> allow different views of the document. So a graphic editor developer could
> >> get the graphic editor view of the document which would leave out the
> >> examples and checkpoints that don't apply.
> >
> >Up to now, I was under the impression that people wanted everything
> >in one document (e.g., sample information is available in the techniques
> >document and in separate documents). You might split along the following
> >lines:
> >
> > - General techniques, list of resources, links to other techniques
> >documents
> >   (this would be the "main" techniques document).
> > - Content techniques
> > - User interface techniques
> > - Sample implementations
> >
> > - Ian
> >
> >
> >--
> >Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
> >Cell:                        +1 917 450-8783

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Cell:                        +1 917 450-8783

Received on Wednesday, 8 March 2000 17:27:40 UTC