Why publish Design Principles?

A lot of the discussion of the "Design Principles" seem
to be rehashing past history of who did or didn't
use which Design Principle.

I don't think that's too useful. As a "historical artifact",
we can publish a document with sufficient disclaimer
that we can at least let some people know what some 
people tried to use as principles some time, and leave
it at that. Refining it further NOW doesn't help produce
a better "historical artifact": after all, documenting
the past can't be accomplished by rewriting history.

If, on the other hand, there's a desire to publish
the Design Principles because doing so is USEFUL,
we should ask:

# How do we imagine the Design Principles being used?

One very common reason why standards groups publish
"Design Principles" documents and "requirements" 
documents and "goals" documents, is that such documents
are provided to the community as benchmarks against
which we expect review of the target document to
be judged.

So, we could work toward publishing a "Design Principles"
document against which we expect community review:
do these principles apply, NOW, to the document that
we are asking the community to review?

Can we document our goals -- even if they are 
incomplete, inconsistent, not entirely agreed upon --
in a way that will be useful to reviewers in the
review process?

If that's the goal, then we should stop talking about
the "Design Principles" in the past tense -- what were
they, whether they were applied during arguments, etc. --
and instead focus on the present and future.

Going forward, starting today, what Design Principles
do we want from the HTML 5 specification? And does
the specification we have match those design goals?

I think, for such a document to be useful, it would help
to combine it with much of the material now contained
in Section 1 of the HTML 5 specification -- which lists
many but not all of the goals that the group or the
editor or authors wish.

I will add that I don't think agreement on design goals
is completely NECESSARY. It is always the case that
different groups in a standards process may disagree
about goals, or at least about priorities, and the
standards process is one of discovering compromises
that allow win-win: that all sides accomplish enough
of their goals to be satisfied, even if goals don't
agree.

Finding a common technical solution to disparate goals
is the heart of standards work.

So let's not hold up publishing a useful document because
there is not 100% agreement on Design Principles.
If there are or were differences, document them, note
the differences, ask the reviewer/reader to determine
if the result was reasonable, accomplished multiple
disparate goals in a fair manner, and move on.

Larry
--
http://larry.masinter.net

Received on Monday, 25 May 2009 20:35:57 UTC