Webmonkey: design: The End-All Guide to Small-Screen Web-Dev

The End-All Guide to Small-Screen Web-Dev
by Heidi Pollock

Nothing is more fun than seeing your Web page nestled nicely into a teeny tiny handheld screen; and nothing is more excruciatingly horrendous than trying to figure out how to get it there. The number of devices, screen sizes, operating platforms, and support levels for small-screen browsing is mind-numbing. While doing the research for this article, I actually walked away from my computer right in the middle of my umpteenth developer guideline PDF download, hopped in my car, picked up a bottle of wine, three DVDs, returned home, and crawled into bed. That's how bad it is.

You, of course, will be spared from having to watch Chicago, xXx, and Bringing Down The House, and yes, all in one sitting, because I am going to hold your hand as we walk through the valley of darkness that is small-screen wireless web development. You won't even need the cheap red wine — though a good jolt of caffeine might keep you awake during the onslaught of acronyms I'm about to toss your way.

You can skip ahead to the more specific design tips, but if you want to understand which guidelines matter to whom and why, you're going to have to wade through the wireless wilderness with me first.

Learning the "L"

My fellow Webmonkey and superfriend Paul, who generally knows more about technology than seems normal for one person, offers this linguistic pointer to help us on our jargon journey: Acronyms that end with "P" tend to be protocols because Protocol starts with the letter P; acronyms that end with "L" tend to be markup languages because Language starts with the letter L. Yes, I know you knew that.

OK. Languages are what we code our Web pages with; protocols are how they get delivered. Good ol' HTTP, the Hyper Text Transfer Protocol is how all the HTML (and now XTHML) pages get delivered to a monitor near you. HTTP was also used to deliver web pages coded in the Handheld Device Markup Language (HDML), a language hacked together for mobile devices. But HDML was an interim measure, more or less killed off when a bunch of folks decided that HTTP was too slow a delivery system for wireless devices and came up with a sleeker, faster protocol known as the Wireless Application Protocol (WAP). WAP, being a protocol and all, needed its very own corresponding markup language so it would have something to deliver. And thus was born WML, the Wireless Markup Language.

Why am I boring you senseless with acronym roulette? Because every cell phone, PDA, or handheld device that renders a Web page does so by means of a browser that will or won't be able to parse one or more of these markup languages. If the varying degrees of screen browser support for CSS makes you mental, now might be the time to run out and buy yourself a nice bottle of wine, because the small-screen world is a Rubik's Cube of compatibility issues.

There are three major components in the wireless world, some of which have nothing to do with us lowly content developers, but it helps to have an overview if you want to wade through the support documents on your own.

At the base of all this wireless surfing are invisible waves that go through the air: CDMA, G3, Bluetooth, 802.11, etc. As a designer, you don't have to worry about this. However, in the sense that some of these transmission schemes may or may not effect the future economic health and longevity of wireless providers, servers, proprietary devices, operating systems, and browser platforms, well, it's worth keeping in the back of your mind.

Next there are the devices themselves. There are phones and there are PDAs and there are PDA phones and there are a few things that are kind of like PDA phones but not really. Each one of these small-screen devices picks up one or more of the invisible wave types and, lastly, pushes your data through some form of operating system, which may or may not support multiple or proprietary browsers.

One Hoop Shy of the Olympics

Whether or not some, or all, of your data finally makes it into the window of a small-screen browser (or SSB, the acronym coined by our very own Evany Thomas in order to spare me the trouble of typing "small-screen browser" a hundred times) is dependent on its ability to jump through four hoops. Hoop One: does the service generating the invisible waves have a throughput cut-off point? How big is it? 32K, 100K, more? Hoop Two: what protocols does the device support and will it deliver the language you've used? Hoop Three: is there a proxy server involved and what sort of data does that server automatically filter out? Flash? Large images? Tables? Hoop Four: Which codes will the device's browser support? HTML 3.2 or 4.1? CSS? JavaScript?

May the force be with you as you try to figure out which combination of elements you're mostly likely to encounter. Traditionally when we coded our pages for browsers displaying on regular-sized monitors, we only had to concern ourselves with what browsers, plugins, monitors, screen resolutions, access speeds, and codes will needed to be supported. As demanding as these questions can be, at least we have more than a few statistics sites that compile user data for us. When we code a site for a small-screen wireless device, however, there is almost nothing to guide us but whim, luck, and hubris.

I would be lying to you if I didn't admit my deep and abiding rage for the ocean of available FAQs and white pages and developer guidelines pertaining to the topic of small-screen Web design. The bulk of this supposedly informative information is by-in-large obtuse, useless, illegible, or locked behind account-only developer subscriptions. Almost all of the critical files are PDFs, which is nice in a cross-platform way, but more than a little weird when you consider that the people who want to read the files are Web designers and pretty likely to have access to browsers capable of parsing HTML.

Finally, there is virtually no way to test your site for small-screen compatibility short of downloading literally gigs of unnecessary SDKs. As if mere humans are supposed to know what that acronym means! (Software Developers Kit, by the way.) Content developers should not have to download software development kits simply to test their websites for small-screen compatibility, and the various SSB developers are crazy to demand otherwise. Opera, alone, is the only SSB to offer some meager way to test your SSB-compatibility. This state of affairs is unforgivable and I sincerely hope the industry is listening.

Now that I've gotten that out of the way, let's talk turkey.

Sites Served Three Ways

There are three basic approaches to squeezing your site into a small screen, but there's no fairytale goldilocks "just right" method. The most extreme approach is to design a whole separate version of your site for SSBs. Call me old school, but I don't think this is how anyone should be developing for the Web. Properly coded, a site should be accessible to everyone, with the information formatted on the fly in a manner appropriate to the viewer's connectivity. This is what stylesheets are about, this is what the accessibility initiative is about.

The most minimalist method is simply to take some mental notes for what does and doesn't work on the small-screen and keep them in the back of your mind as you design for large-screen browsers. This is the cross-your-fingers-and-pray method and, frankly, I don't think it's all that bad. Most Web surfers still prefer to use big screens and unless your site is explicitly serving up information of interest or use only to the small-screen audience — location of nearest cell towers, tiny directions and maps — you can expect a certain amount of patience and understanding on behalf of the SSB community. They don't expect bells and whistles, they just want clarity. With most SSBs resizing images and stripping out distracting formats, the community is used to seeing black-on-white text-only sites and there are only a few landmines to avoid in order to ensure your site gets properly stripped down.

The in between approach relies, of course, on CSS, whereby you use the HTML 4.0 media="handheld" attribute to direct SSBs to load a stylesheet designed with their needs in mind. This one-if-by-land, two-if-by-sea approach is probably the most design-savvy. It requires you to separate your content from your design and use CSS the way it was meant to be used. Finally. Right now you may or may not be concerned with the small-screen audience, but someday soon your audience will be browsing over television and voice connections, so you might as well buckle down, once and for all, and learn to separate your data from your formatting.

OK. Time to jump through some hoops.

Jumping Through Hoops

Hoop One: Throughput

The throughput hoop is much easier to jump through than it used to be. It is a rare (or at least old) device that will flat-out stop your page from being sent. Throughput limits may range from around 32K up to 100K or beyond, and the newer gizmos are better at dividing large files, sending them in small chunks, and reassembling them "inside" the device. When serving a Web page, images, stylesheets, and anything that involves following a link are all served separately. With those out of the picture, what's left is just your text, and I doubt many of you have pages with over 32 KB of text.

Of course, by text I don't mean the words a visitor reads but the source code itself. Keep in mind that white space is a character too and must be "sent" along with everything else — every line break, every tab indent inside your code takes up a few bytes (OK, usually just 8, but still). Keeping the empty space in your source code to a minimum gives you a speedy little edge.

Other byte-hogging codes include everything from those dreaded font tag attributes (seriously, stop using FONT now! CSS is your friend!) to JavaScript and meta tag descriptions. I'm not suggesting you stop using JavaScript or meta tags, I'm just pointing out that these, too, take up space.

Most small-screen development guidelines suggest you keep your pages to a total of 10 KB, including images. This is pretty unreasonable unless you're taking the extreme route and designing explicitly for the small-screen world. What you should consider is that the common throughput for a wireless device such as a cell phone (opposed to a bluetooth device) is closer to 19.6kbps, with a best-case-scenario of about 56kbps. If you still have access to a dialup account and remember how to set your modem properties, you can restrict your own access speed and test your site's load times to assess just how painful the wait might be for wireless users.

Though it's not as true for WAP connections, owing to the manner in which TCP/IP works, sending eight 1 KB images takes longer than sending four 2 KB images. In other words, even if the only images you're using are teensy, little black-and-white GIFs, the more you're sending, the slower your page will load. As for big images, whether or not they get sent depends largely on the provider's throughput limit, but I definitely wouldn't count on any single file (image or otherwise) larger than 100 KB getting delivered.

Hoop Two: Protocol

The protocol hoop basically comes down to WAP versus HTTP. If you want to reach every single wireless user, you have to code an entirely separate version of your site in WML. WML is a more compact language, and WAP is a faster protocol than HTTP, so you may decide there are benefits to developing a WML version of your site. That said, even though many devices (usually older cell phones) run only WAP/WML browsers, most devices capable of receiving HTML usually have the capacity to support WML as well. Furthermore, the Open Mobile Alliance (formerly wapforum.org) is pushing XHTML now instead of WML, so even if WAP 2.0 gains favor as the wireless protocol of choice, the preferred coding language will be XHTML.

Confused yet? At great personal risk to my inbox, which will likely receive tons of hate mail now, this is my one sentence summation: code in HTML, not WML, and follow the very few basic rules to make your HTML XHTML-compatible.

Hoop Three: Proxy Servers

Before we get totally bogged down in language-support caveats, first a word about proxies. The wireless service provider and/or the browser application itself may pass your Web content through a proxy server which will filter, alter, or strip down your site before delivering it to the device for display.

As murky as this can get, traveling through a proxy is fundamentally a good thing for small-screen surfers. In short, a proxy won't send stuff that can't be displayed. No matter how crazy your site is, you can trust a proxy to speed delivery by holding back "unnecessary" content. Some proxies will simply kill large images while others will resize them before sending. It is also common for proxies to filter out music, Java, Flash applications, animated GIFs (sending only the first frame) and other multimedia of the bells-and-whistles variety. If your site's functionality is dependent on these sorts of plugins, you'd be wise to rethink your SSB strategy. Lastly, a proxy server may also be an additional source of throughput limitation.

Most of the more popular small-screen browsers employ some level of proxy filtering. It is crucial to understand that there is a very important distinction between what a SSB will support in terms of delivery versus display. Unfortunately, understanding this distinction is only marginally helpful thanks to the fact that the developer documentation frequently confuses these two concepts; you will search in vain for detailed explanations of which code gets delivered but not displayed and what codes and files are conveniently filtered out through a proxy server. Meaning, one browser that doesn't "support" animated GIFs might filter out extraneous frames, delivering only the first GIF in the animation, while another browser might deliver the entire file but only display the first frame. May heaven help you when you're troubleshooting your load times because most of the SSBs don't offer source viewing functionality. In other words, there's no safe way to ascertain which lines of HTML code are sent but not displayed and which are filtered and not delivered.

But enough about what doesn't get displayed. Time to throw ourselves through the fourth hoop.

Hoop Four: Browser Code Support

Like any good game, the final hoop is the hardest.

Just like with the big computers, small-screen browsers run on operating systems. Unlike the bulk of big-screen browsers, the SSBs aren't cross-platform in any meaningful sense of the term. And so our discussion of browsers must begin with a brief rundown of small-device operating systems. Alphabetically, the major operating systems are: Palm OS, Symbian, and Windows CE. While each operating system has more than one browser option, the newest Palm OS includes Palm's Web Browser Pro 3.0 (originally NetFront); Windows CE not surprisingly bundles up Pocket Internet Explorer; and many, but by no means all of the latest smart phones (Nokia, Sony Ericsson, Motorola) running the increasingly popular Symbian OS include a handheld flavor of Opera. Blackberry devices rely on the RIM operating system and tend to come with Blackberry's browser, while one or two third-party solutions also exist. The T-Mobile Sidekick, running Danger system software, has an almost evangelical following although it comes with a proprietary browser and (as of press time) does not have the means for users to download others. (Links to these products appear at the end of this article.)

Because of the big XHTML push, all of the newest SSBs for all of the operating systems noted above support HTML and CSS while remaining backward-compatible with WML. The only category of users that won't have HTML-compatible browser options are users of older (by about two years) cell phones. If you're just starting out, you should definitely code your pages to be XHTML-compatible, using stylesheets for your layout. If you have an older WML page, now's the time to migrate to XHTML. I am definitely a fan of standards, so feel free to disagree with me here, but wireless users (just like we big-screen surfers) should be responsible for downloading and upgrading their SSBs. The PDA folks have tons of newer browsers to choose from and, while some older phones may only offer WAP, phones break or get left in cabs or dropped in toilets, so these people are bound to upgrade in the near future. In other words, worrying about the WML-only audience is not unlike worrying about the 4x screen browser audience — only you can decide if this shrinking group of users is a mission critical concern for you.

Now that I've made the case for XHTML, I should warn you that when you read through the various SSB specs on language support, you're going to find out that a bunch of them only support HTML 3.2. First off, this isn't actually true. Secondly, even if it is, it probably doesn't make a difference. Chances are your code is exclusively 3.2 as-is (yeah, all you font tag users know whom I'm talking about). Secondly, most of these supposedly HTML 3.2 browsers have finessed their code support to include popular 4.0 tags like "span" and "frames". The 4.0 tags that aren't supported are more along the lines of "thead", "tfoot", "col", etc. At the other end of the scale, even a DOCTYPE of "XHTML 1.0 Strict" hasn't produced any terminal effects on the SSBs I've used (what, your site still doesn't have a proper DOCTYPE declaration?). For people who must know everything, here's a link to the w3.org summary of the differences between HTML 3.2 and 4.1.

A quick aside about "cHTML": You may come across this term, but be advised that it is not a real language. CHTML was a proposal made in early 1998 for a pared-down version of HTML that would load quickly on wireless SSBs. Although it was never formally adopted, if you're the kind of person who enjoys reading those w3.org abstracts, the proposal forwards a minimalist design ethos that any serious SSB designer could use.

JavaScript support is scanty and random. Neither the Sidekick nor the Blackberry have a browser that supports javascript. Pocket IE apparently supports 1.1, Opera Symbian has partial support for 1.3, and Palm OS 5 Web Browser 2.0 supports javascript 1.5. Use that knowledge as you will. Nearly all the devices do support cookies, forms, and some level of SSL, so it's not as if small-screen browsing lacks for interactivity.

As for CSS support, truthfully that's a bit of a mess, too. This shouldn't come as a big surprise to anyone. CSS is fundamentally about formatting, not structure, and the devices themselves have daunting limitations that SSB developers have obviously catered to in their applications. The SSBs reinterpret your potentially hazardous code (20px borders, pre text, etc.) in ways presumably designed to optimize display for the small-screen experience, in effect, second guessing the intentions of the designer.

As few people design their websites for both big and small-screen audiences, I'll admit I sympathize with this father-knows-best approach. If the Web looks bad, visitors are more likely to blame the browser or the wireless technology than the designer. Unfortunately, the situation resulting from this default designing is more nightmarish than even the earliest days of CSS — no small-screen browser "fully" supports CSS, the CSS code that is supported differs from one program to the next, and, bonus points, this is all intentional!

The good news is that some SSBs won't mess too much with your CSS if you link to an explicitly defined handheld stylesheet. For instance, Opera's Symbian browser employs something they call "small-screen Rendering" (or, SSR, in their terminology). They tweak with your HTML according to their SSR rules unless you've specified a unique handheld stylesheet, whereby they trust you to know what you're doing with fixed table widths, images sizes, etc.

Here's the tag you'd want to use to point to a handheld stylesheet:

<link rel="stylesheet" type="text/css" media="handheld" href="file_name.css">

This relative link won't have any effect on visitors using large-screen browsers; only handheld browsers that support CSS will be sent to the alternate stylesheet. The media attribute was defined with HTML 4.0.

In the end, no matter how much code a SSB supports, or how well it honors your chosen formatting, the built-in display parameters of handheld operating systems in combination with the limited pixel dimensions of the small-screen itself place constraints on even the best-intentioned SSB developer. The sheer diversity of devices presents problems that no amount of compatible coding has yet to conquer.

And so with heavy hearts we leave the hoops now and enter the small-screen display funhouse hall of mirrors.

The Incredible Shrinking Font

While the PDA world (Palm OS and Windows CE) offers a pretty standard array of font sizes (9, 12, 18 point, etc.), most devices are limited to at most three font sizes. There is massive cross-platform variety in the pixel sizing of this small-medium-large approach. For instance, the Sidekick fonts are either 7, 9, or 12 pixels tall; Nokia Series 60 phones use 12, 13, and 17 while their Series 40 phones use 9, 19, and 23; older Ericsson phones use 9, 10, and 12.

The real fun begins when the SSB has to decide which of its default sizes to use for your code. You might think that the "big" and "small" HTML tags can help you out here, but you'd be wrong. I have no good explanation for why "big" and "small" don't twist the font sizes the way you'd want them to — they're non-deprecated HTML 3.2 tags, after all — but I believe it has to do with how the SSBs convert your point and pixel sizes to those available within the device. The SSBs that support CSS will sometimes look to the font size attributed to your P tag and go from there, but most use a strict interpretation, automatically converting, say, all fonts with medium-ish point sizes (10-14pt) into their "medium" pixel height, which may be 9, 10, 13, 19, or something else. "Big" and "small" don't work well because shrinking a 12pt font (either through the stylesheet "font-size: smaller" attribute or the HTML "small" tag) only knocks it down one step, to 10pt, which the SSB is likely to map as "medium". In short, relative font sizing is a total crap shoot.

PDAs will, depending on the user-configured settings, employ corresponding point sizes if they find them. PDA power users may have special font packages installed which will come with their own small-screen array of point sizes. Whether (and how) the extended font applications installed are in charge of mapping these custom sizes in a browser or whether this job falls to the SSB is beyond my knowledge. Lastly, many devices allow users to override their whole systems to restrict the smallest sizes to being something other than, well, small — leaving a SSB with merely two, or perhaps even only one size to choose from.

Relative sizing and point sizing are unpredictable even in big-screen browsers, so most designers use pixel sizes. But be warned: Don't expect explicit pixel heights to work. The problem is that some SSBs are capable of displaying exact pixel heights, which is a small-screen disaster when you've set sizes to be, say, 30 pixels high (that's one third of the screen in most cases). Furthermore, while 11 pixels is fairly dainty on a monitor, it's "normal" on small screen. Chances are that any pixel sizes the SSB can match will be displayed, while the rest will be rounded up or down accordingly, and they're all likely to end up as Medium, ruining any sense scale you had going. The one instance where pixel sizing would be acceptable is if you create an entirely separate stylesheet for the mobile visitor. In this case, you can probably get away with setting small absolute pixel heights, which some SSBs may be able to interpret accurately as the rest go about their stubborn resizing ways.

Based on some admittedly haphazard testing of my own, what I've discovered is that heading tags can provide you with the greatest font size control. For the most part, H1 tags appear in the largest available size while H6 appears teeniest. H6 can be unreadably small on many big screen browsers, but you can use stylesheets to bail you out of that trap. What happens when you use the heading tags with stylesheets is that a CSS-compatible screen browser will render the fonts exactly as you code them while the SSBs automatically use their default Largest and Smallest pixel sizes for H1 and H6, ignoring most of your mapped style declarations for these tags. This is a nice way to gain back some control of font sizes without coding a separate handheld stylesheet. You should try not to abuse the structural philosophy behind heading tags: Use H1 and H2 for site and page titles and maybe H6 for tiny footers, but don't start wrapping body text in heading tags just for the SSB audience. Why not? Because it's wrong, that's why.

For truly lovely SSB compatibility, try to design using only three font sizes. At worst, that's all you're going to get out of a small screen to begin with. Even if you can extract more relative sizes out of a SSB, it's likely that your page will seem messy and confusing with all those different looks squeezed together in a three inch screen.

Less Than Festive Decorations

As far as text goes, bold is about as exciting as it's going to get in the way of text decoration. Few PDAs and fewer phones have italic formatting to begin with because it looks so awful on the small screen, so both EM and I tags are rendered as bold. Most SSBs will take all the formatting tags (B, I, U, EM, STRONG) and just make them bold for lack of anything better to do. This doesn't mean you can't or shouldn't use the tags, just be prepared for the monotonous small-screen look. But don't despair, this minimalist font styling is much easier to read and these constraints actually make you look good on the small screen.

While you still have the previous page's font-size difficulties echoing in your head, I should mention here that some SSBs will use boldface to make "larger" fonts. This is quite common on the non-PDA platforms. Where 12pt might translate into "medium" and 24pt might be super-sized, 18pt might be rendered as bold "medium". If you find yourself browsing your own site on a SSB and wonder why your text turned bold, that's your answer.

Never underline anything that isn't a link. It is ridiculously confusing on a small screen. (It's kind of confusing on the big screen too.) As a corollary, be prepared for the fact that your link text decoration set to "none" will be ignored by nearly every SSB. Links without underlines are as confusing as underlines without links. Again, the SSB makes your site easier to navigate no matter what your stylistic intentions.

Use color with care. Colored text is a possibility only on color PDAs (go figure) running properly compliant SSBs. Color cell phones using proprietary browsers are unlikely to display anything in colors except for images, if that. The Sidekick and the Blackberry (I'm guessing about the Blackberry here because its developer PDF is corrupt — welcome to my world) opt to display all text in black on white. Black on white is always clear and although you may be able to come up with pleasing, easy-to-read high-contrast color combinations, the smallest of the SSBs can't go around trusting everyone not to code with white-on-yellow.

Here's what I suggest for using colored text. First, you can't count on it, so don't rely on color. If you want to highlight your text in color, try to use an HTML tag that will degrade in a useful manner. For instance, use the "strong" tag in your markup and set its style to be a not-bold red; people with color capable devices and CSS-compatible browsers will see red text while other users will see bold black text and either way you've created a highlighting effect with great cross-browser potential. As for color depth, the best color displays offer 65K, which probably seems great only because you haven't read David and Hadley's article about color palettes.

Second, keep contrast in mind. Similar colors and hues may look soothing on a large screen browser, but they'll be indistinguishable on the small-screen and quite likely identical in greyscale. Check out your site in greyscale by taking a screenshot and converting the picture just to make double sure you've got enough contrast in your images, backgrounds, and colored text for the site to work for those surfing in the twilight zone. I have no stats on how many people are using greyscale SSBs, but why make their lives any worse?

There are no font faces. Pocket PC is the only platform that ships more than one font face (Tahoma, Bookdings, Frutiger Linotype, and Courier). Palm users may choose to download extended font packages, but like so much that depends on the users, this can't be counted upon. If you are still using the "font" tag to set colors, font faces and styles you might note how this bulks up your code for no reason — the SSBs can't do much of anything with those awkwardly defined attributes in the first place.

The Small Screen Takes Off Ten Pounds

As I mentioned before, proxy servers or the browsers themselves will shrink your images to fit the screen. Unfortunately, like tossing a wool sweater in the dryer, the shrinkage is never even. Big images will be squished to fit while small images that already fit won't change. This loss of scale can be merely ugly or fundamentally disastrous. Conceivably, your navigational GIFs could be larger than your company logo, which is not something the marketing department is likely to sign off on.

It would seem that the safest approach is to shrink your images to fit the screen yourself. But which screen, you ask? Hah.

All dimensions in the following litany are given in pixel sizes with the width first. The typical Pocket PC, whether PDA or embedded in a phone, measures 240x320. The original Palms, Handsprings, and current low-cost models measure 160x160, with newer models clocking in at 320x320 (one of the Tungsten models offers a "stretch" display of 320x480). The newest Blackberries give you 160x100 while the Sidekick is 240x160. As for phones, a smattering of Samsung screens range include 128x160, 128x169, 160x240; the Nokia series 40 is 128x128, series 60 is 176x208, with smaller (96x65) screens for older phones and strangely wide (640x200) landscaping screens on the newest series 80. The Sony Ericsson P800 is 208x320.

I list all those numbers for you because, frankly, they weren't that easy to come by. I still can't get any useful information off the Sanyo or Motorola, websites and the majority of independent product reviews give screen dimensions in ruler measurements which are completely useless to content developers.

But wait! There's more! Default menus and scroll bars reduce the actual display size, producing a whole new set of working numbers. For instance, those 128x128 Nokia Series 40s only have a usable size of 122x96. The Sidekick is more sparing with its shrinkage, shaving only four pixels off the width to give you 236x136. Pocket PCs drop a stunning 15 and 60 pixels, giving you 225x260. And the older Palms shave off 10 pixels in both dimensions, leaving you with 150x150.

So, given all those many different screen sizes, what's a poor, sad, and probably sinfully underpaid developer to do?
Small Is the New Small

If I were absolutely forced to make one sweeping decision, I'd pick 120 pixels as my maximum target width. Why? Two reasons. First, smaller images load more quickly and no one, not even users with the bigger screen widths, wants to wait around for your "giant" 300px image to load. Second, while a 120px image will fit inside the greatest majority of SSBs, on larger screens there's sure to be leftover white space which leaves you with a less cramped and desperate design.

It comes down to what images you're using and why. A branded logo? A navigation bar? Added visual oomph? Say you have a 120px logo and an 80px wide set of navigation icons. On a 128px wide SSB, those two items will appear one on top of another, but in a larger (200 pixel plus) screen they'll appear next to each other. Either way, nothing gets resized and your layout stays clean and undistorted by small-screen wraps.

You can steal tips on making small graphics from Emily's super article on how to create the tiny icons you sometimes see in your screen browser's location bar. And, naturally, we have an entire library of other useful graphics articles covering everything from optimizing photographs for the Web to keeping those files sizes slim.

It probably goes without saying that you must use ALT tags, but I'm saying it anyway. Turning off images is a very common practice amongst the regular users of SSBs. When I tried to get a movie time from moviefone's regular website, the submit button graphic didn't have an alt tag and I was forced to load the entire graphics-laden page just to enter my zip code! Oh, the shame.

Suppose you don't want to go through the hassle of making shrunken versions of all your images? Why not specify an alternate stylesheet with a nice "display:none" property affixed to your "img" style? If you're super tricky, you could work some magic with tiny icons that get sized differently, again, in separate style sheets. Obviously this will pixelate anything with a curved edge but it would nicely with simplistic hard-edged GIFs. It's a damn shame scalable vector graphics haven't really caught on because this is their true raison de etre: They're capable of rendering big or small without a single difference in file size. Sigh. A girl can dream, no?

White Noise Versus White Space

By now you're probably asking yourself, what the hell are people doing browsing the Web on all these tiny screens, anyway? For starters, I very much doubt they're doing much casual browsing. I think they're out there doing quite specific things. Whether they're looking for entertainment, news, consulting reference materials or stock prices, buying the occassional last-minute gift, or whatever else it is that we can no longer live without doing 24-7, screen-size be damned, my belief is that small-screen users know exactly what they want and they will become highly discouraged if you place a lot of nonsense between them and their goal.

To put it another way, they are already customers. You don't need to toss them bells and whistles, you don't need to load up links to every branch of your site, you don't need to push anything at them. They're browsing to read the words or order the products or access the information they already trust you to deliver. For this reason, handheld users probably don't care so much about your slick graphics or the FAQs, About Us, and Contact links.

If you're going for a full-fledged CSS media="handheld" approach, why not take a span tag with a display:none out for a whirl, at least for some of the lesser-used navigation links. And keep your words short and sweet. Even the diligent sites already serving up text-only navigation tend to fill their small-screen real estate with two- or three-line navigation text leading to sections of the site handheld users a unlikely to ever visit. Take our tracking tutorial to see which areas of your site have the most traffic.

Think about the size of the white space you might be generating inadvertently. A lot of big-screen sites now use some form of a three column layout (like this very page!), with navigational links in the left and right margins. On a small screen, users would much rather have the text of whatever they're reading fill the space than see text bordered by white space as they scroll downward. Think vertically, not horizontally. And play the percentages. Percentage and relative sizing are your layout friends. It won't help you out with most images but it will help you with things like colored horizontal lines generated from one-pixel GIFs, should you be inclined to use those. And it really comes into play with tables, text line heights, and margin padding.

If you like to inset your paragraph text using CSS, don't set the margins to 30px, set them to 5%. The CSS-compatible SSBs might use those thirty pixels and you'll end up with maybe three words to a text line on a small screen. Whether you're using tables or DIV tags, the same rules apply: Don't set explicit pixel widths if you want your layout to work well on an SSB. If you're spacing your paragraphs or lines with a BR tag, consider instead using CSS to set top or bottom margins to a 1em measurement which will give you padding equal to the height of the paragraph font, whatever that may mean to each SSB.

Say goodbye to tables and frames, and hello to the div tag. Some SSBs will support your table layouts, but they'll resize your cells in so many strange ways that you'll wish they'd just served up a 404. Those that don't support tables (most cell phones) will "unwrap" your tables, listing everything contained therein one after the next without even honoring line breaks for rows. If you're positioning small graphics with tables, your site is guaranteed to look ridiculous on the small screen. Use CSS positioning instead. You'll get better small-screen degradation out of the box, but used with a handheld stylesheet and some display:none codes, you'll have considerable control.

Less is More for More and More

Think minimal links, minimal margins, minimal clicking. One thing I've definitely noticed over the years of wireless surfing (I was an early owner of the unpopular Palm VII) is that I hated having to click around. The main reason for this is that wireless connectivity cuts in and out all the time. While this isn't a problem when you're standing on a busy metropolitan street corner trying to download the address of a restaurant, it's a huge problem for commuters moving around in trains, cars, and buses. News sites in particular should take note of this because it's really vexing when you can't get to page two of an article because you're suddenly out of range. I understand the whole ad-serving business model behind multiple page breaks, but small-screen users find this approach wildly frustrating.

I learned a lot more recently about the small-screen world while surfing with a Sidekick. Like so many of these devices, the Sidekick supposedly supports CSS but in the end it doesn't display anything it doesn't want to. After my initial dismay, I realized this makes for a very pleasant small-screen browsing experience. The enforced minimalism renders websites easier (and faster) to view and navigate than they are within the more full-featured browsers available to Palm, Symbian, or CE users. I don't really get the whole proprietary approach, per se, but cleaning up websites not explicitly designed for small-screen browsing is an intelligent move when you can't count on the designers to have done this for you.

The number of wireless visitors using tiny browsers with ever increasing capacities is unlikely to diminish. (How's that for a safe tech prediction?) In the PDA world, Palm and Handspring dominate the market, outselling all the Windows CE devices combined, making Palm browsers one of the largest subsets of the SSB world. Meanwhile, Symbian is staking out its own growing market share on cellphones using Opera as its best in breed. Novice users surfing the Web with increasingly proxy-free connections and these cutting edge browsers are likely to be turned off from the whole experience until developers start designing sites with their needs in mind.

My documentation rant notwithstanding, I'll close now with a whole slew of links that might be helpful whether you want to create an entirely separate version of your site for the mobile world, code alternate handheld stylesheets, or simply streamline the directions page to your retail store so wireless users can find you while they're driving (not that this seems like a safe trend to encourage, but then again, neither were stock options).

Browsers by Company:
AvantGo
Blackberry Browser (PDF)
Blazer
Netfront
Opera
Palm Web Browser
Pocket Internet Explorer
WebToGo

Phones by Manufacturer (where available):
Ericsson
Handspring
Motorola
Nokia
Samsung

Developer Resources by Service Provider:
AT&T Wiress
Cingular
Sprint PCS
T-Mobile
Verizon Wireless

SDKs and Emulators by Platform:
Blackberry/RIM
Danger/Sidekick
Microsoft
Palm
Symbian

Miscellaneous Useful Style Guides:
AvantGo
Microsoft
Opera
Palm

Other:
Handango software for all handheld platforms. Includes some possibly useful HTML design programs.
Wireless Developer Network
W3C article on "Authoring Challenges for Device Independence"

Heidi Pollock finally left the big city for a quiet country life of dial-up access and frequent power outages. But that hasn't stopped her from being a Webmonkey. Oh no!