How build a mobile web
Over the past few years, mobile web usage has considerably increased to the point that web developers and designers can no longer afford to ignore it. In wealthy countries, the shift is being fueled by faster mobile broadband connections and cheaper data service. However, a large increase has also been seen in developing nations where people have skipped over buying PCs and gone straight to mobile.
Unfortunately, the mobile arena introduces a layer of complexity that can be difficult for developers to accommodate. Mobile development is more than cross-browser, it should be cross-platform. The vast number of mobile devices makes thorough testing a practical impossibility, leaving developers nostalgic for the days when they only had to support legacy browsers.
In addition to supporting different platforms, each device may use any number of mobile web browsers. For instance, an Android user could access your site using the native Android browser, or could have also installed Opera Mini or Firefox Mobile. It’s fine as long as the smartphone uses a progressive web browser (and it’s safe to say that most browsers are progressive nowadays), but it doesn’t have to.
There are several approaches to creating a mobile-friendly web presence. They are usually divided into three ‘types’, each of which provides a different experience for mobile users:
• Responsive: the page – URL, HTML, images, everything – remains the same, but the CSS gives different rules based on browser width.
• RESS/Adaptive/Dynamic Serving: the URL remains the same, but the server sends different HTML and CSS based on what type of device is requesting the page.
• Separate Mobile Site: usually hosted on a sub-domain (e.g. m.domain.com) or sometimes a subfolder (e.g.www.domain.com/mobile), but it can also use the same URLs as the desktop site, and simply serve different HTML (called dynamic serving) to desktop and mobile visitors based on user agent.
If the mobile site uses different URLs, they are often kept parallel with their desktop counterparts (e.g.www.domain.com/first-page and m.domain.com/first-page), which allows for smooth redirects based on user agent. But since it’s a separate set of pages, the options are unlimited. You could choose to have a completely different site structure, in which case the mobile URLs might be necessarily different.
Mobile visitors want to see a version of your site with colors, themes, and content similar to the main site so they can be certain that they’re on the right site. But they expect the actual structure of the page to be fairly different: the screen should really only display one or two elements at a time, rather than the multitude of options we show desktop visitors all at once.
With either method, test the order of the content to see what converts best. You may be surprised at what content is most persuasive to mobile visitors.
If you find that content should be deleted from the mobile version of the site, or should be included on the mobile version of the site but not the desktop version, you can write it into the HTML code but hide it for the device type that shouldn’t see it. But, if this is a significant amount of data, consider a separate mobile site instead.