Any sensible person designing web sites these days ought to be
designing them with some consideration for how the sites will look
when viewed on a small-screen mobile device.
If you care to know the reasons, start by reading the
href="#reallymobile">Preface: What “mobile” really means
section below. Otherwise, just skip ahead a little, to where I
outline four steps you can take to make a site “mobile
considerate”:
Four steps to mobile-considerate site design
- Add “jump” links
- Adjust the physical order in your source
- Do initial layout testing in a PC browser
- Ditch the novel-on-a-roll-of-toilet-paper site design
Preface: What “mobile” really means ⇮
So who cares about mobile web browsing? Well, I do. Partly
because I work for a company that makes software for the mobile
Internet, but also because I personally use and rely on my
href="https://searchmobilecomputing.techtarget.com/sDefinition/0,,sid40_gci820042,00.html">keitai
(short for keitai denwa = mobile phone) and the “other
web” — the mobile web — quite heavily. More heavily,
actually, than anybody else I personally know. In fact, if there
is somebody using the mobile web more than me, well, I think
they’re using it too much. I think I’m using it too
much.
Any, being the trendsetter that I am, I find that people around
me often seem to start copying all the stuff that I do, and then
others copy them. and so on, and so on. So I’m sure it’s just a
matter of time before it reaches people like you, and you start
doing this cool thing that I do now — regularly browsing the web
on mobile devices. So if you’re someone who happens to design
things for the web, well, I think you can see that you can either
start designing now with mobile viewing in mind — instead of
designing exclusively for the un-mobile web — or you can play
catch-up later, after you finally get hip.
And note that when I say “mobile”, I mean truly mobile. As in
handheld mobile. To me, anything that requires sitting in a
chair is not truly “mobile”. Nor is anything the requires you to
place your “mobile device” on some kind of surface (other than
your hand) before using it. Because, while whatever device you’re
using which requires that may by some stretch of imagination be
considered “mobile”, you ain’t. Because all your fancy
technology has made you un-mobile.
Figure 1. You
![]()
src="/users/files/53819/laptop-jockey.jpg" width="300"
height="206" border="0" alt="Laptop jockey." title="Laptop
jockey." style="border: 1px solid rgb(204, 204, 204); padding:
4px; margin-right: 8pt; margin-bottom: 0pt;" />
photo copyright by
style="text-decoration: none; color: gray">dannyman, via
Flickr.
style="text-decoration: none; color: gray">Some rights
reserved
(I would go so far as to suggest that any device that requires
or expects the use of two hands to operate it is mobility-impaired in
comparison to a device you can operate with one hand (e.g., a
mobile handset). It is often important to have one hand free for
manipulating other things.) [cigarette, whiskey flask, booty]
Rock, paper, scissors: keitai beats Kaypro ⇮
So while you are slumped forward at a keyboard somewhere
“enjoying” a browsing experience via the magic of the contemporary
equivalent of a
>Kaypro, I’m out in the real world enjoying my favorite
activities [bar-hopping,
skirt-chasing, dope-smoking], all while browsing the mobile
web whenever the mood strikes me — using a truly mobile, handheld
device (in my case, a 2.4 Mbps, GPS-enabled
href="https://www.au.kddi.com/ezweb/service/ez_naviwalk/tokucho.html"
>location-aware
>W31T keitai).
Figure 2. Me
![]()
src="/users/files/53819/mobile-hipster.jpg" width="300"
height="296" border="0" alt="Mobile hipster."
title="Mobile hipster." style="border: 1px solid rgb(204, 204,
204); padding: 4px; margin-right: 8pt; margin-bottom: 0pt;"/>
photo copyright by
me. All rights reserved
Yes, it lacks a 1600-by-1200 pixel screen. Yes, it lacks a
keyboard with 90+ keys on it. But you know what? It doesn’t want
those things. All it wants to do is provide me with pure mobile
web-browsing satisfaction. And it does.
One last thing before moving on: Note that throughout the
discussion which follows, when I mention “handheld browser”, I mean
a web browser on a handheld device — a browser that’s not
CSS-aware to the extent, for example that it can render CSS floats
and absolute positioning (which are not useful or relevant in a
small-screen handheld view).
Adding “jump” links ⇮
Perhaps the first thing you need to deal with when trying to
make your site mobile-considerate is figuring out how to handle
navigation among the various parts of each page — particularly if your
site is rendered in multiple columns in the PC-based “big browser” view.
As an example of how to handle navigation for the handheld view
of a multi-column site, take a look in Firefox or another
PC-based browser at my friend
href="https://akira.arts.kuleuven.ac.be/andreas/blog/"
>Andreas Bovens’ blog, “chosaq”. It’s designed into three
major “page parts”, which in the PC view are rendered in three
columns: a wide first column at the far left that holds the main
content, and then two smaller columns on the right.
One of the smaller columns is a sidebar that has links to the
blog archives and that has a search form. The last smaller column
(all the way to the right) is titled “News Selections” and has
links to external sites.
Below is a screen capture of the top part of the chosaq
homepage (chopped and channeled so that I could fit in in
here).
Figure 3. Top part of chosaq as seen in a PC-based
browser
![]()
src="/users/files/53819/chosaq-pc.jpg" width="536"
height="202" border="0" alt="Chosaq in the un-mobile web"
title="Chosaq in the un-mobile web"
style="border: 1px solid rgb(204, 204,
204); padding: 4px; margin-right: 8pt; margin-bottom: 0pt;"/>
Now, if you look at the site in a handheld browser, you will,
of course, see just one column instead of three. But knowing that,
Andreas has designed the site with consideration for making it
easy for users to jump among each of the “page parts” (that is,
the sections that are rendered as columns in the PC view).
Figure 4. Top part of chosaq in a mobile browser
![]()
src="/users/files/53819/chosaq-top.jpg" width="240"
height="249" border="0" alt="Chosaq in the mobile web"
title="Chosaq in the mobile web"
style="border: 1px solid rgb(204, 204,
204); padding: 4px; margin-right: 8pt; margin-bottom: 0pt;"/>
Note the “Jump to …” links. If those links weren’t there, you
would find out the sidebar and “News Selections” parts existed
only if you took the time to scroll all the way down in the
browser frame.
Whether or not those links are displayed is controlled just
through CSS. If you look at the page in Firefox with CSS turned
off (go to
View > Page Style > No Style),
you’ll see that the links are actually still being served up in the
PC-based “version” (which is in fact the exact same content as the
handheld version). It’s just that they’re hidden in the PC
version, through the use of CSS (the display: none
property).
Adjusting physical order of source content
href="#nav">⇮
Another important thing to keep in mind is the physical order
(in your source HTML file) of the major divisions (which are
usually HTML <div>s) that make up the “page parts” you see in
the rendered view of the page. For most sites, the right-to-left
and up-to-down order of the page parts in the rendered output
usually matches the physical order of the divisions in the source
file. But for CSS-enabled PC-based browser views, the physical
order of the source for page parts in your HTML source file does
not necessarily need to match the rendered
ordering of the page parts.
Read the part above again. It’s very important.
What I mean is, for example: A lot of multi-column sites have
their smaller columns (navigation, sidebars, whatever) on the
left, with the main content on the right. For example, look at the
page you are reading right now: It has column on the left, with a
search form at the top of it, and with a long, long list of links
to all the O’Reilly sub-sites.
Most web designers who use that smaller-column-on-left style
put the source of the left-column div in the source file before
the source of main-content div. So when users like me go to
view your pages in a handheld browser, we’re screwed — because
you (thanks!) have forced us into doing unnecessary scrolling.
That is, we first have to scroll down through all the left-column
content to get to what we really came to the site to see, which is
the content in the other, main column.
Unfortunately, the site at which you are reading this page
uses that page-parts-in-source-file-order design. This is how
the top of the page looks in a mobile browser:
Figure 5. Top of this page as seen a mobile browser
browser
![]()
src="/users/files/53819/oreilly-mobile.gif" width="246"
height="379" border="0" alt="Example of poor page design."
title="Example of poor page design."
style="border: 1px solid rgb(204, 204,
204); padding: 4px; margin-right: 8pt; margin-bottom: 0pt;"/>
So if you were too look at this very page in an actual mobile
browser, you would need to scroll all the way down through the
entire listing at left of all the O’Reilly sub-sites before you
could actually start reading this piece. Do you reckon that
would make you want to have a word or two with the site designer?
It sure makes me want to.
If you instead put the source for “extras” (sidebars, etc.)
near the physical end of your HTML source file, you can
still use CSS floats and absolute positioning to cause it to be
rendered anywhere you want on the page. In the case of a
left-column-sidebar site design, put the left-column div
after the main-column div, and do your CSS magic to cause
that left-column div to be rendered at the left of the
main-content div when it is viewed in a PC-based browser. But
because mobile browsers display the content in the physical
order in which it appears in the source, when you view your
site in a handheld browser, you’ll now get the main-column content
first. (And you can add jump links like Andreas’s to let users
know the other stuff is there.)
Testing: Getting a handheld view in a PC browser
⇮
If you have a current PC-based version of the Opera browser,
then you can get a “small screen” view in the PC-based version
of Opera just be doing one of the following:
- type
Shift+F11
- or, select View > Small screen
That will cause Opera to reformat the entire page into a very
narrow single column.
By the way, if you are reading this page in Opera, try typing
Shift+F11
right now. See what happens? See what I
mentioned earlier about the search form and list of O’Reilly sites
being placed at the top of the column? See how far down in the
column the picture of my face is? Don’t I look lonely down there?
Wouldn’t I look much better and much happier at the top of the
column? I think I would. I wish the designer of this site would
fix things to put me up there at the top of the column, where I
belong.
Anyway, you’ll notice that the Opera Small
Screen
view also causes images to be automatically scaled
down such that they are tiny enough to fit in the width of
that single column — just as most current mobile browsers will do
(well, most decent ones, at least). Very cool stuff.
But even if you are not running Opera, you can still actually
get a pretty good approximation in a PC browser of the handheld
view of the layout of your site. There are a few adjustments to
make:
- Turn off all your “bars” (status bar, navigation
toolbar, bookmarks toolbar, etc.) other than the main menubar
(which you may not be able to turn off and which you probably
don’t want to, because once you do, you may not be able to
figure out to turn it back on again)
- Resize the width of your browser frame down to
something small. Really small. Make it so that the inner part
of the frame where the actual content is shown is no
more than 240 pixels wide by 320 pixels high (QVGA size); to
compensate for the browser menubar and scrollbars, that means
making the actual size no more than 260 pixels wide by 370
pixels high or so (there is a
href="https://addons.mozilla.org/extensions/moreinfo.php?id=60">Web
Developer toolbar for Firefox that makes doing that easy,
along with a lot of other things)
- Turn off CSS (by using the
View > Page Style > No Style
trick or causing your browser to use some stylesheet other
than the media=”screen” one — which is another thing that the
“Web Developer” toolbar lets you do)
- Play around with different font sizes. Users of
modern mobile web browsers can change font size too. Some like
big text, some small. At least try changing among 10, 12, and 14
points.
As you jack up the font size and jack down the browser width
and height, you will quickly start to realize that, on the mobile
web, you want to have as little extra junk as possible at the
top of your pages — because screen “real estate” up there is
quite valuable. You want whatever is at the top to pull your users
in right away. If there is nothing interesting right at the top.
they’re not going to take the time to scroll to try to find
something further down.
Here’s a screenshot of what chosaq looks like my
adjusted Firefox:
Figure 6. Poor man’s mobile-browser simulator
![]()
src="/users/files/53819/chosaq.jpg" width="268" height="400"
border="0" alt="image" />
That view is remarkably similar to what I see if I view the
page in a handheld browser.
Ditch the novel-on-a-roll-of-toilet-paper
page design ⇮
Most web sites serve up way, way too damn much content on any
given page. Most pages should have less content, not more.
As an example, consider a typical blog. The homepage for the blog
probably has the 10 or 15 most-recent items, and for each item, it
probably has the full text of the item right there on the home
page.
It’d be much more usable if the designer were to:
- put fewer items on each page
- “page” each item (serve up long items in smaller chunks, with
“read more” and “next/previous page” links provided for navigating
among the chunks)
So instead of having your blog homepage show the 15 most-recent
items you’ve posted, make it show just the 5 latest. And/or instead of
having your blog homepage show the entire freaking full text
(yeah, that really, really annoys me) of each of your 15
most-recent items, please (please) do me a favor: Have it just
show some reasonable portion of each item, with a “read more”
link to the full text.
And (do I need to mention this too?) once I get to the full
text, can you page it for me there too? Yeah, I know some people
don’t like that kind of paging. I suppose those same people
would also probably also like to read a novel published on a roll
of toilet paper. Or a parchment scroll.
Me, well, I think parchment scrolls suck. Scrolling
sucks. So spare me the novel-on-a-roll-of-toilet-paper design.
(And, smart guy, if — even after reading this — you insist on
continuing to design sites that way, well, I guess I’ll have to
come looking for. And I will find you. And I will smack some sense
into you. Because I reckon that’s the only way you’ll learn.)
Some examples of sites that do paging well:
- The International Herald
Tribune — open a news story. A “Page X:YY
”
at the bottom of the left-most column tells you what page you are
on and how many totals pages there are in the story. Now, resize
your browser frame; you’ll see that the story gets paged into
smaller parts dynamically, depending on the size of your browser
frame. And the numbers in the Page X:YY
indicator change dynamically.
- Gmail mobile — open a long
message and see that Gmail automatically pages it into smaller
parts — with a hyperlink at the end of the each part that
reads “more (N pages left)
“
Here’s a screen capture that shows what part of a paged
message looks like in Gmail mobile.
Figure 7. Paged message in Gmail mobile
![]()
src="/users/files/53819/gmail.jpg" width="236"
height="327" border="0" alt="Gmail message paging"
title="Gmail message paging"
style="border: 1px solid rgb(204, 204,
204); padding: 4px; margin-right: 8pt; margin-bottom: 0pt;"/>
The good news is that many frameworks for building web apps
(and most decent blogging apps) provide off-the-shelf mechanisms
for automatically controlling paging of content — so that you
don’t have to do it manually. Find those mechanisms and use
them.
Current practical limitations
⇮
Note that in the last section
above, I made no specific mention of the mobile web. That’s
because the design approach of using paging instead of scrolling
is important on the non-mobile web as well. But while it may just
be a optional “nice to have” approach to design on the non-mobile
web, keeping page contents small is a must have design
requirement on the mobile web — a requirement you
will need to meet if you don’t want to end up with a bunch of
pissed-off mobile-web users like me waiting in line at your front
door for their turn to smack some sense into you.
It’s a requirement in part due to some very serious current
limitations in many current handheld mobile-data devices and
mobile-data networks.
Those limitations include the fact that most mobile devices
have a relatively small amount of physical memory, without
even any mass (disk) storage to use for swap space when physical
memory gets low. In many cases, that tends to severely restrict
the maximum size of a page that a browser can render. How severely
it limits it varies among browsers, devices and carriers. But
40Kb as the maximum size for an individual page is a figure
you might hear mentioned.
Another serious current limitation is the fact that the data
speeds of many mobile-data networks around the world are extremely
slow. Pages on the mobile web can take a long time to load. If
you have only previously tested your pages over a
non-mobile network (DSL, a LAN, whatever), you’re likely to be
a little surprised as how long it can take most mobile devices to
load even a relatively small page.
But both of those limitations are (relatively) temporary ones.
Mobile-data devices with much more physical memory — along with
hard drives and other mass storage — will eventually be commonly
available. And the data speeds of mobile networks around the world
will increase significantly (as it has here in Japan).
Conclusion: PC-based “big browsers” are not the
only window to the web ⇮
The
limitations mentioned above have the practical effect of requiring
you — if you want your site to be accessible on most handheld
devices — to keep your page sizes small. Real small. However,
even after the current memory and data-speed limitations are
overcome, you are still going to need to keep your page sizes
small. Why? Well, because the screens on handheld browsers are
going to remain relatively small. There is a practical limit to
how big the screens can get before the devices become no-longer
hand-holdable and so no longer truly mobile.
So handheld users are going to continue to see the web
through a very different “window” than users of PC-based big
browsers — a small-screen window. And there are going to be more
and more handheld users wanting to get to a usable view of your
sites through that tiny window.
Ignore those users at your own peril.
Other factors that should go into “mobile considerate” site design?