5 Sure Fire Ways to Break Your Site in iPhone's Mobile Safari

Apple promises the full Internet on the iPhone. Not a cut down, mobile version like on other devices. It’s a bold statement, one that has already got them in hot water with the British ASA (Advertising Standards Authority). As a heavy user of the iPhone, I’d say that Apple comes as close to offering the full Internet experience on a mobile device as anyone. In fact, out of the numerous mobile devices I’ve used, the iPhone is head and shoulders above the rest.

However, there are still sites that don’t work. But what are these sites doing so wrong? Are they bad sites? And does the fault lie with the iPhone and Apple, or the sites themselves? In this post, I’ll list the five most common problems I’ve come across when using the iPhone to browse the web, and ways around them.

Flash

By far the biggest hurdle (but not the most common, see below) that needs to be overcome is Flash. Not only is it popular and used for a variety of uses, but many sites use only Flash. This renders them inaccessible on the iPhone. The two biggest offenders are those sites that use Flash for navigation and those sites that use Flash for media. In the grand scheme of things, navigation is the biggest problem, if a site uses Flash for it’s primary navigation it is basically useless on the iPhone. Multimedia is less of an issue as it often provides only supplementary content. It’s worth remembering that text replacement tools like sIFR use flash and can also cause problems if not implemented with due care. Although sIFR itself should be OK so long as it is implemented correctly.

To avoid problems with iPhone users, sites should avoid using Flash.  If you are hosting multimedia content, then use a well supported format and codec (e.g. .h264).  If you are using Flash for navigation, then more fool you.  Switch to XHTML and CSS and become accessible to everyone.  If the use of Flash is unavoidable, then following the WCAG guidelines is a good place to start when thinking about not only making your site accessible to Mobile Safari users but also those with disabilities and impairments.  Provide an alternative version of the site, or at least the content in question, and clearly link to it.

Applets

Along with Flash, the ASA singled out Java applet support, or lack thereof, as one of the reasons for banning the iPhone 3g advert.  Fortunately, Applets aren’t as big a part of the Internet as they once were.  You no longer have to regularly block MS Java and Active X applets at every turn.  However, they still exist.  So if you are thinking about adding some functionality to a site, and someone suggests using an applet, consider whether the same thing could be done in Javascript for example, just to give iPhone, and other mobile web users, a chance.

Fixed Footers

I’ve been keeping an eye out for a new job recently, this involves trawling the popular job sites for things that may be of interest to me. However one of the biggest sites out there, Monster, is effectively unusable on the iPhone.  The image to the left is a screen shot of Monster.co.uk as seen through Mobile Safari.  As you can see, there is a bar fixed on the bottom of the screen that sits out of line with the rest of the text.  If the same page is visited in  desktop browser, the bar stays fixed to the bottom of the browser view port even after the page has been scrolled.  In Mobile Safari, you simply cannot scroll the page.  If you do try to scroll the page, the entire viewable area moves and then snaps back into place, the same behaviour as is seen when you reach the bottom of a normal page.  Apparently, Monster doesn’t want to target the iPhone using demographic.  Odd that, because most recruiters bend over backwards to explicitly target the educated, fairly well paid, technologically savvy people in their 20s and 30s.

This may be a bug in Mobile Safari, but quite frankly this is a horrible idea from a usability point of view even when it works, so the blame should lie squarely in the laps of Monster.  People don’t expect elements to move with the page, and anything constantly position at the bottom of the view port, such as this, will surely be considered by most users to be part of the browser and promptly ignored.  Probably not the effect Monster were after.

Quite frankly, the fixed footer, and in fact any elements on a page that necessarily follow the user as they scroll, should be dumped.  Not just for the benefit of iPhone users, but for the good of everyone.

Drag and Drop

We’re (unfortunately) seeing more and more implementations in web applications of drag and drop functionality. Again, like fixed rooters I have a general usability issue with drag and drop on the web, in most cases. It’s not an interface feature people expect to see on the web, and as such it has to be treated with great care. On the iPhone, the technique you would use for dragging and dropping is used to position the Safari viewing area, so using the same interface method for something else just isn’t possible, and if it was it would be hugely confusing. Again, the solution (in my opinion) doesn’t just benefit iPhone users, but everyone, and the solution is to find a better way of performing that task in your web application.

Hover Behaviour

The last, and most common, problem with Mobile Safari comes from sites that use hover elements for various effects.  When you are using an iPhone, you do tend to notice how many sites use hover effects and how many different implementations and uses there are out there.  Take Flickr for example.  Often heralded as the way to gradually reveal a complicated set of features to users through exploration.  They highlight certain areas of pages when you mouse over them and give you instructions.  See the screen shot below taken from my Flickr photostream.

As you can see, the title on the left is highlighted in yellow when I mouse over it to indicate it is editable.  If I leave my mouse there for long enough, it also provides a tool-tip.  It is not possible to get this information on an iPhone because you can’t hover over anything.  And it doesn’t stop at Flickr, there are sites that use hover behaviour for expandable navigation menus, to show information that is not accessible in any other way and to provide extra features.

There are two ways to avoid this problem on your site.  Firstly, you can avoid using hover behaviour.  Secondly, you can carefully describe that hover behaviour exists (which you should be doing anyway, as it’s not a standard interface method on the web) and making sure your coding is robust enough to handle clicking as well as hovering.  For example, if you have a navigation list that expands when the user hovers their mouse over it, make sure it also expands when they click it.

Bonus! Write bad code

Mobile Safari manages to provide the “Full Web Experience” by allowing users to zoom in and out of pages to examine different levels of detail far easier than any other device.  It does this by intelligently determining the area of the site the user wants to view when they try to zoom in.  It does this by examining the structure of the page to pick out block elements.  For this to work, your site must be at least fairly well structured.  So make sure your lists, paragraphs and headings are correctly marked up, just to make the iPhone’s life that little easier.

Anything to add?

Do you have anything to add to this list? Is there anything I’ve missed out?  I have noticed certain sites being really slow and unresponsive on the iPhone, notably the BBC News homepage.  I believe this is because of the unnecessary news ticker they have at the top of the screen.  What do you think?