Re: Why Design Principles?

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.

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

Regards,
Maciej


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 21:56:02 UTC