- From: Sander Tekelenburg <st@isoc.nl>
- Date: Mon, 6 Aug 2007 13:34:13 +0200
- To: public-html@w3.org
At 12:17 +0300 UTC, on 2007-08-06, Henri Sivonen wrote: > On Aug 4, 2007, at 00:00, Sander Tekelenburg wrote: [... optionally not present audio equivalents to deaf users] > 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. 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. If there is agreement on that need, we don't need to know if it also applies to certain minorities. [...] >> Note that I'm think of a general indicator here. > > On the page-level as in the feed case or local to the rendering of > the part of content that has a hidden (except for the indicator) > alternative? I suspect it would have to be "local", as you call it. A toolbar indicating that there are equivalents available for some object in the <body> would not be useful, as it would probably be impossible to be clear about which item in the <body> it refers to. >> Not ideal, but hopefully good enough for >> this discussion's attempt at understanding each other, might be a >> cursor >> change on hover, and a listing and access to the equivalents through a >> contextual menu. [But this is jumping to UA implementations again, >> before >> establishing agreement on actual needs.] > > FWIW, I think a cursor change on hover is a rather awful indicator in > terms of discoverability. It requires the user to scan the page with > a cursor to find out if alternatives exist. Agreed. That's why I said "not ideal". Note however that it might very well be ideal for some users. Those who generally need or just want to have a clear indicator would need something better. But those who generally prefer to simply consume the 'main' equivalent would probably not want a more 'agressive' indicator at all. [...] >> By default, in the sense of "fallback", whichever is defined as >> preferred. A >> sensible factory default would probably be PDF, but the user should be >> allowed to change that default to PowerPoint. > > Wouldn't that involve asking the user to order a list of known file > formats to an order of preference? Seems like a task one wouldn't > want to put forward to J. Random User. No, "asking" == bothering the user. I said "be allowed". Being allowed to change such settings is nothing new. Most UAs (or host OS) allow users to configure how a resource with a certain MIME type should be treated. They'r not asked to do so, and thus not bothered with it. UAs ship with reasonable defaults that most users don't need to change. But they are allowed to make changes, and those who need to do. (Even that can be relatively user-friendly in certain cases. A plug-in installer might be allowed to register itself as teh default for a certain MIME type, for example.) So it seems to me that [1] a default and [2] allowing users to change that is not without precendence for the sort of thing we're talking about. >>> The user but not the browser can probably guess that the PowerPoint >>> file is the master file and the PDF was generated from it. >> >> Is that really relevant? > > For the purpose of guessing if something has been "lost in > translation", yes. Well, the proposed <alt> would seem to allow for it, I guess. >>> But what if the page said this >>> <p>Presentation Foo Bar is available as a <a >>> href="foobar.ppt">PowerPoint file</a> and as a <a >>> href="foobar.pdf">PDF without animations</a>.</p> [...] See <alt> thread, starting at <http://www.w3.org/mid/20070804012329.GA6301@jdc.local>. [...] > Quite a few users know what PDF and PowerPoint are. For those who > don't, how would "animated presentation" and "pretty text with > images" allow them to make an informed choice? 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. Having to choose from types of beans without knowing they're coffee would provide problems for most users. Only when for example they know to prefer a particlar type, or they know to be allergic for one, do they need to know. Translated to the Web: when the browsing environment can handle PDF, there is no need for Joe Average to know what PDF is. Knowing it would be helpful, but having to know it would be limiting. [...] > 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? [... 'visibility of metadata' to authors] > Making invisible metadata visible would involve a novel visualization The idea of <alt> is visible equivalents made invisble. See <alt> thread, starting at <http://www.w3.org/mid/20070804012329.GA6301@jdc.local>. > (in visual editors) What's a "visual editor"? > and would necessarily be against WYSIWYG if the data being > visualized is invisible in a usual visual browser. "WYSIWYG" contradicts the Web per definition. 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. In other words, let's not make it needlessly difficult to produce high quality web content just because that is impossible to do with a 'WYSIWYG editor'. [... parties capable of indexiing non-markup] >> If that's the case, then I don't see why it >> couldn't compare its indexed prose with the content of explicit >> 'invisible' metadata. > > Would there be any case where if the comparison resulted in a > "invisible metadata disagrees" result, the search engine would want > to use invisible metadata nonetheless? Use, yes. Nonetheless, no. 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 -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Monday, 6 August 2007 11:43:59 UTC