Like most modern appliances, a lot of people try to keep a computer for as long as they can before upgrading to the latest and greatest. If it still works, why replace it? The problem with this strategy is that technology moves at a very fast past leaving those of us with previously powerful technology in the past in about three years.

Then there are those in rural America who don’t have the luxury known as Broadband Internet. 40% of rural Americans don’t have access to this high-speed Internet access, meaning they’re still using (at best) 56 kbps modem connections. For them, making use of the modern web is just not an option.

As our everyday lives move more onto the web, our slower computers and connections just can’t keep up with newer web technology. But thanks to the popularity of smartphones and their smaller screens, slower processors, and limited Internet speeds, we can use the Mobile Web to our advantage on the Desktop.

Browsing the Web with a Fake ID

In order for us to access mobile web sites on our desktop, we have to do a little bit of lying.

When you visit a web site, information about your web browser is sent to the site. This information is used to ensure your browser will work with their site. It’s also a way to be able to serve a certain version of a site to your browser. This piece of information is called a “user-agent”.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1
Example of a user-agent, used to identify your web browser to a web site.

In the above example, a computer breaks down the information and sees that Macintosh is the platform the operating system is built on, Intel states the processor type, Mac OS X 10_6_8 shows that the operating system is Mac OS X (version 10.6.8), AppleWebKit/535.1 specifies how your web browser interprets (or renders) web pages, and Chrome/13.0.782.112 is the web browser you’re using and its version.

As a web developer, sometimes we need to change this user-agent to simulate using another browser or a different computer platform completely. This allows us to test our sites under certain circumstances. Using this feature meant for developers, we’ll be able to fool web sites into thinking we’re actually a mobile web browser.

Deciding on a Mobile Platform

The mobile web is made up of 5 major platforms: Apple iOS, Google Android, Microsoft Windows Phone 7, RIM Blackberry, and hp (formerly Palm) WebOS. This is then split into two device categories: phones and tablets.

As for the device to emulate, it would be best to use a mobile phone over a tablet. Web sites made for tablets take advantage of more screen real estate which would be typical on a desktop, but, at the same time, web sites take advantage of more screen real estate which would be typical on a desktop.

When browsing the mobile web on a tablet, if a web site sees you’re on a device like the iPad of a Android Honeycomb tablet, it’ll likely serve you the regular desktop version of their web site instead of a optimized mobile version. The thinking here is you have more space on a tablet, so you’ll be able to see their regular site just fine. That’s what we’re trying to get away from. We’re looking to save as much resources as possible and don’t want the full version of a web site.

A mobile phone has a smaller screen size where a mobile-optimized site is needed. As less information can be presented and the device likely accessing the site is on a speed-limited Internet connection, the amount of data needed to be downloaded will be a lot smaller.

How do we decide which mobile platform to use? In this guide, we’ll be focusing on products from two companies: Apple and Google. It would only seem appropriate that we use their mobile platforms as well, iOS and Android. The main reason for this is due to the rendering engine used by these browsers: WebKit. In other words, to ensure the maximum compatibility from mobile to desktop, we need to be sure we keep the way web pages are rendered as similar as possible. Both Apple’s and Google’s desktop and mobile browsers use this WebKit rendering engine to display web pages.

To match these equivalents, we’ll be using the Google Chrome web browser on Windows and its open-source variant Chromium on Linux-based operating systems (such as Ubuntu and Red Hat). Over on the Mac, we’ll be using two different applications: Apple’s built-in web browser Safari and a specialized single-site browser called Fluid.

A Few Quirks

It’s important to note that when using mobile versions of web sites, they’ll mostly made for a touchscreen input method. This means sites may not work as you would expect them. For example, Mobile Twitter requires you to click-and-drag (simulating a tap-hold-and-slide action you would do on a touchscreen) the timeline to scroll through it. Another example is Mobile Gmail, in which pressing the arrow keys won’t scroll through a message but navigate you from one message to another.

These actions will take some time to get use to, but when you’re bandwidth and processor constrained, getting use to this is well worth it compared to endless loading and waiting.

Setting Up the Mobile Web on your Desktop and a Little Experiment

Over the next series of posts, we are going to install these browsers and setup up the mobile web on our desktops. Also, in the coming weeks, I’ll be taking my broadband connection and slowing it down to a 56 kbps modem to get a better understanding of life on the Internet in rural America. I’ll begin by trying to use the web as it is now then transition to the mobile web to see if it’s that much better.