Mobile Image Replacement

by bryan on November 14, 2008

In the previous article I touched on one of the problems we encountered while working on our mobile site, namely— automatic image adaptation for mobile devices. In this follow-up article I’d like to share a solution we’ve come up with to improve the user experience, with the hopes that others might find it useful.

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.

Example of automated adaptation for smaller screens - note the text becomes illegible and details are lost.

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.

da-mirf: settings.ini and alternate images based on default_suffix

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.

WordPress

  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.

{ 2 comments }

Mobile Image Adaptation

by bryan on November 12, 2008

Over the past week Steph and I have been busily working away at creating a mobile version of Yiibu. Yet again we’ve encountered an all too familiar problem when designing for mobile devices; mobile screens and pixel sizes — and dealing with larger images on smaller screens.

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.

ready.mobi: score of 5 [Good] It will probably display very well on a mobile phone.

ready.mobi: 1 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.

Example of an image that works just fine within desktop browsers.

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.

Example of automated adaptation for smaller screens - note the text becomes illegible and details are lost.

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.

An example of a replacement image for smaller images where the detail and the legibility are preserved.

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. ;)

{ 1 comment }

Mobile Screens and Pixel Sizes

by bryan on October 29, 2008

A couple of years back when working on migrating a design to the Nokia E60 I ran into an interesting problem that resulted in my questioning something that I’d taken as fact for a number of years. Exactly how big is a pixel?

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%.pixelsizes.png

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.

{ 7 comments }