Re: [HDP] Response to Review of HTML Design Principles Questionnaire

At 21:56 +0100 UTC, on 2007-08-22, James Graham wrote:

> Sander Tekelenburg wrote:
>>> Henri gave some good examples of problems people try to solve that
>>> aren't real in IRC:

[...]

> As I understand it, Henri's point is that it is not uncommon to see
> arguments like "We should add elements <x>, <y> and <z> with attributes
> a,b and c so that search engines can use the information they provide",
> without ever asking people who have experience developing search engines
> whether <x>,<y> and <z> or a,b and c would actually help.

I have to say this still sounds like some context is missing ;) (Because I do
not recognise this sort of incomplete argument as something I've seen happen
on the list.) But assuming that people do provide such incomplete arguments,
I have to say that it seems to me that there's nothing much wrong with that.
If such an incomplete argument is posted, there are plenty of specialists on
this list who could either fill in the blanks, or explain why it would not
help search engines.

I can understand that it might be more directly effective if someone would
first contact search engine implementers to run their idea by them to verify
that it would solve a problem. But most of us would not know who exactly to
contact, or would be ignored. I wouldn't know who at search engine X to ask
for confirmation that problem Y exists and solution Z would solve it. Posing
it here, assuming that someone who does know can fill in the blanks, does
seem reasonable to me.

I do understand that a line should be drawn *somewhere*, but some amount of
naivety should in fact be welcome. Naivety can be extreely useful in finding
solutions. (Besides, this is not your average wide open Web forum where
Bezzle Bob will shout anything just to get some attention or disrupt things.)

Still, this was mostly a thought experiment (going along with your
paraphrasing of what Lachlan might have meant with what Henri might have
meant ;)) If we keep any reference to "Real Problems" in the design
principles and have that mean anything, then "real" needs to be defined. It
could indeed be clarified by pointing to examples of problems that are not
considered "real", but then those should be actual examples, not paraphrased
ones. It's just not clear from this paraphrasing exactly what is really meant
with "not real".

> Often it turns
> out that they would not because, for example, the features only function
> as intended if they are use correctly by a large proportion of the
> userbase, something that is unlikely to occur in practice (e.g. [1]).

Sure, that may be the case. But that doesn't mean the problem isn't real but
that the solution may not be good enough.

> With this in mind, we should not assume problems are real until we have
> spoken to the constituents who are supposedly having the problem to ask
> them if it is, in fact, a problem they are having, and whether the
> proposed solution will actually have any bearing on the problem.

I don't deny that that is the ideal road to take. I quite agree. But we
should becareful in allowing only one (still pretty vague) road. If TBL would
have asked you, way back, if the WWW would solve a problem for you, you'd
probably have declared him crazy. Some problems can be clear to a few and
need an implementated solution before others will 'see' the problem.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Thursday, 23 August 2007 02:49:17 UTC