On Saturday 28th February 2009 I’ll be heading down to Brighton to particpate in MobileCampBrighton. Tickets for the event will be announced shortly, in the meantime follow @MobileBrighton on Twitter for updates.

The Skiff coworking space
49 Cheltenham Place, Brighton, BN1 4AB.
[ view map ]

While we were in Hong Kong back in November we received the absolutely fantastic news that our submission to SXSW has been accepted.

If you’re a web or interactive designer, chances are sometime very soon you will be asked to design something for a mobile phone. This presentation will introduce rapid and flexible design and prototyping techniques to help you test early, test often and create great mobile experiences.

Sketching the Mobile User Experience
Presented by Bryan Rieger, Yiibu

We’re both really excited not only to be participating in this years event, but also to be contributing to what’s shaping up to be a really interesting mobile and wireless track. Hope to see you there!

Device Grouping

When designing for mobile we typically begin by grouping devices by screen size, and common properties using a device database such as DeviceAtlas or WURFL. This not only provides us with a common base for the initial cross-platform design, but also potential patterns for dealing with progressive enhancement on more capable devices.

This approach works quite well as it allows us to adapt template and theme designs for specific device groupings; which in the end, results in a better user experience. The problems begin however once you start adding actual content to your CMS.

Unlike templates and themes which often include logic to adapt to various platforms—actual HTML content is typically static. A blob of HTML in a database, often designed to work in one context. This is especially true if the content happens to include images, as currently there is no means within HTML to provide alternative images in a manner similar to that of style sheets using media types.

Adaptation and Content Filtering

As mentioned in the previous article, a fully automated approach to image adaptation doesn’t always provide the best user experience on mobile devices. It works by ensuring that the image data fits within the display, but does nothing to ensure that the image itself is in fact still meaningful or usable.

Being designers, what we really wanted was a means of providing human-designed, alternate images that could replace the default image for specific device groups; without having to add logic (php code) to our content.

Introducing a DeviceAtlas - Mobile Image Replacement Filter

After picking the brains of a few developer colleagues we set about to create a plug-in for WordPress that would filter and evaluate images within HTML based upon a few simple rules, and then react accordingly.

1. Look for a replacement image based on defined settings, if the device display width as reported by DeviceAtlas is less than that of the default image size specified.
2. If an existing replacement image isn’t found, attempt to create a new image based on the groupings defined in a settings.ini file.
3. Once a replacement image has either been found or created, replace the src, width and height attribute of the img tag within the html.

As a designer/developer, the above leaves you with two options.

1. Include one image (of the default size), then let the plugin generate and replace the alternates for you. Or…
2. Create a separate image for one, two, or even all of the sizes defined; then let the plugin replace them as needed.

In other words, should you need or want it; you have full editorial control over every size of every image.

The plugin has also been designed in order to load the DeviceAtlas API and data once upon a request and make both available within WordPress itself. This is useful as it enables easy device specific adaptations to templates and style sheets within the theme. In theory the API should even be available to other plugins.

Known Issues and Limitations

First off — we’re designers, not developers. We wrote this plug-in to meet our needs and have chosen to release it (hopefully) for the benefit of others. Please expect a few bugs.

The class we’re using to resize images (requires GD) doesn’t do a particularly good job of compressing the resulting images. Ideally you’d run them through PNGOUT or optimize them in Fireworks in order to ensure the smallest possible file size.

The plug-in looks in the /da-mirf/data folder for the latest (by actual date) version of a .json file and attempts to use that as it’s data source. The filename isn’t important so long as it’s valid and ends with a .json extension.

There is no real documentation at this point as I’m about to hop on a flight to Hong Kong in a few hours. I’m posting this as I’ve been asked by a few colleagues to make the current version publicly available. Expect it to evolve over the coming weeks.

Download and Installation

Caution! The plugin you are about to download is extremely hot — please expect a few bugs.

1. Download the DA-MIRF plug-in for WordPress.
2. Register and/or login to DeviceAtlas
3. Download the current PHP API
4. Download your current data file (click on ‘My Account’ then the ‘Downloads’ tab)
5. Unzip and copy the PHP API (/Mobi/Mtld/DA/*) to da-mirf/libraries (replace existing ‘/Mobi’ folder)
6. Copy to the data.json file into the da-mirf/data folder - the name doesn’t matter, just the .json extension
7. Upload everything to your /wp-content/plugins/ folder
8. Active the DA-MIRF plug-in within WordPress Admin
9. Test using a mobile phone and/or a UA switcher.

To see it in action please visit http://yiibu.mobi.

We are not able to include the DeviceAtlas API or data.json files within the download as neither are available under an open source license. You can however freely download them from the DeviceAtlas site once you’ve registered. Please note: in order to use DeviceAtlas on a live WordPress install you MUST purchase a commercial license.

The DeviceAtlas - Mobile Image Replacement Filter [DA-MIRF] itself is released under the MIT license.

Like many sites out there we’re using a recent version of WordPress as the CMS for yiibu.mobi, and have used a very flexible theme framework to create our templates. This has enabled us to quickly get our site up and running on a variety of mobile devices without any hassle — even managing to score a lovely 5 on ready.mobi (that’s good) - but we still had one niggling fail; page size limit.

The reason for the fail was blatantly obvious. Within our content (the actual pages and posts within WordPress) we had included several images that worked just fine for devices with larger screens and no bandwidth limitations, but failed miserably on devices with more meagre screens and/or limited bandwidth connections.

A Simple Example

The following illustration from BBC News of how a tsunami is formed (while a little extreme) should serve well to demonstrate the point.

Automated Image Adaptation

This image is perfectly acceptable for any desktop browser — but it’s likely a tad large both in pixel and byte size for most mobile devices. The common approach to dealing with this problem would be to simply (and automatically) adapt the image down to a size more appropriate for use on mobile devices.

While this approach works just fine for a large percentage of images, problems are likey to arise with images containing type, fine details or unusual compositions. Images with these traits may often become illegible and meaningless when automatically adapted, resulting in a poor user experience.

Image Filtering and Replacement

A better approach would be to filter the images within the content and display a variation of the image specifically designed for each screen size — including different aspect ratios. This of course would require that the designer provide additional images for each of the alternate screen sizes, but would result in a much improved user experience on devices.

As mentioned earlier, the image chosen for this example is a little extreme. Ideally you would opt to include the caption within the XHTML rather than the image; but I believe it does make my point nicely regarding the need for some other way to deal with content-rich or detailed images beyond simple, automated adaptation (aka scaling). And on that note I’d like to point you to part two of this article.

Ever since I can remember (circa the early 90’s) the standard measurement was roughly 72 to 96 pixels per inch. This of course was typically based on display sizes averaging 17 inches diagonal with screen settings of around 800 x 600 pixels to 1024 x 768 pixels. Of course, some displays were capable of displaying many more pixels - but this was a decent yardstick to go by for a number of years. Recently however things have started to change significantly - but we’ll get to that in a bit.

Getting back to my Nokia E60 problem. This device has a screen size of 352 x 416 pixels which was exactly double that of my existing design of 176 x 208 pixels for the Nokia 6630. At first I was really excited about what I might be able to add to my original design with all of these extra pixels - after all, this device has double the screen size, right?

Well, not exactly. Yes, the screen size was double - but the actual display size was about the same (roughly 2 inches diagonal) which required all font and image resources to be scaled up by 200% in order for the design to be useable. For example, the original design had a bitmap font with a height of 8 pixels which when displayed on the E60 was half the visible height of the same font displayed on the 6630 - which of course was completely illegible. Again, the solution was fairly simple - scale the font and all resources by 200%.

Now I hear you saying to yourself “No problem - I’ll simply scale all my resources appropriately!”. Well, it’s not quite that simple any more as Barbara Ballard recently pointed out. Today mobile designers now have to deal with screen sizes ranging from 128 x 128 pixels to 320 x 480 and higher, with pixel densities ranging anywhere from 110 pixels per inch all the way up to (and over) 193 pixels per inch.

The reality today is that mobile designers are required to be much more aware of the screen size and display variants they are being asked to design for. Information about screen sizes is typically easy to find - but data on display sizes (the actual physical screen size) is much rarer. Lately there has been some interest in seeing this information added to device data initiatives such as WURFL, DeviceAtlas and even Adobe’s Devce Central, but it’s largely going to fall to the community to provide much of this information until the device manufacturers are motivated enough to begin publishing it.