This is actually a very old debate that was first had on this list
years ago when 1st gen imode keitai were fairly newly out..
Some basics: Having one URI for all devices is technically a trivial
thing to do, whether one is handling it server side with tag soup and
only sending what the client wants, or client side with xhtml and
css. Back in the old days, some of us - me included, thought it was
"cool" and wrote sites (database/dynamic, so it was easy) that did
this. But it soon became clear it wasn't a good idea...
The question then is not - is it technically easy - but - can one
reasonably 1 to 1 map the IA of sites for browsers with sites for
handsets of radically different capabilities? If one can, one can
pump them out of the same URI - (although searching and indexing a
web of such sites would be problematic - hence the google lady's
objection on this list, passim.) If not, one can't.
On 9 Dec 2005, at 03:07, Andreas Bovens wrote:
> : "The Web works by reference. As
> an information space, it is defined by the relationship between a URI
> and what one gets on using that URI. The URI is passed around,
> written, spoken, buried in links, bookmarked, traded while Instant
> Messaging and through email.
I think this is a naive conception of the manner in which the web now
ACTUALLY works - very pre-google. Berners-Lee should know better.
People stick terms into search engine, or "go to the front page" or
whatever. URI's are often so long that they cannot reliably be
communicated by email, IM the spoken word, etc, unless they are trivial.
In addition, frequently the same information exists at multiple
URI's. URI's often contain a huge load of extra gunk that the
designers want to pass around which have no relevance at all to the
page one is actually looking at.
The URI is NOT king except for the moment I actually click it.
> People look up URIs in all sorts of
> conditions.
Very rarely, in fact, does someone type in a long URI to their
keitai.... They type a short URI of a front page and then dig.
> It is fundamentally useful to be able to quote the URI for some
> information and then look up that URI in an entirely different
> context."
What might be useful is that knowledge of the URI should give one
knowledge of a method of accessing a version of the information it
holds. This might be handled server side by a trivial rewrite (if the
IA for both sites permits it) or by the user knowing that all URI's
of ,
"/info/here" will have a keitai version at "/i/info/here". If the
IA permits it. If not, send them to something higher level ( a
section heading) and tell them to dig.
> So that's why it's important. (In an ideal world,) URIs shouldn't be
> used to communicate device specific info.
In your ideal world, access devices all have the same, or similar
capabilities. I am curious also what you are treating as
"information" as a little later you say one can get rid of links on
the page for less capable devices. Are "links in context" Grauniad
style, not "information"? You move between "information" and
"content" quite easily....
http://www.guardian.co.uk/
>
>> Let's say we have a text file 4meg in size on a URI. How can we
>> make that accessible on that URI to a handset with a maximum page
>> size of 5k? Why should we even try? If we have to cut it up into 40
>> small pages with navi, then we are going to have to use a different
>> URI - in part at least.
>
> That's indeed a bit of a problem, although you can wonder if you
> really want to offer such a huge page to ANY browser, mobile or not.
It is a huge, stonking problem - the elephant in the room.
4meg may well fit the browsers capabilities well enough. It could be
a novel I have set to autoscroll. Rule 1) - DON'T dumb down the info
you send at a URI to a desktop browser just so it will fit on keitai
handsets. That is slowing down the traffic in the fast lane so you
can ride your bicycle there.
Make a different URI with an automatic or implicit (the user knows
what to do) transformation between the two. If possible.
> Anyway, I can imagine that in this case, it's possible to redirect a
> /longpage.html#section2 (referring to the second section on the page)
> request to something like /longpage.html?section=2 (referring to only
> the second piece of the original content) when the page in question is
> accessed with a mobile. Not very elegant, but probably the closest we
> can get; some server side redirect magic should be able to do the
> trick, I think.
And BANG goes URI integrity in the strong sense of serving the "same"
content from the same URI.
>
> I talked about complicated / content heavy sites in point 3 and 4.
> Point 2 was about "10-page company websites, search engines, blogs,
> papers, etc.".
Weeell - either it is a good thing or it isn't. If a site is 10 pages
you can just send someone to the first page and tell them to look
around. Complex sites is where URI integrity MIGHT be useful. And
yet in those cases you are happy to accept that the IA dictates that
one abandon it.
> I don't know - if you change the size of your images and optimize
> navigation for cell phones, does that mean you have fundamentally
> different content, which even requires a different URI?
Fundamental? Well - "you owe me a definition of content" as my old
Prof used to say. But I think so, yes - if you change the size of the
images, only put the first para on the page, reduce the links and so
on - I think you are serving "different content". (Soto voce - Goggle
probably would.) What is your criteria/on of content identity? Do you
HAVE formal criteria of content identity? (The Bernard Lee paper you
cite would be a little less sloppy if he troubled to give us a
definition of "information").
Another problem is that you would require a semantic search engine to
index all this. One that could determine page identity based on your
attenuated conception of CONTENT.
Look at the guardian website - how could one make a keitai version
that would fit in 10k and was in any meaningful sense "the same page"
as the front page and meriting the same URI?
> I doubt that happens a lot. The desktop and mobile front pages' URI
> may be the same, but after that, all URI portability is usually lost.
I was referring to the AU/Imode/Voda URI's all probably running the
same code and it not mattering which one was hit by which handset -
it would still get a page specific to it. (On any kind of dynamic
site - this would be the EASY way to go - I have certainly built
sites like that). This is possible because the IA is the same for
those handsets.
As for URI portability being lost between the keitai and the desktop
- it isn't lost out of carelessness - it is flung - with some force
- out of the window fairly early in the design stage. And it is
abandoned for sound reasons of IA. As you agree yourself above, for
any kind of non-trivial website, it WILL HAVE TO BE. Don't get me
wrong - where one can and the IA permits, signpost the relationship
between the two.
I think I disagree with you because I have a STRONGER sense of URI
integrity than you offer, arising out of a rather stricter sense of
content identity than seems to be implicit in your postings.
Or are you merely suggesting "this might be a good thing for trivial
websites"?
If so - ah - yes - if the IA allows (and that will be based on device
capability) .... But never dumb down the desktop website just to make
it happen.
Nick
Received on Fri Dec 9 06:00:47 2005