Re: Why Design Principles?

Maciej Stachowiak wrote:
> 
> 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.

Status of the Design Principles in this document is not binary.  They 
aren't all 100% successful or 100% abject failure.  The point of view 
that states that they must be in exactly one category or the other is 
counter productive.

I saw the original email on this subject as representing significant 
progress.  But, yes, you have the leeway to ignore the feedback of 
myself and others that felt that incorporating the essence of that email 
into the document itself would make that document more useful.

And I actually thought that your email did a reasonable job of conveying 
the above notion in a positive and constructive manner.

> Regards,
> Maciej

- Sam Ruby

Received on Wednesday, 3 June 2009 00:46:53 UTC