[Techs] Divide Techniques docs into chapters?

On the Techniques call this morning we discussed different approaches to
provide user agent/baseline information within the various Techniques
documents.
 
There was widely shared concern that providing full user agent
information for every technique would both be very difficult and time
consuming on the one hand, and make for very long techniques on the
other. 
 
Placement of the information was also considered important-- one person
pointed out, for example how frustrating it can be to study a complex
technique only to get to the end and find out it won't work for the
environment you're dealing with.
 
One suggestion was to adopt anapproach similar to the I18N group: put
important user agent information at the beginning of each technique, so
readers could decide right away whether to bother reding that technique
or not.
 
I had a thought about dividing the larger Techniques documents into
chapters corresponding to the three "baselines" that have been proposed.
I took an action item to write it up, so here it is.  There really isn't
much more to it than that.  On this model, each Technology-specific
Techniques document would have three chapters (or call them Sections if
you prefer).   Each chapter or section would cover one baseline (e.g.,
Basic, Transitional, Advanced or whatever).  All the techniques that
could be used for each of the baselines would be contained in the
chapter for that baseline.  Each chapter could begin with an Overview
section that would describe the baseline and considerations relevant to
it.  A good deal of user agent information could be addressed in this
Overview section.  
 
The possible advantages to this approach are:
- might avoid duplicating large quantities of UA information in multiple
techniques (and might therefore be easier to update as UA situation
changes);
- could give developers a clearer view of what a given baseline does or
doesn't allow for.
 
Possible disadvantages:
- Putting the UA information up front might make it esier to skip over,
and might also work against providing the granular detail that might be
needed in some cases;
- collecting all techniques relevant to baseline X in chapter X might
unintenionally limit developers' creativity; they might not become aware
of something in a different chapter that might work for them, either for
the site they're working on right then or for some future project;
- might give *us* a false sense of completeness.
 
That's it.  Hope this is useful.
John
 

"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/
<http://www.utexas.edu/research/accessibility/>