Jan 27, 2010

Mobile MedlinePlus

Long time has passed since this blog has been a "mobile portfolio", so here is some screenshot from a nice project I worked on.

Mobile Medline Plus is a mobile web site hosted by NIH/NLM American Government institutes, which is designed to fit a lot of different devices from some plain old WML device, to the latest iPhone 3GS, Motorola Droid and Google Nexus One.

From the home page at http://m.medlineplus.gov you can:
  • Keyword search and get back results from the MedlinePlus database
  • Browse or Search “Health Topic” Pages
  • Browse or Search Drug Info
  • Browse and Read Health-Related News Headlines
It was nice to see that a lot of blogs and twitter users welcomed the new site and, in general, gave a good feedback to it (for example: this one).

Here's how it look on two very different devices, a SonyEriccson W580, a low-mid end device with a 240x320px screen,



and the Google Nexus One, with its huge 3'7'' inches, 800x480 display.



Not bad, since you think that the very same view handles such different devices!
We addressed the mobile web device fragmentation using the WURFL open source tools, both the file and the Java APIs, which provide a lot of useful information and detail about the device which is requesting your mobile page. Also, WURFL file is extensible, allowing the developer to map custom device behaviours he want to keep track of.

Jan 15, 2010

The good, the bad & the ugly: or how much time you need to spend on devices while developing a mobile website

In the last few months I worked on a mobile website project, which needed to render fine on a wide range of devices.
The most common approaches to this kind of work are usually three:
  • the one-size-fits-all
  • serve different page for each device according to the mobile device request data (usually UA string)
  • sampling by device group, which is sort of half way between the first two: you create a reasonable amount of page templates to best fit to the different device (macro) families and address fragmentation without going mad.
Pros and cons of these appraches have been dicussed widely in the last years. My purpose here is to give you a rough idea of how much effort is needed to adapt a general layout to specific devices in case you use  the third approach.
Imagine that you have created your little, nice and polished mobile web pages. You start testing them on various devices and...gahhhh!!! :D

Mobile IE leaves unwanted whitespaces here and there, BlackBerry browser doesn't render small gifs as you wished and a load of other small layout bugs on other browsers  really do annoy you and, most of all, your customers.
So, assuming your mobile web application passes all your functional tests, there's quite an amount of time that you should must dedicate to solve these problems, being careful not to break the already working layout for this or that device.
This is a report I made for myself, where I recoreded what effort was required by certain mobile devices. Time is expressed in percentage on total time spent. Data are based on personal experience  for a time of three working months.


  • BlackBerry 9000: 8%
  • BlackBerry 8100: 17%
  • Samsung SGH-D347: 12,5%
  • iPhone 3GS: 4%
  • Motorola V3: 8% (all Motorola four V series I used, more or less 14%)
  • BlackBerry 8300: 9%
  • BlackBerry 8800: 10%
  • SonyEriccson Z310a: 3%
  • Nokia 6682: 3%
  • Motorola Droid/Milestone: 2%
  • HTC 8925 and Tilt2: 3%
  • LG CG180: 6%
  • All other phones (3 SonyEriccson, 2 HTC, 2 Nokia, 2 Samsung): 8,5%
As you can see, most of my effort has been dedicated to BlackBerries (44%!), whose browsers are really awful beasts. This means that if your website is business or corporate related, or you estimate that your user base will access your website using mostly BB browser, you better spend some time exploring all the UI tweaks and issues they have. Plain and simple.

Also, particular attention must be paid to low resolution screen / memory limited devies (CG180 and Samsung D347 took a good 20% of my time): in these devices, just adding a whitespace may blow up the entire layout!


Motorola (Droid excluded) took another 14% of time for layout fixing and troubleshooting. Their browser is quite "fragile".


The small work on the iPhone has been just optimization, but I have to say that  in my case the main website UI was targeted to its users. As a consequence of this, also Android devices I used (the Droid and the Samsung i7500/Galaxy) gave me almost no problems: I had just to dedicate a little time to adjust the text for the Droid because of its incredibile high resolution.
Mobile IE browser gave me little trouble (the sum of all models I tested - HTC - took just 5-6% of my time for troubleshooting), but be warned: some Win Mobile 5 phones can give you a little more pain.


As you can see from the low percentages, good old Nokia - both series 60 and series 40 - and SonyEricsson gave me almost no problem.


My advice to you is to make a comparison between these data and other you can collect here and there in the internet and take a decision on how to spend your development time before starting your project.
Though I do NOT claim this result to have a scientific value, I hope you can have some hint of where to focus your effort before developing your mobile website. 

So, who do you think are the good, the bad and the ugly? 
Well, about the last ones I have half an idea :D