Choose a Great Domain Name
As you build the mobile version of your site, you’ll need to decide upon the domain by which users will access it, and work out how to advertise the fact that it exists. There are several options for choosing a mobile domain. Let’s explore each of them.
1. Use a separate domain altogether (e.g. www.example-mobile.com).
Creating a separate domain has never been necessary for any of the sites I’ve worked on. A separate domain name can hurt your site’s overall branding and can confuse users — how many people will actually remember both the URL for your traditional web site and your mobile version? And which site should you promote in your advertising? Such an approach can end up being a hassle, and is therefore not recommended.
Use a subdomain (e.g. m.example.com).
Creating a subdomain is probably the most popular option. Using a subdomain (such as mobile, or just m to keep it short) keeps your mobile site part of your brand without creating confusion. Obviously, if it suits your customers, you might want to localize the term ‘mobile’. And if adding ‘m’ to the start of your domain name spells something horrible, you might consider placing the mobile element at the end of your URL (e.g.http://example.com/mobile/).
Either way, you should assume that people will get the address of your mobile site wrong. Anticipate this eventuality by setting up several different common subdomains — m, mobile and others — and redirecting them all to a single mobile site, just as you should redirect typos like ww and wwww for your traditional web site to www.
Use a .mobi top level domain (e.g. example.mobi).
The question of registering a .mobi TLD has been the cause of heated debate among web developers ever since the availability of .mobi domains was announced. Personally, I’ve never used a .mobi domain for any of the projects I’ve worked on, but this decision may come down to a personal preference. If you have a few hours to kill, a quick search will provide you with plenty of information about the pros and cons of using a .mobi domain.
Do nothing, and let the server send the best page based on the user agent.
Performing user agent detection is perhaps the most interesting option from a developer’s point of view. It’s also the most elegant from a user’s point of view, but unfortunately it’s the approach that’s most prone to issues.
Here’s how it works: when a user visits the site example.com, the server looks at the visitor’s user agent and tries to detect if the visitor’s using a mobile device or a desktop browser. Given that information, the server will send the most appropriate page for that user agent. The beauty of this approach is that it allows you to use a single URL, which anyone can use with any device. Whether they’re on computers or mobile devices, all users will magically view the version of the site that is best optimized for them. When it’s done well, this can be great solution. But when it’s done poorly, it can be a disaster.
The second option that we discussed (using a subdomain) has one other advantage: a user browsing with a high-end device might first visit the mobile site, then realize that this site doesn’t contain the information he or she wants. The user then has the option of navigating the traditional web site to locate the information. The user experience might not be optimized, but the user should still be able to find the desired information.
With user agent detection, however, there’s only one URL, and therefore only one version of the site that can be returned to that device. The customer can’t choose the version to view — even if he or she is capable of viewing the site. If you plan on performing user agent detection, you’ll need to allow for exceptions so that devices can override the detection process in order to view a specific version of the site. As you can see, if you head down this road, things can get very messy, very quickly.
When you’re deciding on a domain name for a mobile site, the colleagues and companies I’ve worked with have always chosen option #2. Creating a subdomain is the easiest of the options to set up (you already own the domain), it’s the cheapest option (there’s no need to register the .mobi), and it means that you avoid having to spend hours tweaking the server (and potentially messing up normal traffic). The end result is a sandboxed subdomain built specifically for mobile devices. And if traffic numbers are not what you expect (for better or worse), a subdomain gives you the flexibility to grow or scale back the mobile site without impacting on the traditional web site
Validate Your Markup
Desktop browsers can be quite forgiving. A few misplaced HTML tags here and there will, more often than not, be fixed on the fly so that your page is rendered correctly. However, the “smarts” built into desktop browsers in order to perform this error handling equate to more code, which means a bigger install and more processing power.
Mobile browsers, on the other hand, are much less forgiving. A browser running on a mobile device generally won’t have the luxury of a 2 GHz processor and 100MB of disk space. Therefore, you must check, validate, and recheck your markup, time and time again.
Much of the checking and validation of a mobile web site can be done through a normal desktop browser. If you’re developing in XHTML, for example, you can reuse all of the same tools that you use to validate traditional sites:
- The W3C validator can be used to find simple markup errors — there’s even a mobile-specific version.
- The Ready.mobi site lists a few additional mobile specific checks.
You’ll notice at this point that we haven’t yet discussed checking to see if the mobile site works correctly on a mobile device. Once you’ve received the green light from several validators, you’ll need to get a few different types of phones to perform some actual tests.
Test, Test, TEST!
Testing your site with a web browser on a desktop computer can only get you so far in terms of simulating the mobile experience. There are many elements of mobile device usage that can’t be replicated accurately in this way. For example, a mobile operator might restrict packet sizes to something smaller than you expected, and therefore won’t even send your web page or its images! Additionally, content mime types could be an issue between browsers — are you serving the pages with the correct text/html or application/xml+xhtml? What kind of image formats can the phone display?
Due to the small footprint in memory and on disk, mobile browsers are not as robust as desktop browsers, so the best advice is test, test, test! Granted, not everyone can afford to test on every phone that’s available on the market, but there are alternatives:
1. Emulators
There are plenty of online emulators and offline emulators that allow you to quickly see images in context and the general layout, but they’re not real devices, and therefore they have their own quirks and differences. These tools can act as a good first pass to find common issues. Also, they’re free to use, so there’s no reason to not have a peek in an emulator, but you can’t call a site viewed on an emulator “tested”.
2. Rent Time
Renting time is another option. There are services that allow you to upload or view the content one multiple phones in real time. You control the different phone’s features remotely. This service does cost money, but it’s still cheaper than purchasing lots of different phones. For a basic mobile web site, this service probably isn’t needed.
3. Buy a Handful of Phones
Buying a small subset or representative phones is a possibility. If you’re planning on doing more mobile development, spending a little money up front can really help. You probably need to purchase 5 or 6 phones representing the major brands and types.
You’ll need some sort of Windows smart phone — we test on an HTC Mogul PPS-6800 using Internet Explorer on Windows CE, which gives a representative coverage for all Windows Mobile devices. You’ll also need a Nokia model phone. We test on a Nokia 6600 running Symbian Series 6 OS and the built-in Services and optional Opera browsers. You’ll need a Sony Ericsson phone. The model we use is a T630, which covers Sony’s Internet Services. Lastly, you should test in whatever model is most popular in your audience. You do not need these exact phones, but these types of devices will allow you to quickly see the minor differences in the phone browsers and cover the majority of potential customers.
4. Ask Your Friends
Finally, you can simply ask your friends. We all know at east 5 or 6 co-workers or colleagues who would happily lend us their phone for a couple of minutes. Once you’ve tested your web site with the online emulators and validators, test it on the borrowed mobile phones. The pre-tests should have fixed all but the issues that are specific to each phone. Take notes, make corrections, and test again, and again — and again! — until you’re satisfied.
Depending on your budget, one of those options will suit you. Spending just a little time and money really can go a long way — especially if this is your first mobile web site. Getting your test suite right will allow you to find common issues, while helping you to build a library of working HTML, CSS, and JavaScript code that’s known to be tested and can be reused in future projects.