Mobile Widgets
Widgets are not new, but they are rapidly evolving to offer an attractive user experience and a convenient means for developers to reach users in ways not entirely available via the native or web route.
There is no universal definition of a widget, but most widget technology sponsors tend to refer to them as "mini standalone web applications," or words to that effect. By 'mini,' proponents often mean single function. Even this is problematic. After all, most web apps and native apps really only perform one function, it just depends on the scope of your definition (e.g. "Word-processing" versus "Spell checker")
From a user perspective - not forgetting that the mobile masses don't really know a widget from a wingbat - this "web heritage" tends to set the expectation that widgets, like most web sites, are probably going to be free. Indeed, in all of the various widget vending sites out there, they are free.
Technically, there is no reason why a widget has to be confined to a "mini web app" but part of the problem here is that by calling something a 'widget,' as opposed to an 'application,' we are left with trying to explain, or categorize, what they are. And so, rather unimaginatively, we end up with the stock favourite demos of clocks and weather forecasts. Users will eventually catch-on to the wider potential of widgets, simply by visiting a widget store and seeing the hundreds and eventually thousands of widgets on offer. It will be interesting to see if Apple introduces widgets for the iPhone and supports their distribution via the app store. Technically, there is no reason why a widget can't be signed and DRM-protected. This is just packaging.
The technology underlying widgets is not universal either. So, we have the proprietary widget scripting languages, as offered by Nokia Widsets and Yahoo Blueprint. We have web standards approaches, like Nokia WRT Widgets and Access Netfront Widgets. And we have the Java-bound approach of the new Sun Java ODP.
The overwhelming advantage of the web standards approach is that all those millions of web developers can produce apps for mobiles that load faster than websites because the widget is stored locally. Of course, it has to go fetch data and be quite carefully designed to run efficiently. In fact, there are lots of 'tricks' to designing efficient widgets, but nothing that seasoned mobile web developers wouldn't know. Moreover, the great advantage of the web standards approach, apart from familiarity, is the possibility of sticking with current web-design tools. Apart from the issue of emulation on a mobile device, there isn't really the need for an SDK, as such - just stick to the tools you already know and love. There's some widget packaging to take care of, but this is mostly just zipping of files anyway.
Overall, the web standards approach supports a richer UI with fine control over the look and feel supported by CSS and various Javascript libraries. In theory, there's no limit to the use of existing libraries, such as Prototype and so on, notwithstanding all kinds of very real performance constraints. This is where some skill is required in efficient coding and design. Some vendors, such as Opera, provide 'widget friendly' libraries, such as an animation API.
There are two significant advances that increase the usefulness of widgets. Firstly, on some platforms, widgets can run standalone without requiring the user to first invoke a container application. These standalone solutions mostly involve the widget invoking the web browser 'inside' the widget as a means to display web-standards content. This is the web runtime (WRT) approach, an idea introduced by Microsoft long ago. The key here is that on many new mobile platforms, such as S60 5th Edition, Android and others, the web runtime approach is available without needing to download a 'widgets' upgrade to support running widgets. In other words, many new phones are widget-ready.
What is still missing from the current WRT approach is the ability to support persistence in terms of allowing widgets to consume data whilst 'running' in the background. This is the obvious next step and we keenly await more details of the Palm WebOS to see how they solve this problem. I believe that it is essential to the longer term success of widgets. I recently discussed persistence methods in a previous posting.
With persistent widgets - always active - we can support new modes of ambient communications, such as Twitter or many others that I'm sure will emerge. I recently wrote an essay about 'riding the timeline of moments' via widgets, to be published soon by Vodafone, who are promoting widgets heavily via their Betavine Widget Zone.
The second important evolution is the ability for 2nd generation widgets to access platform services via device APIs that are exposed as Javascript APIs. These give widgets access to underlying phone functions and data, such as the contact book, messaging features, location and so on.
The use cases for widgets are propelled by the possibilities of mixing web-bound services with local phone services. Moreover, unlike standard web-browser models, the AJAX capabilities of widgets permit interacting with websites outside of the origin server(s) for the widget (which is a misnomer anyway because the widget exists as a local XHTML page, not served by an origin server). This enables mash-ups at the client (as opposed to server-side) although operators seem to want to restrict this (e.g. Vodafone Widgets are confined to one host that is pre-defined in the config file) for security reasons.
With device APIs and the increasingly rich capabilities of widget containers (including embedded Flash Lite), the main limitation on use cases is the imagination and having to code within the performance confines of the widget container (e.g. keeping XHTML and libraries local as much as possible, judicious use of CSS techniques and so on). As I hinted above, I foresee that the best and most compelling user experiences will arise from ambient applications that provide the user with a constant drip-feed of data and almost visceral connection with their digital web-bound lives. This is what widgets will be good for. But, there are other opportunities....
There are also potentially new ways for operators to expose their services "over the top" of the underlying handset UI capabilities, which are difficult to update. For example, one can imagine better ways of packaging videophony or self-help. That said, there is no reason stopping operators doing this today and it is surprising how O2 has not offered their own set of iPhone apps to improve the iPhone user's O2 experience, as opposed to Apple experience. The only O2 app that I saw was something to do with Christmas.
This is not a new idea either. Indeed, when I was Chief Architect at Motorola, I tried to get Opera interested in this idea within their browser platform, mostly to expose IMS capabilities to local web apps. These weren't called widgets back then, but Opera had launched something called Opera Platform (discontinued) which essentially did the same thing ahead of the recent advances in browser and underlying platform technologies. Despite being suspended, I still wrote about Opera Platform in my book.
Clearly, WebOS from Palm has taken a similar technological approach, but baked right into the OS, which Opera might have considered (and perhaps still could).
Of course, I'm not sure I would be that keen anymore to support SIP/SIMPLE and its cohorts within the web/widget runtime, but the idea is still interesting nonetheless and could be extended to other use cases. I only suggested it back then (and see it again as a possibility in my slides about real-time mobile web) because it seemed that we would have to wait forever for "IMS phones" and then be stuck with devising an easily accessible and universal programming model to speed up the proliferation of IMS apps. I thought that just as the browser was the universal client for HTTP/Web, why not make it the universal client for SIP/IMS and all the network services behind it. Just another pipe dream! Smart pipe? No. Smart client? Yes.
Comments