Adapting pages for handheld media

[boclair]

In a discussion between AJ Flavel and Spartanicus, The later said.

"Layouts that work well on the desktop and on small screen devices are
single column layouts. Layouts that use more than one column rarely work
properly on a wide range of viewport widths. This also applies to "css"
layouts that use separate "screen" and "handheld" stylesheets due to the
poor support for the handheld media type and it's intrinsic limitations.
The same also applies to css table layouts".

I have amongst my tasking a request to investigate enabling pages
(whose content includes dynamically generated engineering tables and
graphs) to be made available for a range of hand held media.

My first quick efforts were not successful, I suspect because the
handheld devices are not identifying themselves exactly (or I am not
recognizing their markers) I think I am capable enough with CSS to
create stylesheets that convert multi-column pages to single column pages.

I would be grateful on some guide to references on what is involved or
other advise. (I have done a google. The W3 references seem limited on
the practicalities)

Louise

[Darin McGrew]

boclair <bo*****@boclair.com> wrote:

I have amongst my tasking a request to investigate enabling pages
(whose content includes dynamically generated engineering tables and
graphs) to be made available for a range of hand held media.

My first quick efforts were not successful, I suspect because the
handheld devices are not identifying themselves exactly (or I am not
recognizing their markers) I think I am capable enough with CSS to
create stylesheets that convert multi-column pages to single column pages.

What happens when you view your "first quick efforts" with CSS disabled?
Does that successfully "convert multi-column pages to single column
pages"?

If you advertise your multi-column style sheet as being appropriate for
screen media (and maybe print/projection media), then handheld devices
should ignore it. Just don't create a multi-column layout in your
media="handheld" style sheet. :-)
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Red meat isn't bad for you. Fuzzy blue-green meat is bad for you."

[Spartanicus]

boclair <bo*****@boclair.com> wrote:

I have amongst my tasking a request to investigate enabling pages
(whose content includes dynamically generated engineering tables and
graphs) to be made available for a range of hand held media.

This shouldn't be much of a problem if handheld devices are your sole
target.

The discussion you referred to relates to getting sites to work both on
desktop and handheld viewport sizes. To get proper functionality on both
you need to keep things really simple, simple navigation and no non
unique repetitive content. You then have to serve the same simple
version to desktop displays.

If you do that then afaik there is little point in using a "handheld"
css media type, hh devices that support it afaik default to "screen".
Some information on hh devices css support:
http://groups-beta.google.com/group/...302eec9a54bc7f

If serving such a simple site to desktops is not an option then the best
solution is to create 2 different sites.

--
Spartanicus

[boclair]

Spartanicus wrote:

boclair <bo*****@boclair.com> wrote:

I have amongst my tasking a request to investigate enabling pages
(whose content includes dynamically generated engineering tables and
graphs) to be made available for a range of hand held media.

This shouldn't be much of a problem if handheld devices are your sole
target.

The discussion you referred to relates to getting sites to work both on
desktop and handheld viewport sizes. To get proper functionality on both
you need to keep things really simple, simple navigation and no non
unique repetitive content. You then have to serve the same simple
version to desktop displays.

If you do that then afaik there is little point in using a "handheld"
css media type, hh devices that support it afaik default to "screen".
Some information on hh devices css support:
http://groups-beta.google.com/group/...302eec9a54bc7f

If serving such a simple site to desktops is not an option then the best
solution is to create 2 different sites.

I hadn't thought the problem through, had I.

I <<was>> attempting to use scripting to adjust the CSS behind a number
of existing template classes but, disabling CSS, as Darin McGrew points
out, shows the futility of this. What you now explain reinforces this,
since the disabling of CSS may be device controlled rather than client
controlled (this latter can be regulated in our environment).

Obviously there would be a need for new nonCSS templates and files at
least and possibly some server configuration considerations. Much more
work is involved than I had hoped to get away with.

Catering for hand held devices is obviously a rather costly proposition
and perhaps not even dependable with the current state of play.

I have started preliminary costings and, with the cost of deploying and
replacing "lost" devices added, somebody would have to be keen to
approve the implementation.

Thank you, and Darin too

Louise

[Alan J. Flavell]

On Mon, 21 Mar 2005, boclair wrote:

Obviously there would be a need for new nonCSS templates and files
at least and possibly some server configuration considerations.
Much more work is involved than I had hoped to get away with.

Catering for hand held devices is obviously a rather costly
proposition

I don't know anything about the sites you have in mind, so this is
just a what-if and for-instance response...

Often a site can be improved by taking things out. As Spartanicus so
eloquently advocated: KISS.

If doing that to an existing design costs too much, then maybe one
should be asking oneself why so much effort was mis-spent in the first
place on over-designing the site.

Compare for example the official uk rail planning site
http://www.nationalrail.co.uk/planmyjourney/
with an accessible alternative: http://www.traintimes.org.uk/

I don't just mean *look* at the sites - actually try using them from
different browsing situations (including narrow windows, text-mode
browser etc.) to make a variety of enquiries.

[boclair]

Alan J. Flavell wrote:

On Mon, 21 Mar 2005, boclair wrote:

Catering for hand held devices is obviously a rather costly
proposition

...
Often a site can be improved by taking things out. As Spartanicus so
eloquently advocated: KISS.

If doing that to an existing design costs too much, then maybe one
should be asking oneself why so much effort was mis-spent in the first
place on over-designing the site.

Thank you for raising this. This whole discussion has left me with
quite a lot to take away.

The following is self indulgent

The pages are not that pretty, even now, especially those which would be
candidates for hand held devices. The audience is engineering and
technical staff, many working on site.

Apart from unambiguous and readily scanned display of content, however
got, the main consideration is providing an intuitive and flexible
method of navigation across the site so that another document, where
ever located, can be reached from the current document as directly as
possible (The guide is any document is no more than three "clicks" from
any other). We are in the habit of doing this by columnising the page.
We would need a new approach to navigation for hand held devices, for
the reasons set out earlier by others in this thread, and, in the
available literature

The other reason we columnise is, and I realize there will be criticism
of this, is to reduce the length of the text line in the desk top
display. Our content is often didactic needing to be read carefully and
understood phrase by phrase. We tend to set the text in short sentences,
eschewing conditional clauses and in short paragraphs. The physical
dimension of the viewport on hand held creates a different environment.

Going to hand held, along side desk top, supplemented with printed
pocket handbooks, would require a major rethink for us. However since
such technologies will undoubtedly have a future place in businesses
such as ours, I think, whatever the decision now, you are right in the
observation that web documents need to be simplified in structure. I
don't know that ours are sufficiently.

Louise

[Rijk van Geijtenbeek]

On Mon, 21 Mar 2005 14:53:55 +0100, boclair <bo*****@boclair.com> wrote:

...

Thank you for raising this. This whole discussion has left me with
quite a lot to take away.

More info on designing for handheld media:
http://www.alistapart.com/articles/pocket/
--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

[Gus Richter]

Rijk van Geijtenbeek wrote:

On Mon, 21 Mar 2005 14:53:55 +0100, boclair <bo*****@boclair.com> wrote:

..

Thank you for raising this. This whole discussion has left me with
quite a lot to take away.

More info on designing for handheld media:
http://www.alistapart.com/articles/pocket/

Live demo for Small Screen Rendering (Gecko Only):
http://www.glazman.org/weblog/newarc...azblogarc.html

--
Gus

[Alan J. Flavell]

On Mon, 21 Mar 2005, boclair wrote:

The pages are not that pretty, even now, especially those which
would be candidates for hand held devices. The audience is
engineering and technical staff, many working on site.
Web pages are best if they're "fit for purpose". What that means,
obviously depends a great deal on the "purpose". Engineering and
technical documents are rarely a work of visual art in the normal
sense of the word, so I wouldn't say that a verdict of "not that
pretty" is, in and of itself, any criticism of the pages. Of course
we aren't getting actual samples to comment on, so we can only comment
on your descriptions of them...
Apart from unambiguous and readily scanned display of content,
however got, the main consideration is providing an intuitive and
flexible method of navigation across the site so that another
document, where ever located, can be reached from the current
document as directly as possible (The guide is any document is no
more than three "clicks" from any other).
OK
We are in the habit of doing this by columnising the page.
You mean navigation columns alongside substantive content? Dare I
suggest that in this kind of context, that might not be the optimal
choice? As I see it, there's basically two phases to the use of this
kind of site: 1. find the relevant content and 2. make use of it.

While users are locating the relevant content, they need good links,
indexes, tables of contents or search engines, or some combination of
all, and enough overview of what they found in order to decide whether
it's what they were looking for.

While they're -using- it, they'll mostly want cross-links in context,
and the site navigation won't get used till they're good and finished
with the page.

Let me take a practical example. This week I've had to start getting
up to speed with PF in OpenBSD, which is quite a new topic for me,
even though it's in my general field.

So we start at http://www.openbsd.org/ , which is evidently a language
selection page as well as a general overview navigation. I don't see
the topic PF there directly, so I could drill down for documentation,
or try a search. I do the latter. And the first hit is
http://www.openbsd.org/faq/pf/

I'm obviously in the right place, and here we have a table of
contents, simply and straightforwardly set out. I pick the
appropriate section. Now it's time to start intensively reading. The
text has links aside to relevant topics, but, while I'm studying the
text, I have no need of a complete naviation menu to the rest of the
site. The few major links that are provided here are ample.

We could go into detail about this or that aspect of what they're
doing here, but by and large I say that this *is* fit for *its*
purpose (of course it's never going to sell Disney to the kids, but
it's not meant for that).

And it works well enough in a narrow window, leaving room on a decent
sized display to consult other materials at the same time; while still
working well on a display where space is limited.
We would need a new approach to navigation for hand held devices,
for the reasons set out earlier by others in this thread, and, in
the available literature
Welll...
The other reason we columnise is, and I realize there will be
criticism of this, is to reduce the length of the text line in the
desk top display.
I think we all agree that long lines are not easy to read. That's why
I've taken to specifying a max-width in em units for paragraphs. A
pity that the operating system component that thinks it's a web
browser doesn't support that, but we can't have everything. Users of
that thing are entirely free to narrow their browser window.
Our content is often didactic needing to be read carefully and
understood phrase by phrase. We tend to set the text in short
sentences, eschewing conditional clauses and in short paragraphs.
Fine, no complaints from me...
The physical dimension of the viewport on
hand held creates a different environment.
Yes, indeed it does. The simple solution adapts itself calmly to
quite a range of presentation situations; although nobody's claiming
it's perfect, it does rate to work better than some over-engineered
pixel-perfect multicolumn design (I guess you knew I was going to say
that).

I repeat, since we can't see concrete examples of what you're
describing, the comments have to be based on an interpretation of
what you're saying, so I could well be missing the target...
Going to hand held, along side desk top, supplemented with printed
pocket handbooks, would require a major rethink for us.

Good luck ;-)

Of course those OpenBSD pages could use a judicious application of
stylesheet, and removal of some deprecated HTML features. The only
other accessibility criticism is about the navigation links plus table
of section contents at the top of each page. WAI guidelines would
want these to either be elsewhere, where they don't get in the way of
getting to the body content; or to offer a first link which skips
directly to page content. (I'm still uneasy with the latter
"solution" myself). But I still say that in their existing form it's
quite justifiable to rate them as "fit for purpose".

[Now try to get the same sense out of the technical support section of
a big vendor's site.]

all the best.

[boclair]

Alan J. Flavell wrote:

On Mon, 21 Mar 2005, boclair wrote:

The pages are not that pretty, even now, especially those which
would be candidates for hand held devices. The audience is
engineering and technical staff, many working on site.

Web pages are best if they're "fit for purpose".
Of course
we aren't getting actual samples to comment on, so we can only comment
on your descriptions of them...

the main consideration is providing an intuitive and
flexible method of navigation across the site so that another
document, where ever located, can be reached from the current
document as directly as possible

OK

We are in the habit of doing this by columnising the page.

You mean navigation columns alongside substantive content? Dare I
suggest that in this kind of context, that might not be the optimal
choice?

While users are locating the relevant content, they need good links,
indexes, tables of contents or search engines, or some combination of
all, and enough overview of what they found in order to decide whether
it's what they were looking for.

While they're -using- it, they'll mostly want cross-links in context,
and the site navigation won't get used till they're good and finished
with the page.

Once again thank you for taking the time to give me such a detailed
response.

Unfortunately I am unable to provide access to any pages that would
demonstrate our page structure; but you have a very clear idea of what
they may be like, as would be expected. Points you have been making are
pertinent.

All I can do is provide a general description of a typical web document
for desk top display. (The site, network not www, is heavily scripted
with a database backend. The user logs in and depending on his
organizational position and peer group is granted access to defined site
resources).

A typical web page displays a header and a footer with a main body of
three columns with the left and right columns absolutely placed.

The left column is a menu column with categorized links giving access
to granted material. ( The restricting of access is only in part about
"need to know" and "need to know who accessed" considerations. A major
consideration is about managing the delivery of web pages efficiently
and menu management) (Called the main menu)

The header has details of the user, the page title and concurrence. It
has a search "box" rather like that used by php.net. Beneath is a
dynamically generated horizontal menu with links to pages that most
usually (and recently) called from any of the menus on this page, by
<<all users>> (Called the page menu).

The right column is also a menu column, dynamically generated, that
lists the links in link categories that <<the user>> or his <<peer
group>> most usually call, (not originating page related). (Called the
User menu)

The main use of the footer is to provide web mail to directed recipients
and where appropriate, database table inserts.

For most users this arrangement works fairly well. But it is a Sunday
too far for any small viewport device.

As an aside, we have started story boarding the serving of resources to
hand held devices for sometime in the future. The immediate purpose is
to reflect on our present authoring guidelines for desk top displays.

However it is already clear that having a scripted site with database
backend overcomes a lot of problems in using common resources for desk
top and hand held and obviates the need for site and much content
duplication.

I am now a long way from ciwas. Thanks to the community for
indulgencing me and especially for the insights.

Louise