Making iPad Work

I continue to cope without internet access for my desktop computer - for just another few hours, I hope - relying instead on my iPad's 3G connection. As I posted previously, I'm finding the iPad to be a poor replacement for a notebook computer for anything beyond the simplest of tasks (email and web browsing), and its limitations are glaring in some areas.

But I'm also finding that not all the problems are the fault of the device. Some of them are due to poor website design/development decisions. I've found a workaround to most of these situations (more about that in a moment), but it's annoying that I had to go to those lengths.

If you have a smartphone, you're probably accustomed to seeing so-called mobile versions of the websites you visit. This is generally a good practice, as those sites load more quickly, optimize the use of the limited screen space, and eliminate features that don't work in mobile browsers (e.g. Flash in mobile Safari). Unfortunately, this has created a new set of problems for a device like the iPad which falls into the gap between a smartphone and a full-featured/full-sized notebook or desktop computer.

This is partially Apple's fault, because its iPad version of Safari delivers a user-agent string that identifies the browser as "mobile." When a website that offers a mobile version queries that user-agent string, it will usually send the iPad to that stripped-down version, even though the device can easily handle the full version (or most of it, anyway). This behavior is often frustrating for the iPad user, especially if he or she needs the full functionality of the website for business purposes.

I have two examples. First is my webmail. When I access it via the iPad, I get the mobile version of the webmail program (in my case, it's an application called Horde). The mobile version lacks many of the mail management features of the full version. For example, I can't delete messages from the server using the mobile version.

The second example is the website I'm using to create this post. In mobile Safari, Movable Type (my blog platform) automatically delivers a barebones post creation page that basically allows me to type in text and that's about it. I have no formatting options, no control over publishing (e.g. time and date), etc. Movable Type apparently decided that those options were not important to smartphone users, but the iPad could easily take advantage of all of them. Unfortunately, we don't get to choose the version, because there's no option to force delivery of the full version of the website.

I mentioned above that I've found a workaround, and it's a pretty good one (so far, anyway). I download the Atomic Web Browser from Apple's App Store (a $.99 purchase) and this browser allows you to change the user-agent string to, in effect, impersonate the desktop version of Safari. This means that I'm being served the full version of a website, rather than the stripped-down mobile version. This has its own set of problems (if a site is built in Flash, then I'm out of luck) but it does solve the above-mentioned problems. Plus, it's a pretty good browser in its own right, incorporating tabs, View Source, multiple search engine options, ad blocker, and much more. Some have reported that it's buggy, but I haven't yet encountered any problems.

But web designers and developers need to deal with the real issue of figuring out how to serve up non-crippled versions of their websites to iPad users (and, really, even to legitimate mobile browsers). Mobile versions shouldn't lack important functionality in order to achieve simplicity. That borders on laziness. At the very least, the mobile version should provide the option of navigating back to the full version (Sports Illustrated is a good example of a website doing just that).

2 Comments

I'll have to try the Atomic Web Browser. I too get frustrated with how some websites display on my iPad. Of note: For the last week or so Fire Ant actually crashes Safari on my iPad. I am sure it is some setting on my iPad that a proper geek could figure out.

About this Entry

This page contains a single entry by Eric published on November 18, 2010 9:24 AM.

Programming Note - Part 2 was the previous entry in this blog.

Increasing the odds of getting a lost iDevice returned is the next entry in this blog.

Archives Index