reframe contentious 'principles'

ChrisW: ... I think we'll have to make a decision on the disputed 
principles soon. There are arguments both ways, but it's important to 
say something.

May I suggest another approach?

Don't force the group to pick a "right answer" to the wrong question.
See if you can't re-frame the issue so as to expose latent agreement.

As I read the "principles that are divisive" it seemed to me that
these were couched in unnecessarily divisive terms. This is the kind
of place where searching for an assertion that gets more ready
agreement will show us a better way to look at the design space.

Let's take the 'visible metadata' issue.

First of all, there is a mistake in talking about only 'metadata.' At
the model level, there are no metadata. Just data, and relationships
among the data. Different processes touch different views of the
aggregate of data. Display processes, machine processes. The web runs
on very lightly-modeled content because of the pervasive involvement
of human operators. The principle that belongs in your set of values
touches _all_ the concepts floating through the instance docs, both
markup and metadata.

The answer to this issue flows from some of your other principles:

- solve real problems
- simple

- and an expansion of your 'security' item.  This should be relaxed
to "support information integrity."

And one of Tim's: lowest level language.

The corollary of 'lowest level language' here is "frame the model in
terms of concepts your users already understand, to the greatest
extent reasonably achievable."

 From "support information integrity" we get the following
line of argument:

Historically, the Web worked because of the finely-marbled
alternation between human and machine action. In the beginning it was
just evolving navigation, and the back button meant that groping and
test-and-fix added up to success. Now the things one can do on the
web are broader and we need to look afresh at 'undo' and what's safe.
But in any case, there is cause to prefer field definitions that get
used more, for both economy and information integrity (does the data
reflect reality?). This is not limited to metadata. And within that
"used more" to further prefer field definitions that get validated by
users understanding and acting on them. That comes from the
conjunction of "information integrity" and "lowest level language."
So, prefer data definitions with more human use over data definitions
with less human use. In markup and in metadata.

Please understand that for accessibility we will be after you to run
a sliding scale on this value.  That is to say if the "real problem" is that
some people get no access to the functionality, then we may want you
to include things in the design that close this gap, even if they are not
widely used (and specifically they don't have to be widely used now).
I think Alastair and Henri framed the "feasible range for agreement" 
pretty well:

One thing I'd point out though, is that accessibility use-cases
shouldn't necessarily be dropped due to (some of them) being edge cases.

If you come and say that you want a given edge-case solution in the
spec just because you know you think you need it, you are likely to
be unsuccessful. On the other hand, if you present a use case,
present a clean common case solution and *then* as an extra present
coverage for edge cases *and* explain why the edge case coverage is
not just chasing for diminishing returns, you are much more likely to
be successful even if the edge case stuff is the same in both cases.

If we make the principle "prefer feature designs that get more use
over feature designs that get less use" we get both support for
universal design over "special things for special people" *and* the
justification for why one should prefer metadata that passes through
the human consciousness over metadata that doesn't, where either can
do the job.


Received on Thursday, 19 July 2007 20:23:09 UTC