Re: Cool interfaces hide URIs

Al,

	I agree with your points, but I think you missed mine. I was
trying to say that, for many years now, it does not matter much how
URIs look. We should not spend time discussing or documenting their
looks. That does not mean that access to "raw" URIs should disappear
from user agent interfaces. That access is essential and should stay
(for the reasons you mentioned). That access does not imply we should
care how URIs look though.

Alex.


On Tue, 28 Jan 2003, Al Gilman wrote:

>
> At 04:40 PM 2003-01-28, you wrote:
>
> >On Tue, 28 Jan 2003, Karl Dubost wrote:
> >
> > > QA Activity has published two W3C Notes: CHIPs and CUAP
> >
> >There are several CHIPs checkpoints that talk about visual formatting
> >of URIs. It surprises me that QA WG (or anybody) still cares how URIs
> >look. The whole "use meaningless but easy to remember URIs" rhetoric
> >seems to lack real-world foundation.
> >
> >While cool URIs may not change, cool interfaces do not force users to
> >type URIs and, hence, it is not that important how those URIs "look".
> >Cool interfaces use other means like page titles and links to present
> >resource pointers to users, and computers do not care how URIs look as
> >long as the URI "works". Document <title>s are for humans, URIs are
> >for computers.
> >
> >With the exception of domain names (which are not even URIs), how many
> >users still have to type URIs by hand? Bookmarks and links of various
> >kinds make that awkward and unnecessary. Moreover, isn't it a
> >violation of Web Accessibility guidelines to talk about specific
> >visual appearance of URIs without talking about how URIs should sound,
> >for example?
> >
> >Without much hope, I would suggest that arbitrary requirements related
> >to URIs "look" are removed.
>
> It is true that for screen reader friendliness, one should not use the URI
> as link text but rather put a natural language title for the cited
> reference in the link text and expose the URI-reference in visible text
> somewhere unlinked but nearby.
>
> But don't hide the URI, either.  This is a genuine conflict between user
> groups.  Lots of users understand what is going on better if the link is
> from the URI-reference text.
>
> What is easy should be easy (activate a hyperlink) but what is hard should
> be possible (cut, edit and paste or even type in a URI-reference).
>
> Direct navigation, that is to say going directly to a web resource by
> entering a URI-reference through the user interface of the user agent, is a
> civil right of the Web.  It's not the democratic space that Tim wanted it to
> be without this cycle.  Yes, it is mostly done with cut and paste and not
> typing.  Only fossils like me type the URIs for the email archives.  But
> editing the URIs from where you are to say where you want to go (to parallel
> structures on the site) is very real in terms of resources such as the W3C
> email archives.  It depends on the structure of the collection, whether
> editing URIs is something that will be used often or rarely.
>
> See also:
>
> Use URL path hierarchy mnemonically:
>
>   http://lists.w3.org/Archives/Public/uri/2002Nov/0013.html
>
> People do use the list-of-list-archive pages:
>
>   http://lists.w3.org/Archives/Public/wai-xtech/2002Mar/thread.html#66
>
> Al
>
> PS:  If the URI is available in cut and pasteable text, we don't need to
> put in guidelines about how they should sound.  The sound like gibberish,
> it is clear to the screen reader that it should spell and not say them,
> and the key thing is being able to print or email them for a friend to
> start at the same place as where you were.
>
> Think about reporting a problem which arose using the web.  The first
> question is "where were you, and what were you trying to do."  If one can't
> cut and past the URI the webMaster is out of luck trying to reproduce the
> problem.
>
> This is a genuine problem for people with disabilities: that the reporting
> of problems is badly supported with over-restrictive web forms and not
> enough automation in terms of capturing and emailing the conditions under
> which the problem occurred.
>
> >Alex.
> >
> >--
> >                             | HTTP performance - Web Polygraph benchmark
> >www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
> >                             | all of the above - PolyBox appliance
>
>

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Wednesday, 29 January 2003 00:07:48 UTC