Re: Lists in normative section

Gregg Vanderheiden writes:
 > Couple of problems in the way we were thinking of doing 4.1
 > 
 >  
 > 
 > Problem 1:  If we create a list of things to review against and put it into
 > normative section, then we cannot add to the list.   So are we saying that
 > those things are the ONLY things that make content simpler to understand-and
 > that they do not need to consider anything else?     We can't sat  etc. on
 > the list to indicate that there may be more because then the success
 > criteria stops being testable (since we are requiring that they review
 > against a list that we don't provide them all of.
Proposed solution: require that the review be conducted against the
 > items on the list. That is, if a developer has reviewed the content
 > taking into account the listed items, this should be sufficient for
 > purposes of the guidelines. The developer should not thereby be
 > precluded from taking into account other considerations, but
 > what we would be saying, in effect, is that if the listed matters
 > have been duly considered then a review has been conducted
 > satisfactorily for purposes of the guidelines. The working group
 > should strive to ensure that the list includes all of the items
 > considered to be of greatest importance.

In practice I think the > list compiled for checkpoint 4.1 is rather
good, thanks to the > excellent work undertaken by Lisa, Avi and
others.
 > 
 >  
 > 
 >  
 > 
 > Problem 2:  In trying to create a list of individual items, I kept running
 > into the problem that they looked like success criteria.  Even if we start
 > off with a sentence which simply says, "You must think about the following
 > things," if the list that follows reads like:
 > 
 >  
 > 
 > *        One idea per sentence
 > 
 > *        Words are familiar to intended audience
 > 
 > *        Etc.
 > 
 >  
 > 
 > The items end up looking not like suggestions, but success criteria.  I
 > tried rewording them as questions, but they, again, ended up looking like
 > success criteria.
 > 
 >  
 > 
 > *        Is there only one idea per paragraph?
 > 
 > *        Are the words and structures familiar to the intended audience?
 > 
 > *        Etc.
 > 
 >  
 > 
 > If we release a set of guidelines in this form with a bulleted list of items
 > in the "success criteria" area, I'm afraid it will be widely misunderstood
 > and misconstrued to be a list of criteria.  I would be willing to bet
 > anybody a very large amount of money that we will immediately see test tools
 > which try to (if they possibly could) test compliance by testing each of
 > these questions rather than testing the "did you do a review".
I agree this could happen, with a high degree of probability.
 > 
 >  
 > 
 > The only thing I can think we might do about this is to go back to the
 > original plan which simply had the requirement for review up above and
 > sample lists of things to review below.
I don't like this alternative because the items to be considered can
 > so easily be omitted from checklists, summaries and other documents
 > that enumerate the success criteria, and can so readily be ignored
 > by the developers. Did I conduct a review? Yes (but I never really
 > looked at the list of items, all I noticed was the requirement that
 > a review of some sort be conducted).

 > 
 >  
 > 
 > Or maybe make them very clearly general things to be looked at and not
 > specific things to be achieved.  

Possibly. Here are a few options. They both run along the line of
taking the first of the potential misinterpretations mentioned by
Gregg (above) as the lesser of the two evils.

1. Rephrase the items to be considered so they read differently from
   our success criteria:
There should be only one idea per paragraph, where possible.

Words should be used with which the intended audience is expected to
be familiar.
[...]
(others can probably write the above better than I just did).

2. Use a different style (font, layout etc.) for the "items to be
   considered", in order to distinguish them from the success criteria
   (this could also be reflected in the markup).

3. Make an explicit statement somewhere in the guidelines that warns
   against this particular misinterpretation by reminding readers that
   the requirement is that a review be conducted and it is
   acknowledged that the items to be taken into account aren't
   inthemselves testable.

My current thinking, as indicated, is that the misconstrual of these
items as success criteria is less of a practical problem than the risk
of their being overlooked, which is the likely result of moving them
into a separate section below the success criteria. Essentially we
have to decide which potential misinterpretation or misapplication is
worse, and do our best to militate against it. I can say with high
confidence that, however they may be written, the guidelines will be
misinterpreted and misapplied by people who don't understand them or
who implement them carelessly.

Received on Friday, 17 January 2003 02:45:25 UTC