Widget Investigation leads to a ‘Worst Practice’ Discovery

Nokia just wrapped up their Developer Conference in Monaco last week. Sadly, I didn’t have the budget to go. Maybe you were lucky and did (or maybe you live there, lucky you!). Anyhow, one of the technologies that they’re pushing these days is their WRT (Web Run Time) or Widgets for the lay person out there. This whole mobile widget thing is nothing new, but what does appear to be new is that they’re gathering a steam this time.

The widget buzz has been rumbling for years now in the mobile world. Looking as far back as 2005 there were the Opera Platform, MIDAS from Openwave, and the Widget Player from Access. Nokia’ widgets platform, ‘Widsets’ is, after two years of service, being subsumed (along with MOSH) into the the new Ovi Store. All along, Yahoo! has had widgets for mobile as well integrated with the Yahoo! Go application for WinMo/S60 devices. As with most things in the mobile world, there really isn’t a standard to go on, so what’s a developer to do, and should you even care?

Well, as always, before jumping in with both feet, it’s highly advisable to stop for a minute (or maybe an hour or even a day or two) and think about what you’re trying to accomplish and what your development resources look like. Thinking about what you want your users to get out of your mobile experience will help guide you down the right path.

If all you’re looking for is information access and traditional web type interactions with your users, then your investments will likely be better spent on a slick mobile site that differentiates for high, medium and low end devices. Your in-house web development folks ought to be able to crank something suitable out for you. If you want deeper interaction with the user or device, then you’re going to start looking native. Development costs will be higher, timelines will be longer and life cycle management of your application is going to be much more involved, but you will get keystroke level interaction with the user and complete integration with the underlying OS.

Widgets (and their engines) fall out somewhere in the middle. If you want to do more than just have a mobile page, but don’t want to make the investment (or commitment) to going fully native, then they may be worth looking into. Ask yourself the following questions:

• Do I feel OK not really getting at native APIs?
• Do I need more than location, messaging and address book integration?
• Am I OK running in a sandboxed container?
• Am I OK not really having my own icon on the Phone Application Menu?
• Do the devices I’m targeting actually support the widgets?
• Am I OK living without clear paths to revenue for any of this?

If you answered yes to all of the above, then perhaps a mobile widget is for you! But before you get all wound up, there is always a caveat. Control of the environment, or lack thereof may leave you feeling blue. As I took a quick spin through the widgety world out there from a developer and an end user perspective I came across some pretty interesting things, but in the process stumbled upon something on the pure web environment side that I’d like to share with you today. Don’t worry, I’ll get to the nitty gritty nuts and bolts of what you can and can’t do with the widget engines out there too, but this struck me as an important.

First off I went to the Yahoo Mobile Widget Gallery (http://mobile.yahoo.com/gallery) on my desktop system. I don’t think that it’s really fair to call what they list on these pages ‘widgets’ as they’re just a series of optimized web sites from the Yahoo! Family of properties. The Yahoo Widget engine proper is Yahoo! Go, so I’m not sure why the folks at Yahoo! suggest going to beta.m.yahoo.com to ‘browse the Widget Gallery’ from my mobile device (yes, even though the service has come out of Beta and the real link I’m re-directed to is ‘new.m.yahoo.com’). The resulting user experience on my device is pretty horrendous, and doesn’t match what’s on their site. What does happen is that the little ‘widget/gear’ icon just isn’t there, and the icons that are present don’t line up with the Y! logo. It wasn’t this way in the beta version, (there were other issues like blue links on a blue background…) so I dug into the code a bit and discovered what is perhaps a mobile web ‘worst practice.’

Those icons, are not being placed on the screen as part of an tag, they are getting dropped in as a background-image in an empty span. I’m not sure why the folks at Y! would go to this length of complexity, but it seems like some sort of content management gone awry. Instead of simple code that one might expect:
[code]



[/code]
what we have instead is the following:
[code]

[/code]

They’ve taken the trouble of combining the variety of icons, glyphs and miscellaneous buttons into only 3 PNG or GIF images and then attempt to use the background-position property to create a clipping area and display only the small 20px image that they really wish to show.

It strikes me that there are several things wrong with this approach for the mobile web.

• Accessibility: no tag means no ‘alt’ text.
• No Layout Hints: without the tag you can’t assist rendering by providing image dimensions to the browser in the tag
• Reliance on Tables: There’s no real reason here to force a tabular layout here. Tables are also expensive in terms of processor (and therefore battery) so why?
• Background-position: Ok, a CSS2 property to control a critical element of page layout in Mobile. Don’t go there, really.
• Empty element: If you notice, the only thing that appears active in the selection of the link is the space, which doesn’t cover the width of the icon itself.
• Performance penalty shifted: Sure, if you combine images you benefit from reduced HTTP transactions, but you’ve moved the burden now to the layout engine, which sadly may be unreliable.

I do really think that the biggest problem here is the reliance on the layout engine to respect the background-position to create the clipping area on the composite image. The thing is that the icons are really very static, (and they even set a long life for their composites in the cache), so you only get that chatty HTTP penalty once if you cut them up on the server first. Whereas when you rely on the layout engine to do the work for you, the user gets the penalty with every page load/re-load as the rendering engine chugs away.

Really. I don’t know what’s going on over at Yahoo! these days. Maybe they’ve been drinking too much iPhone kool-aid, but that’s not even a valid excuse because the do serve up a slightly different presentation to iPhone, S60, and WinMo, and even promote that they support those three specific platforms.

So where I am I going here. I started out just trying to evaluate widgets and their engines from an end user perspective so I could give valid advice to you the developer on some of the if/when/how questions that you would come across. Instead I get this cautionary tale for mobile development. Even though the browsers are getting more powerful and sophisticated you are [b]not[/b] dealing with the web proper here. In addition, they blew some basic fundamentals here:

1. Make sure that your desktop preview of your mobile site really does match what the end user is going to see on the mobile side
2. Make sure that your links are updated (e.g. don’t tell people to go to the beta site where there’s no content except a pointer to the new page). At the very least, do a server side re-direct if you’re done with your beta…
3. Evaluate your performance improvement strategies for real improvements
4. TEST ON REAL DEVICES!!!

I’m still working on the widgety widgetness, and will have that for you shortly. Thanks for listening to me today!