W3C home > Mailing lists > Public > www-qa@w3.org > April 2002

Re: New version of Quality Tips for Webmaster

From: Al Gilman <asgilman@iamdigex.net>
Date: Thu, 18 Apr 2002 08:56:42 -0400
Message-Id: <Version.32.20020418080955.01e90310@pop.iamdigex.net>
To: www-qa@w3.org
At 03:10 AM 2002-04-18 , Olivier Thereaux wrote:
>On Thu, Apr 18, 2002, Karl Dubost wrote:
>> Olivier and I have worked on the page Quality Tips for Webmaster.
>> 	http://www.w3.org/2001/06tips/
>> There's now a process to help people to submit new tips and a template.
>> Participation is welcome.
>Here you go, I'm submitting this:
>"Your authoring tool produces invalid code? Send a bug report!"

** Break this out into three propositions to fit the webmaster's world.

This 'tip' is too rooted in the interests of the W3C in promoting valid content and too little rooted in the interests of the webmaster.

To appeal to the interests of the webmaster, we need to break this advice down into an argument, constructed of three parts:

a) do report trouble to your tool suppliers
- they want to know what is a problem for their customers, and may well fix the problem if you
b) document trouble thoroughly
- give enough information so they can reproduce the problem in their workspace for diagnosis and repair
c) invalid content is a problem worth reporting
- this takes a hyperlink into a tutorial explanation of the problems caused by invalid data and advantages of valid data.  One of the sub-paragraphs on this point is how assisitive technology would like to use the DOM to access web content <http://www.w3.org/TR/UAAG10> but invalid content results in unusable DOM representations and they have to use costly hacks that don't reflect what you thought the content was.


** Side note on what QA infrastructure webmasters need beyond 'tips':

The authoring tool vendor needs enough configuration information from how the webmaster is using their product to reproduce the conditions that led to invalid product from the webmaster.

This is where tool users need the most help, in helping their toolsmith suppliers.

The trick is to get the webmaster's webspace set up with enough minimal test harness in place so that when a piece of production work is found to be faulty there is a clean record of how it was produced -- the Makefile if you will for how to get the result again.

This is extra critical in the case where the user is using unusual stuff like assistive technology in their environment for using the tool.  But in fact HTML validation is a minority function just like a screen reader or voice-command modification to the UI of the customer's operating environment.  Most customers don't validate.

The webmaster needs real help in configuring their system so that it will generate usable bug reports for tools embedded in a content development pipeline or workspace.  Not just slogans encouraging people to report unorthodoxy.

The EARL work is highly valuable in setting the agenda for how to populate an effective bug report.  But in this 'tip' the webmaster should be given more help recognizing the kinds of information that the tool supplier needs, in order to *reproduce*, isolate and fix the problem.

Received on Thursday, 18 April 2002 08:56:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:29 UTC