QA vs. Baby Steps, Cowpaths, RealProblems

Rob - this is for you, could you say if think this is worth sending to the list?

Leif


When Laura have argued for design principles, she has cited bettering the communication/not debating the same things over and over as some of the reasons for having them. Can our proposed principles live up to that? At least some of them can't (yet). And looking at the design principles for HTML4 [1]: In retrospect, they seem just as much like as plans as design principles (for instance, one of its principles reads «TABLES»). The HTML4 authors could therefore use their principles as checkpoints: do/did we stick to the plan? I.e. they had a purpose in Quality Assurance as well. I think we could learn from that. Unclear principles probably only worsen the debate.

Comparing with our proposed principles, I would question that e.g. «Pave the Cowpaths» can serve as design principle. Can we ask (quality assure) «Have we paved the cowpaths»? But if instead we said  «Identify and specify/pave [useful] cowpaths», then it might be more constructive. That sounds much more like a plan ([and not a slogan - slogans are for the PR-staff]): We know that some design patterns have been developed since HTML4. Our task is to identify them, and eventually spec them when they satisfy our other principles. This to me sounds like something we could Quality Assure: Have we identified the significant cowpaths? Have we evaluated them?  Have we spec'ed those we found useful?

Regarding Baby Steps (BS), can that formulation help the debate? My answer is negative. Although, it depends what it means.  First, could it not be made less poetic? For instance «Go Step by step» or «Take it Little by little» seems much more understandable.  But then, how is this different from «Evolution, not revolution» (which again could be rephrased as «Identify the HTML4 principles and build on them» ...) It could be possible to assertain that the new spec builds on what we had and not bring about (too) radical change.

But Ian explained «BS» as «Not every content producer use case will be handled by HTML». First, «content producer use cases» is nothing more than «use cases». A rephrasing could be «HTML will never at any point provide solutions for every use case that some content producer might wish that HTML would handle». But do we need to take steps in order to assure that HTML will not satisfy the use cases of all content producers? This will happen automatically. In fact, with this interpretion, it sounds like something that could arbitrarily be used to oppose design which would otherwise fall within the priciples we work along.

EXAMPLE: Ian offered Baby Steps as a rephrasing of his 80% principle. From this, we can see how this formulation might be used: For a well defined use case, nameley «when needing to tell a cell's headers cell relations» he brings up that a language will never cover all use cases that the authors might wish it would, and therefore he do/might not want to have headers=. This is not a design principle. This is the «you gotta realize» principle. In another message he also said that we would never support eight dimensional tables ... It is also useful to look at the example he provides: «HTML5 only allow for simple commands, radio buttons, and check boxes. We don't support colour pickers [...]». But this example seems to fall short of its goal. We allready have radio buttons and we allready have a «headers releationships feature». To take HEADERS= out of the «headers relationship feature» would be like limiting the functionality of radio buttons «because we cannot support all things in the world». Or it would be like if we had a color picker allready, but decided to support fewer colors than we had previously «because not everything will be handled by HTML».

A possible reformulation I could think of could be «Make a realistic spec» (or .. «Only put in a realistic amount of challenges» ...). This is something which we could probably find ways to quality assure/evaluate, and which probably differs somewhat from «Evolution, not revolution». (But perhaps it touches «Solve real problems» a bit.) 

«Solve real problems»: why does it need to have this negative undertone of «Do not waste time on hypothetical problems»? The question «did we [only] solve real problems» seems far to ambiguous. A better phrasing could be «Identify and fix actual problems». (If you are are afraid that such a principle would also include HEADERS= ... then you should rather make a negative principle: «Try to find problems about which we agree are hypothetical and make sure that they don't enter the spec».)

[1]<http://www.w3.org/TR/WD-html40-970708/intro/h4desgn.html>
-- 
Leif Halvard Silli

Received on Friday, 17 August 2007 02:17:27 UTC