Browser bars, etc. (was: RE: I-D Action: draft-klensin-iri-sri-00.txt)

--On Monday, July 09, 2012 20:03 +0000 Dave Thaler
<dthaler@microsoft.com> wrote:

> Also on the real substance of the SRI vs IRI discussion...

Indeed, this is part of the key question.   I think the
underlying question is even more complicated than the way you
present it, so I'm going to pull your message apart a bit.  

> Browsers today have an address bar. 

And one of the things the UI community has known for many years
is that users don't make useful distinctions about what they see
or type there.  In particular, only a very small fraction of the
user community understands the differences among domain names
(aka "web addresses"), URIs of various sorts, and search terms.
Some modern browsers have essentially given up on those
distinctions entirely, mixing up partial URLs with
autocompletion and searching outside the browser (whether that
search is the history often used in autocompletion, some sort of
web search, or a "friend" search of some flavor.

>   That address bar today
> can often contain IRIs, which are more readable than URIs.

I'll agree with "more readable" but note that there seems to be
an industry trend to be toward more and more complex URIs which
are usefully accessible only from favorites/bookmarks, imported
references, and search mechanisms of some flavor.  Discussions
in the IETF may lead to reinforcing that trend (e.g., proposals
to incorporate hashes instead of user names and of signed URIs).
If one assumes a URL that goes on for several lines, with most
of the relevant tail components present, possibly embedding
another URL, multiple query components, and so on, then
readability is an unreasonable expectation whether the abstract
text is ASCII or not.  Even if it is not, the marginal
percentage readability improvement from IRIs is likely to be
miniscule.

Even the structure of the address bar doesn't help much.  If the
number of characters in an IRI or URI considerably exceeds the
width of the address bar, readability and usability suffer: I
have yet to see a browser that handles over-long URI strings in
the address bar (such as by scrolling) really well.   IRIs might
help by virtue of being shorter, but the window in which that is
of large benefit to readability is not huge.

So, part of my response (albeit a small one) to concerns about
the address bar is that, unless something like ICANN's new TLD
program changes the trends toward long and complex URLs/URIs,
the whole concept of the address bar as a display of the current
"location" is going to need rethinking in favor of things that
make better sense to users given limited space and attention.
Relative to that requirement, I think URIs, IRIs, and SRIs are
going to fail more or less together.

> The SRI isn't amenable to that UI paradigm which was based on
> the URI-is-an-IRI principle.

If one preserves the [every] URI-is-a-[valid-]IRI principle, a
number of convenient things happen.  Some inconvenient things
happen too, a few of which SM and I tried to identify in the
document.  But one of the reasons this I-D or something very
like it wasn't written a half-dozen years ago was that there
seemed to be general agreement that URI-is-an-IRI made sense.
In that context, IRIs were no worse for localization than IDNs:
perhaps, if one had a good "above DNS" layer that would do the
kinds of language-based matching that end users had been
encouraged to expect, IDNs would be almost useless because that
layer could translate directly to strings with which the user
would not need to deal, but, especially with the dual
relationship between A-labels and U-labels introduced in
IDNA2008, they would not be harmful.  

But, in that regard, IRIs ran into something of the same problem
that IDNA2003 ran into: if one could not reverse the ISI-> URI
transformation and reliably get back the same IRI, then there
are uncomfortable side effects (including on the user's ability
to interpret the address bar regardless of how readable it is).
There were other issues as well, and the WG (or at least an
active fraction of it) concluded that IRIs should be independent
protocol elements, similar to URIs but independent of them and
perhaps most suitable for new protocols.  

Depending on how far that goes --and I really don't have a clear
picture of how far it is going-- URI-is-an-IRI works for RFC
3897 IRIs but may not apply for draft-ietf-iri-3897bis IRIs.  


>  In this proposal to get rid of
> that principle, it would be worth discussing UI paradigm
> principles, since the XML representation  can't be easily
> rendered in such a box.

Yes, but note that draft-ietf-iri-3897bis proposes to get rid of
that principle too.  Not as dramatically of course -- under
draft-ietf-iri-3897bis, many URIs will still be IRIs -- but,
unless the WG reverses itself, the discussion is not about
whether to get rid of the principle or not but about what to
replace the discarded principle with.

>   That means without IRIs, it seems
> one would either need a radically different paradigm, or one
> would need to always display the less-readable URI form.   I
> don't think always rendering the URI form would be any better
> for usability, so to me this proposal is tightly tied to the
> discussion of alternate rendering paradigms.

Agreed.  But, again, that is "without IRIs that preserve the
URIs-are-always-IRIs principle" and "with many longer and more
URIs even without i18n", so I think that we are likely to need a
new rendering paradigm soon anyway.  The bad news is that it is
not clear how the IETF talks about rendering paradigms for
"address bars" given that I don't think we have anything formal
that even mentions address bars or their ilk.

   john

Received on Tuesday, 10 July 2012 07:17:35 UTC