rakaz

about standards, webdesign, usability and open source

Windows Mobile Widgets are totally ridiculous

A couple of weeks ago I went to a workshop by Peter-Paul Koch about W3C widgets. Widgets are little more than packaged HTML, JavaScript and CSS files. Technically they run on a browser, but you launch them as native applications. The best part of the W3C Widgets standard is that it is available right now and that it is available on multiple platforms. Nokia has a widget manager for S60, Opera has a widget manager for multiple platforms and even Microsoft has decided to follow the W3C standard instead of rolling their own incompatible widget standard. A widget written for one phone should in theory work on another phone. During the workshop we created some simple widgets and even tried to transfer them from a Nokia phone to a Windows Mobile phone using Bluetooth.

Today I read an article on the Window Mobile Development Blog that makes it difficult for me to take the whole widget standard seriously. And don’t get me started about Windows Mobile as a platform. One of the biggest advantages is also its biggest disadvantage: cross platform support.

You could theoretically run the same widget on a S60 Webkit based browser, on an Opera browser and… Internet Explorer. And the Window Mobile version of Internet Explorer is based upon Internet Explorer 6… So, if you want your widget to work on a Windows Mobile phone you are limited to the subset of standards that is available on Internet Explorer 6. Effectively that means absolutely no CSS 3 support and not even a proper CSS 2 implementation. No canvas drawing, no fast JavaScript interpreter and don’t even think about using sexy things like CSS Animations, CSS Transitions and CSS Transforms.

The article is called Widget Anatomy – Touch and D-Pad inputs, oh joy! and I am still not sure if the title is meant sarcastically. It should be, although I fear it was meant seriously. The first example is how easy it is to use Touch from within your widget: you can just use the onclick event handler. Sure, this is a good practice. Even the iPhone web browser does this. However I absolute do want a way to get the raw touch events from the phone. The onclick event might be good enough for a simple webpage, but it surely isn’t for a widget that is supposed to work like a native app.

The next example is how to use the Directional Pad – the small button with four arrows that you used to use to navigate your phone before touch screens were invented. Well it is still an important way to navigate your Windows Mobile phone. The example tells us we can use this button to navigate between elements that have a tabindex property and use the onfocus and onblur events to let us know about which element is currently activated. Okay, fair enough. This is how normal keyboard navigation in a browser works. Except that if you want the user to know which element is selected – which is fairly essential – you must use those event and a small piece of JavaScript code to change the style properties of element directly or change the class of the element. Wait… don’t we have a :focus CSS selector for this purpose. Well… Yes, but not in Internet Explorer.

So writing widgets has become as frustrating as web development was before Internet Explorer 7 and 8 were released. At least for web development we now have something to look forward to. The death of Internet Explorer 6. The crapfest on mobile is just beginning…

Comments are closed.