W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: Why publish Design Principles?

From: Robert Sayre <rsayre@mozilla.com>
Date: Mon, 25 May 2009 15:12:21 -0700
Message-ID: <rxwubpbbt1ana9hq4j31ac4q.1243289542558@email.android.com>
To: Larry Masinter <masinter@adobe.com>,HTML WG <public-html@w3.org>
I don't think revisiting these will be productive. I favor moving forward and publishing over the few objectors. 

Larry Masinter <masinter@adobe.com> wrote:

>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
>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.

Received on Monday, 25 May 2009 22:13:12 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:45 UTC