In the process of creating the new Ribit web site-as well as my own personal site-I had occasion to test the site out on an iPad. Browsing on an iPhone/Pad/Pod (hereafter referred to as an iProduct) is very intuitive and easy, but also very different from what we are used to on a desktop or laptop PC. Contrary to what some might think, the iProduct multi-touch interface does not merely substitute touching for clicking, and our usual instinct of viewing a page and vertically scrolling to the next page or section of content doesn’t always serve us well. Viewing a web page on an iProduct is more akin to looking at a menu of items available for perusal. When you first visit a site, you see the entire front page. If this page has a lot of stuff on it, you will see a tall vertical strip of content, all of which is far too small to actually be read or viewed effectively. Tapping an area automatically zooms the screen to that area of content, bringing it into focus and making it readable. Tapping again zooms back out to the full page, touching and sweeping your fingers around allows you to freely pan (I don’t like to call it scrolling, it doesn’t feel anything like scrolling on a normal PC) in any direction. All very intuitive and very, very cool, but as I discovered, this and other aspects of the multi-touch interface have some consequences for web design.
First if all, there is navigation of pages. We are used to point and click; an iProduct gives us touch. Easy enough, but when designing, one has to remember that a human finger is not as precise and pointy as a mouse cursor. Navigation elements on a site need to be large, and have more space between them, to make browsing your site on an iProduct a good experience. Another thing to remember is that there is no such thing as mouse-hover or mouseover on an iProduct. The cursor does not exist when the screen is not touched, and so many of the event handlers web designers use to highlight things like navigation buttons simply won’t work. With this in mind, navigation needs to be made very clear. A link, whether it be text or a graphic button, needs to very obviously be a link. Along with rollover states for navigation, drop down menus are problematic on an iProduct. Apple has given us the functionality by invoking the normal mouse-over event when touching on a navigation element that triggers a drop down, but unless your site is extremely large I would highly recommend doing away with hierarchical drop downs in your site menus. One touch per step to the destination should be the rule, as far as it is possible.
Another interesting thing I discovered is that certain CSS properties that work perfectly fine in Safari on a desktop computer are ignored on an iProduct. The most important of these I found are fixed elements such as DIV tags with a position:fixed attribute, or background images using the background-attachment:fixed property. The reason for this is simple, and makes sense once you think about it. On an iProduct, in order to accommodate large amounts of page content on the smaller screens, the user has to be able to pan around the page, and unlike a desktop environment, you don’t get the ever-present cursor and scroll bar with its handy buttons, to say nothing of having a mouse with a scroll wheel. The result of this is that a touch and drag on an iProduct screen has to pan the page around on all directions, and fixed elements will not behave properly in that environment. Accordingly, Safari on the iProducts ignores the fixed property items and moves them around with the page as a whole. It might be helpful to think of a web page on an iProduct as akin to looking at a static printed document that has active areas that allow you to bring up other, related, documents.
The easy solution to all this is simply to make your navigation really big and chunky, which I hate; and to avoid the use of fixed properties in your CSS, but frankly the cool things you can do with them in the desktop environment make that an unattractive choice. You might notice I have used them here.
Can we have our cake and eat it, too?
The answer is yes.
We have a couple of options we can use to accomplish this. WordPress makes this very easy as it has some built in functionality that smooths the process along. If you are not using WordPress, similar results can be achieved using CSS Browser Selector. For WordPress users, check out this excellent article by Nathan Rice on using the WordPress body_class function to detect if your user is on an iProduct and serve them altered CSS instructions to make your site iProduct Friendly.
I’ll let you read the article to get the full scoop, but what is happening is essentially that if someone on an iProduct comes to your site, alternative CSS instructions can be used for any elements that might be problematic in the small-screen multi-touch environment. I was able to use this to remove the fixed properties from various site elements, and best of all, I was able to increase both the size and spacing of text and graphic navigation elements. For the user the changes are totally transparent, and I as the designer don’t have to compromise on my desktop design in order to have a usable site on an iProduct.
With millions of iProducts flying out of Apple’s warehouses, I think iProduct prep is going to become a vital step in delivery of web sites.
