- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 6 Aug 2007 16:10:36 +0300
- To: Sander Tekelenburg <st@isoc.nl>
- Cc: public-html@w3.org
On Aug 6, 2007, at 14:34, Sander Tekelenburg wrote: > At 12:17 +0300 UTC, on 2007-08-06, Henri Sivonen wrote: > >> Perhaps this should be approached by finding out the actual user >> needs are through observational user testing to see which choices >> presented to users actually cause badness by, for example, slowing >> users down. > > Actual research results would definitely be interesting, yes. If this WG is to ask that UA vendors devote a non-trivial amount of engineering resources to develop presentation and configuration for features that selectively pick one alternative and suppress others and then ask authors to make an effort to write for these features, there had better be good rationale why this is Solving Real Problems. In particular, it may entirely possible that suppressing alternatives is Solving Real Problems in some cases but not Solving Real Problems in other cases. Instead of designing one unified consistent architecture for all alternatives, we should only figure out what the cases of Solving Real Problems are and address those. (For example, I suspect that accessibility for the blind and the deaf don't necessitate symmetric solutions, because the role of visual and aural content on the Web is not symmetric and the random access properties of aural and visual presentations are not symmetric.) > But when we > talk about the possibility to hide equivalents, it doesn't seem all > that > essential to me, given that it seems extremely likely that the > majority of > authors and users want to have only one equivalent (the 'main' one) be > presented by default. That's not enough. It should also be established that the badness of being offered more than one alternative is so serious that eradicating this badness is worth all the effort in spec writing, UA engineering, authoring and UA configuration. > See <alt> thread, starting at > <http://www.w3.org/mid/20070804012329.GA6301@jdc.local>. To me that thread looks like debating solution before answering: 1) What the problem is? 2) Is the problem so serious that the status quo is not good *enough*? > In the much the same way that, "coffee" and "milk" does. Most users > in most > situations do not need to know exactly what type of coffee or milk > they're > consuming. While GIF and PNG or MPEG-4 and Ogg could be seen as different flavors of coffee, PowerPoint and PDF aren't just different types of milk. >> I have rather serious doubts about the UI feasibility of such >> configuration, because it isn't just about PowerPoint vs. PDF but >> about various file format juxtapositions in various contexts >> depending on whether the user is seeking a read-only file or >> something to remix. > > Could you give examples of different contexts in which users would > likely > want different defaults? If the user wants to only view the document, it makes sense to download the PDF file. If he wants to edit the presentation, it makes sense to download PPT. I already gave the example of tradeoff with font breakage vs. animations. >> (in visual editors) > > What's a "visual editor"? An editor that presents the document (not source code) visually to the user for editing. > "WYSIWYG" contradicts the Web per definition. Well, a non-trivial number of authors uses authoring tools that contradict the Web... > I recognise the reality that some users will continue to be fooled > into thinking otherwise, but let's not > downgrade reality to cater for that. Here's another point of view: The W3C sometimes gets accused of not considering authoring tools in spec development. Not "downgrading" to take into account authoring tool reality doesn't seem like a productive way to approach this issue. Instead of leaving it to authoring tool vendors to innovate later, it would be good to make sure that features that need authoring tool support are designed with a least one plausible way of exposing them in GUI authoring tools. > What I'm saying is that from the discrepancy between visible and > invisable data, it could be deduced that the author is > abusing the 'invisible' data to lie. Based on that, the resource's > search result rank could be lowered It seems to me that with a policy like that, invisible metadata would only be a liability and authors would be better off omitting it. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 6 August 2007 13:10:57 UTC