The skinny
Use this:
1
|
|
Introduction
This series of posts is intended to introduce web developers to basic techniques for designing for the mobile web. It assumes at least a basic knowledge of creating desktop websites.
The problem
Ok, so you've settled down to learn how to write a website for a mobile device using your current knowledge of building desktop websites. So you start off with some pretty basic HTML:
<!doctype html>
<html>
<head>
<title>Hello world!</title>
</head>
<body>
<p>Hello world!</p>
</body>
</html>
Ok! You can't get much simpler than that. You check it out and it looks good on all the desktop browsers, since there's really no opportunity yet for any cross-browser inconsistencies. And then you check it out on your mobile device:

Doh! Where'd we go wrong? The text is obviously way too small to read without zooming in.
This is the first lesson in making mobile websites: width is your enemy. This is the first of many countless problems with device width you will encounter. Fair warning.
If you think about it logically, it seems to make sense: mobile Safari took a look at the page and assumed it was a document designed for the desktop, which is true of the vast majority of websites. So it gave the website a width of 980 pixels and presented it zoomed out. Which is why we can't read anything until we zoom into the page.
Viewport
But this is no good! What we need to do is tell the browser that this webpage is optimized for mobile. And this is where the viewport metatag comes into the picture.
Now we tweak our Hello World just a bit…
1 2 3 4 5 6 7 8 9 10 11 12 |
|
And we get this…

Much better! By setting the viewport width equal to “device-width”, we're essentially telling it that the device width is 320px, not the default value of 980px that it guessed. If we set width=320 it would achieve the same result on the iPhone and a few other smartphones, but not all phones have this exact width, so it's best to simply set device-width and let the mobile browser figure it out.
This viewport metatag is supported on many smartphones, from iPhone to Android to webOS (Palm) to even Internet Explorer Mobile, Opera Mini and Opera Mobile.
At the end of the day here's what the standard viewport looks like, as grabbed from m.yahoo.com:
1
|
|
EDIT: It's been discussed a bit, and it seems that preventing the user from scaling the page (pinch zooming) isn't necessarily desirable. So here's a version of the tag that allows the user to pinch zoom:
1
|
|
More fun with the viewport tag
In addition to solving our biggest concern with the width of the content, the viewport tag has more options to play with:
Property | Description |
width | Width of the viewport in pixels (or device-width). If width isn't set, it defaults to a desktop size (980px on mobile Safari). |
height | Height of the viewport in pixels (or device-height). Generally you don't need to worry about setting this property. |
initial-scale | (0 to 10.0) Multiplier that sets the scale of the page after its initial display. Safe bet: if you need to set it, set it to 1.0. Larger values = zoomed in, smaller values = zoomed out |
minimum-scale | (0 to 10.0) The minimum multiplier the user can "zoom out" to. Defaults to 0.25 on mobile Safari. |
maximum-scale | (0 to 10.0) The minimum multiplier the user can "zoom in" to. Defaults to 1.6 on mobile Safari. |
user-scalable | (yes/no) Whether to allow a user from scaling in/out (zooming in/out). Default to "yes" on mobile Safari. |
Feature phones: when viewport isn't available…
Note: this info is now very outdated and is preserved here just for historical reference. In general, you can ignore this stuff these days.
Unfortunately the viewport tag is relatively new and as such isn't universally supported, especially if you're working on older feature phones. But there are some older methods at your disposal for identifying your website as optimized for mobile:
1
|
|
This tag was originally used to identify mobile content in AvantGo browsers, but has now been made the general standard for identifying mobile websites. However, it's unknown what range of browsers support this meta tag.
Another tag at your disposal is a Windows-proprietary meta tag that also took root and eventually became used as another means of identifying mobile content. The drawback with this tag is that a specific width must be given, which doesn't make it as flexible as the viewport tag (see above). Again, it's unknown what the support for this tag is:
1
|
|
Lastly, your website will be identified as a mobile optimized site if your doctype is either XHTML-MP or WML. However, this is becoming less and less the case these days, as browsers begin to support good old HTML4.01 and HTML5+.
(info for this section comes from Beginning Smartphone Web Development)
Custom Android properties
The official Android documentation lists a special property they've added to the meta tag: target-densitydpi. This property essentially allows developers to specify which screen resolution the page has been developed for, or more specifically how to handle the scaling of media such as images.
Here's an example of the tag in action:
1
|
|
References
Safari HTML Reference: Supported Meta Tags
Mobile META Tags
The Mobile Developer’s Toolkit (Mobile Web Part 2)
Tools of the trade
You're no mobile developer unless you have the tools to develop on mobile! And while it's good to own at least one of the smartphones you're developing on, it's probably unrealistic to think that you're going to go out of your way to buy several other unlocked smartphones just to test with. So you should have the next best thing: an SDK!
But an SDK is just one of the tools of the trade. Here's links to more things to get you started!
SDKs, Emulators and Simulators
Short of having access to a real phone, the next best thing is to have an emulator/simulator. And good news: all the major smartphones have SDKs available for you!
iPhone SDK (Mac OS X only) – the quintessential SDK for the quintessential smartphone. Includes iPhone simulator.
Android SDK (Mac OS X, Windows, and Linux)
Palm webOS SDK (Mac OS X, Windows, and Linux) – emulator for Palm Pre, Pixi, etc. Also check out Ares, the browser-based tool for creating web apps.
Firefox Mobile emulator (aka Fennec) – mobile version of Firefox being developed for new Nokias and soon Androids
Opera Mobile emulator – this is the fastest emulator of the bunch, in terms of downloading and launching the program. Painless installation.
Opera Mini Simulator (Browser-based Java applet) – In-browser simulator. Note that Opera Mini is different than Opera Mobile.
Windows Phone 7 Series emulator
For a more complete list, see Maximiliano Firtman's Mobile Emulators & Simulators: The Ultimate Guide
Device labs
These are services which allow you to test on actual devices in a lab.
Keynote MITE (Mobile Interactive Testing Environment) (Windows only) – a glorified user agent switcher. Doesn't have testing of real devices.
DeviceAnywhere (Java-based software that runs on Windows and Mac OSX) – a service that lets you test on actual mobile devices sitting in labs around the world. It has a tendency to be a bit clunky, but there's no real alternatives on the market. Only subscribe to this if you intend on supporting more than just smartphones.
Mobile JavaScript libraries
I've created a separate entry for the mobile libraries and frameworks now available.
Hybrid (web + native)
The concept is simple: use what you know to create an app with HTML/CSS/JS and turn it into a marketable native app with one of these “wrapper” services.
PhoneGap
appcelerator's Titanium Mobile
QuickConnectFamily
Rhomobile (HTML-based)
User agent switchers
Many websites sniff a browser's user agent to detect if it's a mobile device. As a developer this presents a challenge, because a lot of development is done on a desktop browser. With a user agent switcher, a developer can masquerade their desktop browser as a mobile browser.
Firefox addon: User Agent Switcher
Safari: Enable the Develop toolbar (click on Safari -> Preferences -> Advanced) and click on Develop -> User Agent. Select a predefined user agent or enter a custom agent by selecting “Other…”
Chrome: There is no easy way to do this (note that the one user agent switcher extension for Chrome doesn't work). Currently the only way is to set command line flags:
To change the user agent of Chrome in Windows:
- Make a copy of the shortcut to Chrome.
- Right click the copy and select Properties.
- In the Target field append ––user-agent=”myagent”
Example Target: “C:\Documents and Settings\Username\Local Settings\Application Data\Google\Chrome\Application\chrome.exe” ––user-agent=”Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”
To change the user agent of Chrome in Mac OSX:
- Open Terminal
- Enter the following into terminal: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome ––user-agent=”myagent”
Example command: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome ––user-agent=”Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”
Mobile detection
On the server side, mobile detection is mostly done by user agent sniffing (thus the need for the user agent switchers above), but there are a few other methods.
“Lite” user agent detection: these methods implement a simple server-side function (commonly in PHP) to detect common mobile user agents. There's a few versions, mostly based on code by Andy Moore. There's one implemented in the WordPress Mobile Pack and a similar one described on the Nokia developer forums.
WURFL (Wireless Universal Resource File) – a 10+ year old project that is still being used and gaining momentum. It's beneficial because it's open source and it offers a lot of valuable information about devices.
DeviceAtlas – essentially a commercial version of WURFL
Reporting bugs
Everybody's human. All this new cutting-edge stuff isn't exactly bug-free. Help squash bugs by reporting them on the project's website. For best results, show a simplified example of the bug in action (try not to post big hunks of code!).
WebKit Bugzilla
Android: Report bugs
Blogs
Keep up to date! There's new stuff happening all the time on the mobile web.
QuirksBlog – blog of Peter-Paul Koch (PPK), who is known for documenting and researching cross-browser inconsistencies. As of the last several years he's been focusing on documenting mobile browser bugs.
Daring Fireball – John Gruber's blog with a cultlike following. Frequently reports on mobile happenings, especially stuff relating to Apple.
Surfin' Safari – The WebKit Blog
Android Developers blog
IE for Windows Phone Team Weblog
Opera Mobile Blog
Inside BlackBerry – The Official BlackBerry Blog
Yahoo! Mobile Blog
Google Mobile Blog
Miscellaneous
Yahoo! Blueprint – framework for normalizing cross-browser issues across thousands of devices
Designing Buttons That Don’t Suck (Mobile Web Part 3)
A button is something that seems to be made just for mobile: it's designed to be big and easy to activate, as opposed to small and harder to activate, like normal text links. This seems ideal for a mobile devices, which have a small display area and whose form of input is a person's (relatively) fat finger interacting with the screen. Contrast this with the desktop, where the display area is much larger and the input device, the mouse, is a much more highly refined and sensitive pointing device.
But you probably don't want to make everything into a button. After all, there's still a place for good old fashioned anchor tags. So what do you make into a button? Simple: areas of your website that get frequent usage. For instance, [mobile.twitter.com][1] has buttons for Search, Refresh results, and More (display more tweets), but leaves other things as anchors/hyperlinks, such as usernames and links in tweets. Basically, use common sense. You should have a mixture of both buttons and hyperlinks.
There's a distinction to be made between form input buttons and other things that look like buttons. The former occurs within a Form tag and can be used to submit a form of data when clicked (and you can [style it up all you want][2]!). The latter is simply an Anchor tag disguised as a big clickable button, which is the focus of this article.
A button can be a very useful thing, and can make the user experience much much better. Yet it's surprisingly easy to fail to create a proper button.
How to fail at creating a button
See if you can tell the difference between these two buttons: