Just like designing for the desktop screen, designing for mobile devices comes with its own set of hurdles and considerations.
Not all mobile browsers are created equal, and you'll need to be aware of their positive aspects and failures alike. Some mobile browsers allow you to zoom in and out of a page for easy access to links, some don't. Some allow you to change the aspect ratio and some don't. And of course mobile devices have varying screen resolutions, and are nowhere near the same as their desktop counterparts. If you thought designing for 800x600 years ago was painful, try 640 x 320 or lower.
Some mobile browsers are operated by touch screen alone, some require moving pointer around the screen and some allow both. Which is most important to your audience?
Bandwidth restrictions play a big part in how you put your design together. 3G speeds are usually fast enough to render any page, but many mobile phone carriers charge insane amounts for bandwidth. Here in Australia some are at the rate of around $5 per megabyte. On the subject of bandwidth, the Nokia browser, despite being a very capable piece of software, does not cache, so going back and forwards between pages you've already viewed will force a complete reload from the server, which means it can potentially consume 2 or 3 times as much cost as other mobile browsers. With this in mind you're mobile web site is going to have to be as lean as possible.
And something I've seen overlooked is that not all mobile browsers can handle AJAX requests, so graceful degradation or something a little more extreme is going to play a role.
Combine all these variables with the fact that the user has the ability to change the default font size (and often does), you'll soon find yourself stepping into a world of pain reminiscent of the old Netscape vs Internet Explorer development era – unless you're prepared.
The check list
Before you even start writing any code you're going to have to commit to a set of design outcomes.
- Fixed width or fluid?
- If you use fixed width, what will be the resolution you design for?
- Will you allow for the mobile device being rotated to a different aspect ratio?
- Will you need to reduce the number of primary menu items, and which ones will be used?
- How will you handle large images and flash video that is supposed to appear in the content?
- If it's a blog, will you allow users to login and comment?
Obviously I cannot list every possible outcome here as there are too many unknown variables from one site to another, but as you know your site better than anyone else, you're in the best position to decide how to proceed.
How I proceeded
Given the subject of this blog knowing I have a technically minded audience and using data I was able to retrieve from the stats, I decided that a fluid design with a minimum width of 240px was in order.
240 pixels doesn't allow for many root menu items across the top horizontal axis, so I selected the most important and limited to 4. While I could have added more, one of my goals was to not have any horizontal scrolling on the mobile pages at 240 pixels wide.
Additionally, all JavaScript actions have been either replaced with a graceful equivalent or removed altogether. Except for one instance, and that is a script that resizes article images proportionately to fit the browser width.
This script while very useful, I couldn't help but think there might be a better pure CSS alternative. Fixing the width of an image isn't difficult, but getting a proportional height is impossible with CSS alone. I'm pretty certain this is impossible.
Sizing the text
My first instinct was to jump right in with the 62.5% CSS trick, and not too far in I realised it wasn't going to work as expected. While I have no qualms doing this for desktop screens, I've noticed mobile browsers seem to disagree on what the default size should be. This is by no means a technical certainty, but instead based purely on my observations of a handful of different mobile browsers.
With that in mind, I decided that using pixel values for the text was going to be the best way of making the design appear consistent across different mobile platforms.
If anyone can suggest a good reason why this might not be good idea, I'd love to hear it. But as this is a learning process I am happy to put it into practice for now.
Getting around a page
One criticism I have of many mobile web pages I frequent is the lack of care shown towards getting around a page. One of my goals was to make sure that all links are easy to access and they aren't so close to each other that you accidentally activate something you didn't mean to. You'll notice the main menu items on the mobile version of this web site are basically big buttons. This was a deliberate choice because I know it's not easy having to be pixel perfect with the tip of my finger.
Likewise, to reduce the amount of finger scrolling up and down the mobile device screen, consider strategically placed anchors on the page to allow users to jump up and down with ease. Things like “back to top”, “jump down to comment” and anything else that might be needed.
Usability considerations
One thing I noticed about Opera Mini, despite it being my favourite mobile browser, is for some unknown reason it will not underline hyperlinks. This means that a simple underline for a link will not suffice (as there is no way possible to notice it), so you'll have to make sure to use a colour as well. I took it a step further on the homepage links by adding background colour and padding for emphasis.
This might be a redundant point to raise as I suspect most designers change the default link colours anyway, but I thought to mention it just in case.
Development testing
My development testing was done in Firefox knowing true and well that it wouldn't look exactly the same when viewed on a mobile device. While this help speed things along in the early instance, eventually you get to a stage where you simply have to start refreshing pages on the mobile browser. Just make sure your local dev environment can be accessed in a browser other than your own machine.
Keep the URL short
My suggestion here is to follow what many others have done, and use an “m”sub-domain for the mobile site, like m.yourblog.com for example.
The reason for this, aside from being an easy to remember convention that should be widely adopted, is that note every mobile device affords the luxury of quick text input, and “m” is a lot easier to enter than “mobile” on an alpha numeric keypad.
Conclusions
I will happily concede I am yet to be fully versed in all areas of expertise regarding mobile web site design and development, but just like desktop screen development it's a lot of practice, trial and error. With this in mind, let this comment thread be dedicated to pointing out anything I may have missed or even gotten completely wrong.
CSS Babe
Thanks webby guy! My boss asked why our site doesn't work on his blackberry very well but I haven't really tried to tackle a mini version of it yet.
Sunday 15th November 2009 | 07:36 AM Reply Comment URL Profile Back to top