> 2. Print devices. The pages display fine for printing, but if I want
> to print the document, I have to go to the first page, print it, go
> to the second page, print that, go to the third page, print that
> again, and so on. Some web pages print on less than half of a paper
> page, others take up more than one.
That's a good point. But imagine my paper would have been one long web
page: I don't think the reading experience on a classic browser would
be very pleasant, and footnotes would become endnotes, both on screen
and in print. So maybe you're even better off with a PDF file here (in
addition to the current set of pages): nice footnotes and page layout
(= easy printing), and all pages in one place (= easy saving). You
could argue of course that going the PDF route doesn't sound very
"device independent" - that may be true, but then you can also see the
PDF file as a sort of "source file" that is just there as an extra,
while the HTML pages are used for cross-device browsing, referencing
and linking. (compare it with offering images in JPG and RAW formats).
I'm just thinking aloud here - don't quote me on this ;-)
> Some printed pages have "prevous
> | overview | next" at the top and bottom, and there's a copyright
> at the bottom of some printed pages but not others.
That's weird - the navigation links are stripped out with a CSS rule
in the print version. Which browser do you use? I can't reproduce the
effect you describe in FF or IE.
> 3. Different URIs based on content. The user has to pick. This seems
> to me to be the best option. It gets rid of most of the disadvanages
> of the options above, and, given a small index page that links to
> the various formats available, indicates clearly to the user where
> the best place to which to link is.
The problem here is that you get small islands of mobile content - I
think there are two problems with this approach:
- search engines index both mobile and non-mobile versions, and as
there is no general rule to distinguish between them, there is a real
possibility that mobile and non-mobile pages get mixed up in the
search results - something that is of course not very user friendly.
N.B.: recently, Google started with its sitemap program
(https://www.google.com/webmasters/sitemaps/login), proposing a syntax
for defining classic as well as mobile site structures. This may
result in improved crawling and indexing, so the search engine problem
may disappear sooner or later.
- a bigger problem however is the URI portability / referencing
problem. And no, this is not only about geeks syncing their bookmarks
between their cell phone and computer. Imagine you have a blog and
offer it in "PC" and "mobile" flavors at two different URIs; mobile
phone users go to the mobile version and enjoy reading your posts,
until they click a link: they arrive on another blog's PC page. So now
the searching can begin: where is the mobile version of that other
blog? mobile.? Or /mob? Something else? In other words, with the
multiple URI system, you not only have to optimize page layout, but
also adjust all outgoing links. And that's a hard thing to do.
> BTW, Andreas, your TAB example may not be particularly good. When I use
> http://www.tokyoartbeat.com/, I'm almost constantly getting the message
> "Size of this page is not supported," and the layout is adequate, but
> not terribly comfortable on a keitai.
Hmm. That's strange. Do you see 携帯 東京アートビート 「ベータ」 on top? If not,
there's something wrong with our server settings.
Andreas
--
http://akira.arts.kuleuven.ac.be/andreas/blog/
Received on Fri Dec 9 20:38:06 2005