This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.
There is no separate “mobile HTML”.
Mobile sites are normal HTML sites. Separate WAP protocol has been dead several years now. “XHTML mobile profile” is also dead. Most phones do normal HTML just fine.
Also in developing countries, where the usage of mobile Internet is more prevalent over desktop internet and the device base is geared toward feature phones with less powerful web browsers, thin client browsers like Opera Mini are widely used and support normal HTML just fine.
The major web experience considerations on mobile phones are not technical, in protocol wise. They include
- Small screen estate
- Lack of physical keyboard
- Touch screen instead of mouse as a pointer device
Smartphones like iPhone, Android and Blackberry devices support new HTML5 and CSS3 features and in some cases mobile browsers are more advantaged than their desktop counter-parts. Even if you don’t like Apple as a company per se, they have done a great deal to push HTML5 forward in mobile space and taken the mobile browsing user experience from old, clumsy, WAP era to something you can actually enjoy.
1. There is no HTML5; there is only HTML
There never will be a finalized HTML5 standard and asking the question when HTML5 is ready is pointless. Browser vendors keep adapting evolving HTML features to their browsers continuously and it is up to feature detection and graceful fallbacks to determine whether you can do the trick with the browser or not.
In mobile space HTML5 features provide enhancements making the surfing experience better
- Specialized input fields for better text input on non-hardware keyboards
- Using CSS3 styles instead of images for layout effects; this reduces HTTP transfer payload making pages load faster
- Touch event support
- <video> and <audio> multimedia (as oppose to Flash)
2. Strategies for building a mobile site
There are several options for “mobile strategy” of your site
- Responsive layout, as described in this tutorial
- Using a stock mobile theme or add-on for open source CMS (Web and Mobile, WPTouch)
- A theming HTML proxy, like Diazo, is an option when you cannot touch the front-end template source code at all. A theming proxy reads web HTML, parses it and transforms the result to new mobile HTML output based on (XSLT) rules
- A commercial scraper which is a theming proxy with fancy UI e.g. Mobify.me
- Have a separately maintained mobile site, using mobile specific CMS with information duplicated by hand or using a custom integration. Suits for large organizations where the marketing budget is big and internal communications are an issue.
What strategy you should use depends on your IT skill, organization structure and business goals. You need to balance between the wanted user experience level, budget and available competence.
3. Tools for mobile site building
Since mobile sites are normal HTML there is no need to have specific “mobile SDK” or “mobile IDE”.
4. Spoofing the development browser as mobile
When mobilizing a web site with responsive design, the only trick you usually need to pull is to shortcut the responsive CSS loading so that the development browser loads the mobile stylesheets.
You can do this in your own code level: instead of selectively load mobile.css file force it to be loaded in the desktop browser too by hardcoding mobile.css to be loaded for all browsers.
You could include a server-side conditions which allow you to perform the spoofing using an URL parameter:
Note: It is not worth of doing mobile development using Internet Explorer as the development browser. Microsoft has recently improved their track record regarding open web standards, but they still have few years catch up to do in order to be able to match the pace of the competition.
5. User agent detection
User agent is a HTTP request header which the web browser uses to tell the web server the software version the web browser is running.
User agent detection is a method of discriminating mobile devices on the server-side and serving them a different HTML payload. I strongly discourage using this old and deprecated method of mobilization in the contemporary world unless you really really have to.
- User agent detection is fragile, because the user agent strings themselves are a mess and different devices may have the same user agent or the same devices different user agent: false positives ensure
- You need to maintain a server-side database of devices and the quality of available databases leaves room for improvement
- Different HTML payloads varying by user agents destroy front-end caching performance, as there are thousands of device types and each would create its own front-end caching entry
- It seems that widely spread, semi-open, device database project Wurlf is alienating its users
6. Native apps
A native application is nowadays almost synonym for “embedded WebKit” – unless you are doing some really high profile applications. The apps are out of the scope of this tutorial.
If you need to wrap your mobile site for App Store, Android Market, etc. distribution you can use PhoneGap. The user experience is not as great as building expensive 100% native application from the scratch, but the price tag is usually something you can swallow easier.