- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 27 Mar 2007 01:58:34 -0500
- To: public-html@w3.org
I think I chose poorly when I picked the subject "brainstorming: test cases, issues, goals, etc." What I really want is test cases; i.e. concrete documents sent as attachments. One person sent a concrete script/parsing case that I was willing to turn into an attachment... http://lists.w3.org/Archives/Public/public-html/2007JanMar/0172.html http://lists.w3.org/Archives/Public/public-html/2007JanMar/att-0172/_t.html and the abbr thread did yield a handful of test materials http://lists.w3.org/Archives/Public/public-html/2007JanMar/0325.html http://lists.w3.org/Archives/Public/public-html/2007JanMar/att-0325/abbr_en-us_fr_title.html (and 7 others) But a lot of people picked up on the word "brainstorming" and sent ideas without giving a concrete example document. On Sun, 2007-03-25 at 19:01 -0400, Mike Schinkel wrote: > However, my understanding was that the W3C wanted to open this up to people > using HTML in the real world in order to get better perspective on issues. > The approach of requiring a well defined use-case prior to discussion very > much discourages brainstorming. Yes, we want to open this up to people using HTML in the real world, but at the same time, we're not in the early phases of design here; we're in the standardization phase. What we want is for people to condense their experience so that we can digest it reasonably efficiently. And there are practical limitations to the size of a group that can do a pure brainstorming exercise. I think story telling and test cases are both important and worthwhile. Story telling is what I like to call discussion of use cases and requirements... [[ Design discussions can get disconnected when some of the parties aren't interested in this part of the design because they don't see the purpose of it. Therefore, tell each other stories and write them down in a RequirementsDocument. 1. tell stories that engage your audience/community 2. derive requirements 3. evaluate design options against requirements 4. ... ]] -- http://esw.w3.org/topic/RequirementsDocument but story telling is also presenting things at conferences and even answering journalist's questions. I don't think I need to elaborate on the value of testing these days. I think a healthy design discussion zooms out from the details of one example to story telling, use cases, and design principles, and then zooms back in after sketching a design, and so on. p.s. I have seen some questions about the "+1" convention. It comes from the apache project. Note in particular: in some cases a favourable vote carries the implied message 'I approve *and* I'm willing to help.' -- http://www.apache.org/foundation/voting.html as opposed to +0 for something like "fine by me as long as somebody else does the work." I'd like to stick to that convention here. It's not at all clear that a plain +1 message is worth distributing to hundreds of inboxes; so try to say +1 and here's an example ... or +1 and here's a firefox/webkit patch ... or +1 and here's a bit of background research to support it ... or +1 and here's a tutorial weblog article I wrote ... -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Tuesday, 27 March 2007 06:58:47 UTC