Re: Why Design Principles?

Maciej Stachowiak wrote:
> 
> Ian and Anne both suggested that I should add most of this justification 
> to the Design Principles document itself. I will likely replace the 
> current abstract and introduction with something based on this email. I 
> suggest that those with an interest in the Design Principles should 
> voice their objections to this plan.

Would you be adverse to those with an interest in the Design Principles 
voicing support for this plan?  :-)

I believe that the text below, when both the 'content' and 'tone' are 
taken into consideration, go a long way towards satisfying the requests 
for a 'disclaimer'.  In particular, the text explicitly acknowledges 
that not all of the principles enjoy full agreement, and that not all of 
the principles have proven to be useful.  Giving people an opportunity 
to add to this list -- with you providing editorial control over the 
'tone' of the additions -- would also be a good idea, IMHO.

The only paragraph I see that requires major rework is the one that 
starts with "The Design Principles never quite advanced to a formally 
adopted Note.".  My suggestion is that the bulk of the remaining content 
and tone be retained intact.

> There are also some suggested additions and removals of principles at 
> the end.

My suggestion is that you incorporate them into the document exactly as 
you have done below: as suggestions.  Perhaps this section doesn't go 
into the abstract or introduction, but instead in an appendix or other 
back matter.

> Regards,
> Maciej

- Sam Ruby

> On Jun 1, 2009, at 8:11 PM, Maciej Stachowiak wrote:
> 
>>
>> Sam has asked me (offlist) to justify the HTML Design Principles 
>> document[1] as a set of design principles. Here is my attempt to do so 
>> as clearly as I can. This is going to be somewhat long, for which I 
>> apologize. I realize this has the potential to spawn lengthy 
>> discussion. I will respond to direct questions and points but I will 
>> try to avoid needlessly drawing out the discussion.
>>
>> If this explanation seems reasonable to most people, I'd like to 
>> update the front matter (Abstract and Introduction) to better reflect 
>> the thinking in this email.
>>
>>
>> 1. == Where did the Design Principles document come from? ==
>>
>> Many of the core ideas in the Design Principles date back to the 2004 
>> W3C Workshop on Web Applications and Compound Documents[2] and the 
>> schism that arose there. The W3C decided that the future of the Web 
>> was a new Webbased on XML + XHTML + SMIL + SVG + XForms + CDF. Some 
>> dissenters, chiefly but not exclusively browser vendors, felt that the 
>> right path forward was incremental evolution on top of HTML + CSS + JS 
>> + DOM. This was based on concerns over continuity, compatibility and 
>> so forth. Some of the dissenters formed the WHATWG to carry on its 
>> vision.
>>
>> While HTML5 (under the name "Web Apps 1.0" and "Web Forms 2.0") was 
>> under development in the WHATWG, the principles guiding its design 
>> were not explicitly called out or referred to. The main participants 
>> tended to share values, and the unofficial nature of the organization 
>> tended to attract those who were mostly like-minded.
>>
>> In 2007, the W3C decided to return to work on HTML. The HTML Working 
>> Group was formed. In the early days, there was much bickering over 
>> basics. Clearly there was a lack of common vision and shared 
>> understanding between groups. Since WHATWG brought a fairly advanced 
>> proposal to the table, some of us who'd followed WHATWG goings-on more 
>> closely felt that it would be good to explicitly write down what we 
>> thought were the guiding principles, the better to communicate in 
>> these early discussions. The first version of the document was started 
>> on the Wiki by me, but had contributions from many others.
>>
>> In early 2007, I suggested that the Design Principles be adopted by 
>> the group, and noted that some others thought they should be published 
>> as a W3C Note.[3] This resulted in two surveys, one to assess the 
>> level of agreement[5] and one on publishing as a Working Draft[4]. 
>> These surveys found support for publishing and also widespread (though 
>> not universal) support for the individual principles.
>>
>> This is part of the reason the front matter is worded as it is. There 
>> was > 90% agreement on the substance of almost every principle, so it 
>> seemed like a fairly strong statement of agreement was appropriate.
>>
>> Today, my ideas about how the Design Principles can be useful are 
>> different.
>>
>>
>> 2. == How have the Design Principles been useful, and how are they 
>> today? ==
>>
>> The Design Principles never quite advanced to a formally adopted Note. 
>> However, I think they have been useful to the group and outside 
>> commenters in several ways.
>>
>> First, they serve an explanatory purpose. Many individual design 
>> decisions in the HTML5 draft are much easier to understand in light of 
>> the principles. Note that this is not just pasting in Hixie's own 
>> thinking. At least the last time we asked the question, the vast 
>> majority of the group agreed. And I even rejected one of Hixie's own 
>> proposed principles ("Baby Steps") since it did not seem to help 
>> explain what people saw in the spec.
>>
>> Second, they offer persuasive power, even for those who are not in 
>> full agreement. If 90% of the group believes in an abstract principle 
>> of design, then if you can couch your arguments for a proposal in ways 
>> that appeal to that principle, you will have more odds of making a 
>> public reasoned argument that persuades the group. Conversely, if you 
>> want to make a proposal that flouts many of the principles, and want 
>> to justify it on the basis that the principles are wrong, then it is 
>> likely you will be swimming upstream. So even if you violently 
>> disagree with a principle, you can make productive use of it in 
>> communicating with the group.
>>
>> Third, they offer a shared vocabulary. If I we to explain the ideas of 
>> "Support Existing Content" or "Degrade Gracefully" from scratch, every 
>> time a proposal is made that is out of sync with them, it would 
>> quickly grow tiresome.
>>
>> Fourth, they are reusable. Other Working Groups or other specs may 
>> choose to adopt some or all of these principles if they have similar 
>> goals to HTML5. XMLHttpRequest is an example of a spec where reference 
>> to the principles has been useful as a guidepost.
>>
>>
>> 3. == Are the Design Principles really principles? ==
>>
>> Yes. The fact that they are neither phrased nor treated as absolute 
>> doesn't make them non-principles. Keep in mind, these principles have 
>> a fair chunk of their cultural origin on the pragmatist side of the 
>> pragmatist vs. idealist schism of 2004. Naturally they will try to 
>> reflect practical considerations and not just unattainable ideal 
>> goals. As I explained[6], and as Ian also explained[7]
>>
>>
>> 4. == Can the Design Principles be abused? ==
>>
>> Yes. Anything can be abused. But the Design Principles are not 
>> intended as a club to silence dissent. They are a tool to help 
>> dissenters couch their arguments in terms that will be more 
>> persuasive, and to make proposals that are more likely to be successful.
>>
>>
>> 5. == What about the fact that some people may disagree with some 
>> details? ==
>>
>> As I said above, I believe the Design Principles can be useful to you 
>> even if you don't agree in all respects. You will have a much easier 
>> time if you put your arguments in terms that the majority of the 
>> group, the editor, and key stakeholders such as browser vendors can 
>> relate to and believe in, then if you try to fight over first 
>> principles. You will also have a much easier time understanding the 
>> reasoning behind decisions in the spec. And they can provide a handy 
>> shorthand for the group.
>>
>>
>> 6. == Some of the most successful Design Principles ==
>>
>> I believe the following Design Principles have been the most 
>> successful. By success I mean, they have actually driven design 
>> decisions and have a lot of explanatory power as to the contents of 
>> the spec. I list them here approximately in order from most important 
>> to least important.
>>
>> - Support Existing Conten: Has influenced many decisions. Core 
>> original reason for HTML5 to exist. Explains many details of the spec. 
>> Not negotiable to browser vendors.
>> - Degrade Gracefully:  Same as above.
>> - Accessibility: A proposal that violates this is a nonstarter (though 
>> there has been much debate over what violates it).
>> - Secure by Design: A proposal that violates this is a nonstarter.
>> - Handle Errors: Has influenced many decisions. Core original reason 
>> for HTML5 to exist. Explains many details of the spec. Not negotiable 
>> to browser vendors.
>> - Well-Defined Behavior: Same as above.
>> - Separation of Concerns / Media Independence: These have been core 
>> principles since HTML4. Much of the language is designed around these 
>> assumptions.
>> - Evolution Not Revolution: Has influenced many decisions. Core 
>> original reason for HTML5 to exist. Explains many details of the spec, 
>> though at a high level. A bit too general and high level to be a 
>> strong decision tool.
>> - DOM Consistency: Much more specific than the other principles, but 
>> stands up for a useful and non-obvious idea.
>> - Priority of Constituencies: Almost risks being a truism.
>> - Don't Reinvent the Wheel: Despite some dissent about the wording, it 
>> clearly explains why we have contentEditable, canvas and IE-style 
>> drag-and-drop, instead of new clean designs for these features.
>>
>> 7. == Some of the least successful Design Principles ==
>>
>> I believe the following Design Principles are some of the least 
>> successful. By this I mean, they have generated more debate than 
>> useful understanding.
>>
>> - Pave the Cowpaths - People get caught up on the word "Cowpath". The 
>> spec has not done literally what this principle says that often. Not 
>> worth having it there to fight about.
>> - Solve Real Problems - Little explanatory power. Sometimes triggers 
>> useless debate over what "Real" means.
>> - Don't Reinvent the Wheel - Yes, I put it on both lists. I think the 
>> content has been useful, the the name and implications sometimes 
>> trigger unproductive arguments. I think it is useful to capture the 
>> idea of addressing use cases with existing not-yet-standard solutions 
>> when possible.
>>
>>
>> 8. == Design Principles that likely should be added ==
>>
>> - Work from Use Cases - This is clearly a key practice, and important 
>> to keep in mind to prepare a successful proposal.
>> - Learn from Data - Quantitative analysis has been a factor in some 
>> decisions. I think we have seen (for instance from Ben Millard's table 
>> study) that providing better data is more effective than arguing with 
>> the idea of using data.
>> - Incremental Improvement - This could be a more general statement of 
>> "Evolution and not Revolution", as well as something like the 
>> Microformats 80/20 rule. Building on the de facto existing Web 
>> platform is in a very real sense HTML5's reason for being. And it's 
>> clearly a goal to avoid defining too much of a feature directly, until 
>> there is more experience with the initial version.
>>
>>
>> [1] http://dev.w3.org/html5/html-design-principles/Overview.html
>> [2] 
>> http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0000/2004jun01.html 
>>
>> [3] http://lists.w3.org/Archives/Public/public-html/2007Apr/1103.html
>> [4] http://www.w3.org/2002/09/wbs/40318/wdhdp/
>> [5] http://www.w3.org/2002/09/wbs/40318/dprv/results
>> [6] http://lists.w3.org/Archives/Public/public-html/2009May/0653.html
>> [7] http://lists.w3.org/Archives/Public/public-html/2009Jun/0037.html
>>
>>
> 
>

Received on Tuesday, 2 June 2009 22:41:26 UTC