(keitai-l) Re: Mobile Web Development in Japan: A Tag Soup Tale

From: Andreas Bovens <abovens_at_gmail.com>
Date: 12/08/05
Message-ID: <8ba9930512081007r38dd651ci3abdfd28bc708bf0@mail.gmail.com>
> > 1. I believe it's important that URIs can be accessed with any
> > browsing device. No /k, /i or even .mobi variants, just the same URI
> > for all user agents - that's true device independence. So far, I
> > haven't seen very much discussion about this point.
> Why? Why is this so important? You have not argued for it, as far as
> I recollect... Saying a URI should be device independent is fine if
> all devices have unlimited capabilities. Otherwise it is like arguing
> that a motorway should be device independent - then trying to ride a
> bicycle in the fast lane...)

I talked about this on p1, mentioning the web's universality and the
importance of referencing. A quote from Berners-Lee discussing the
introduction of .mobi, which is close to the use of /i or /k
(http://www.w3.org/DesignIssues/TLD): "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. People look up URIs in all sorts of
conditions.
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."

So that's why it's important. (In an ideal world,) URIs shouldn't be
used to communicate device specific info.

> 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.
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.

> > You can add some basic
> > handheld CSS rules to make things prettier, but the most important
> > thing is that the content can be *accessed* with both classic and
> > mobile browsers.
>
> Accessed by the browser - but NOT necessarily "accessed by the
> person". The Guardian site is accessible by phone browser - it is
> just a pain to read

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.".

> > So, I'd like to see more of this kind of stuff on the Japanese web.
>
> I think it is a fundamental mistake. Same URI, same content, fine.
> But device capability IS one legitimate feature in deciding the IA of
> a site and that will affect content. Since having different content
> at the same URI (when accessed by devices of different capability) is
> bad - for pragmatic reasons (Google, etc) if for no other (although I
> think there are sound reasons relating to "content identity) - the
> URI has to change.

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?

> Any fool can make a site that delivers content wrapped for different
> handsets, or a desktop, from the same URI. I am sure that many sites
> that are /i or /j or /e all pull in the same engine and just pump it
> out of a different URI because users expect it.

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.

Andreas

--
http://akira.arts.kuleuven.ac.be/andreas/blog/
Received on Thu Dec 8 20:07:33 2005