- From: Sander Tekelenburg <st@isoc.nl>
- Date: Thu, 23 Aug 2007 04:44:52 +0200
- To: public-html@w3.org
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