This chapter is from the book
This chapter is from the book
This chapter is from the book
Writing Mobile Websites
In some ways, writing websites for mobile devices is a lot easier than it used to be. Although a lot more devices are out there, including smartphones and not-so-smart phones, tablets, internet TV devices, and even some picture frames, the devices are converging in what HTML5 features they support, and even in their sizes and shapes (to some extent).
When you’re creating a mobile website, the first thing to remember is that a mobile website is just a website. The best websites are built for every browser and operating system, or as many as possible.
However, you should still consider some basic questions when building a website that is intended for mobile devices:
- What is the screen size and resolution of the mobile device?
- What content do your mobile users need?
- Is your HTML, CSS, and JavaScript valid and compact?
- Should your site have a separate domain for mobile users?
- What testing does your mobile site need?
What is the Screen Size and Resolution of the Mobile Device
When you’re working with mobile devices, obviously the screen size is going to be smaller than on a desktop. In general, with smartphones, you have to prepare for a few standard sizes:
- 128 × 160 pixels—Phones such as the Fujitsu DoCoMo F504i
- 176 × 220 pixels—Phones such as the HP iPAQ 510
- 240 × 320 pixels—Smartphones such as Blackberry 8100 or the HTC Elf
- 320 × 480 pixels—PDAs such as the Garmin-AsusA50 or the Palm Pre
Tablets add to the mix by having not only an increased screen size, but also having a variation in how they can be viewed. For example, most tablets (and some smartphones for that matter) can be viewed in portrait or landscape mode. This means that sometimes you might have a 1024-pixels-wide screen to work with, and other times 800 pixels wide or less.
However, in general, the tablets provide a lot more screen space for you to play with on mobile devices. You can assume you have around 1024–1280 pixels by 600–800 pixels for most tablet devices.
Browsing most websites in their standard format on an iPad is easy because the browser is as clear and easy to use as on a computer monitor. Plus, with the zooming capabilities on both iOs and Android, making small, harder-to-read areas bigger is easy.
What Content Do Your Mobile Users Need?
When you are designing a site for mobile devices, remember that users don’t always want to access the same content as someone browsing on a desktop.
For example, mobile customers are often, well, mobile. In other words, they may be in motion or away from their home or office and have a very specific need or desire when they visit your site. For example, when visiting a restaurant website on a mobile phone, a user riding in a car might need to quickly find the location of the restaurant and the phone number. If the mobile site doesn’t have the phone number and location front-and-center, the user might quickly give up on the site.
Content for mobile sites shouldn’t be limited, however. In fact, the W3C recommends “...making, as far as is reasonable, the same information and services available to users irrespective of the device they are using.”1
This doesn’t mean that you can’t change the format or location of your content, but getting to the same content on a mobile device as on a computer should be possible.
Is Your HTML, CSS, and JavaScript Valid and Compact?
You don’t have to worry about writing well-formed XHTML for mobile devices, but sticking to correct, standards-based HTML, CSS, and JavaScript ensures that your pages are visible by the largest number of devices. Plus, by validating your HTML, you will know it is correct.
Beyond writing valid HTML, you should consider avoiding a few things if you are writing web pages for mobile devices:
- HTML tables—Avoiding tables as much as you can in mobile layouts is best because of the small size of the screen. Scrolling horizontally is difficult and makes the tables hard to read.
- HTML tables for layout—You shouldn’t use HTML tables for layout of web pages in general, but on mobile devices they can make the pages load slower and look bad, especially if the table doesn’t fit in the browser window. Plus, when you use tables for layout, you almost always use nested tables, which make the pages load slower and are much more difficult for mobile devices to render.
- Pop-up windows—Pop-up windows are often annoying in general, but on mobile devices they can make the site unusable. Some mobile browsers don’t support them and others open them in unexpected ways (often by closing the current window to open a new one).
- Graphics for layout—Like using tables for layout, adding invisible graphics to add spaces and affect layout typically make many older mobile devices choke or display the page incorrectly. Plus, they add to the download time.
- Frames and image maps—Many mobile devices don’t support these features in HTML. In fact, HTML5 no longer includes frames (other than the iframe) as a part of the specification because of the usability issues involved.
Also remember that mobile users often have to pay a fee for their bandwidth, so your web pages should be as small (in KB) as you can make them. The fewer HTML tags and CSS properties you use and server requests you make, the better browsing will be for mobile users.
Should Your Site Have a Separate Domain for Mobile Users?
Many websites have a separate subdomain for their mobile site. This makes finding the mobile site without having to bother with the regular domain easy for mobile users. These domains are typically something like m.example.com.
Having a separate mobile domain offers several advantages:
- It makes your mobile site easier to find.
- You can advertise the mobile URL separately from the normal URL, giving you more reach.
- Having a separate mobile domain enables people on tablets or smartphones to switch to the full site just by switching domains.
- Detecting mobile users and sending them to a separate domain is much easier than scripting changes to your CSS for mobile users.
When trying to decide how to handle your mobile site version, consider how you are going to maintain the site. You can create the mobile domain manually with completely separate pages, or you can use a content management system. Hour 4, “Detecting Mobile Devices and HTML5 Support,” covers this topic in more detail.
What Testing Does Your Mobile Site Need?
Be prepared to test your site on as many mobile devices as you possibly can. Although you can use your browser to test or emulate things such as screen size, you won’t see some of the horrible things that can go wrong if you don’t test on mobile devices directly, such as the following:
- Packet size limitations by mobile carriers preventing your page or images from loading
- Images loading incorrectly or not at all
- Inability to scroll horizontally (which is nearly impossible to do on some phones)
- Device-specific features not working that you were relying on
- File formats not being supported
You likely don’t have an unlimited budget for buying mobile phones (and their associated cellphone plans), so what do you do? Here are some suggestions:
- Use emulators—Both online and offline emulators are available for many different mobile devices. Most are free to use and they give you at least a start at testing your site for mobile devices.
- Rent time on devices—Services exist that will allow you to rent time on multiple phones. You can justify the cost by getting a sense of how the phones handle your applications.
- Buy some phones—This might seem like an expensive option, but if you are planning on doing a lot of mobile web development, it could be a reasonable investment.
- Get help from friends and co-workers—This is one of the least expensive ways to test your site—simply ask to borrow phones or tablets from people you know. You just need to put your site on a live web server.
Ultimately, if you are going to do mobile development, you should have at least one mobile device you can test your pages on directly. The more devices you can test on, the better your sites will be.