Re: Why Design Principles?

On Jun 2, 2009, at 4:34 PM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Jun 2, 2009, at 3:40 PM, Sam Ruby wrote:
>>> 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.
>> Thanks for voicing your support. I think sections 1 and 2 are the  
>> most suitable as replacement front matter.
>
> My support was predicated on sections 1 through 8 being included.

Would your support change to opposition if less of the text was  
included? I'm not going to include sections 1-8 verbatim, so if you  
are picky about which parts are in or out, perhaps you should  
determine your level of support  after I post some actual draft text.

>
>>>> 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.
>> I'll think about what to do with that content. Suggestions from  
>> others along similar lines are welcome as well. It strikes me as  
>> odd that the Design Principles document would declare parts of  
>> itself to be not useful, or that it would suggest additions which  
>> are not actually present.
>
> I actually think that by setting expectations appropriately it makes  
> the design principles *more* useful.  Future projects who wish to  
> take a similar approach are likely to encounter the same or similar  
> issues. There is no magic bullet and this document should not be a  
> marketing brochure.  Reality is complicated and always incomplete.   
> As a Note this document can identify areas that merit further  
> exploration.

If it is an important goal to help other groups learn from failed  
principles, then the right way would be to remove them from the main  
body of the text and list them in a separate appendix of failed  
principles. Leaving principles that are not useful in the text, and  
then pointing out separately that they have not been useful, goes  
against the two main goals I laid out for the document, namely (a) to  
help explain the decisions that went into HTML5 and thus aid  
understanding; and (b) to help reviewers and commenters provide  
feedback that will be in sync with 90% of the group's thinking. Since  
are in support of stating those as the goals, then I hope you will  
allow me leeway to make the document better serve those goals.

Regards,
Maciej

Received on Tuesday, 2 June 2009 23:46:54 UTC