I gave a talk on Mobile Widgets for Over The Air in London on the 4th of April, 2008.
Widgets are small, vector graphic, data-capable, handset-resident, persistent data applications (at least within the widget environment, which can be the idle screen of the phone). Though they typically work as client-server setups, that relationship is not required. For example, a location-based gas station price comparison tool would necessarily be client-server, since the server would contain the price data, as well as the stations list. Another server would likely handle the geographic information transmitted from the phone. On the other hand, a widget that displays your text messages in a spiffy theme could simply run as a phone-resident client.
Widgets can be deeply embedded in the phone’s features, working with other applications, or they can be fancy RSS readers. A deeply embedded widget would be the text message display application described above. An RSS reader would be the gas station price comparison tool. Due to the extensive feature range in current widget concepts, a big worry is that widgets will present security threats and malware problems.
Widgets require cached memory, Internet access (nearly always), user interface support, and versioning. The widget rendering engine might need updating, or policy might change.
The ecosystem model for widgets is interesting. Consumers won’t create them, but they should be customisable. URLs are too long to type in, so they need to be available from some aggregation point (e.g., an application store), with a good, optimised search engine–probably accessed through the widget engine directly. It would be nice if they could be side-loaded too–through an SD card, Bluetooth, or USB cable.
Following is a map of the widgets value chain:
The operator-oriented value chain differs. Operators are likely to want a store front that demonstrates their brand. They will pick the platform that suits their business needs, with heavy security, advertising support, and simple-to-the-consumer billing models. Developers may need to pay to play–not being visible without an up-front payment to the operator. Non-operator-built solutions will require complicated installation procedures and suffer trust issues. In either case, authoring is a serious issue, as widget systems will require new scripting approaches or APIs to compile against.
Data policy will be required. Will widgets have budgeted memory or will they be disposed of when inactive? Are they flat rate or by minute or by the byte? Flat rate widgets are likely to be more successful, from a user experience perspective. Power issues will be significant, as widgets may require a lot of processor activity. And let’s not forget the potential for network impact.
Security and trust are paramount, but there can be no guarantees. At the OS level, hooks will need to be provided so that widgets can interface with the core handset data and media modules. Crashing should never, ever happen. Malware needs to be prevented as much as possible, and stopped when it slips through the cracks. Disruptions will erode trust quickly.
With all these issues, who should the central authority be? The Open Mobile Alliance? And who should provide and control the engine? I think it’s the browser vendors, because widgets are most similar to web sites. I don’t think it should be a manufacturer, since each manufacturer would want its own solution. If the controlling entity is the operator, we’ll have just as much fragmentation, as each will choose a different engine vendor and format. However, without cooperation from the manufacturers and the operators, widgets won’t have proper placement within the handset’s navigation.
When I gave this talk, it was conceivable that Openwave would deliver a solution, though its browser assets have been sold to Purple Labs. Since then, discussions about widgets have gone very quiet–and Nokia’s Widsets platform has evolved into the Ovi Store, but not without hiccups. I think the concept of “widgets” will soon become a thing of the past as they may end up being called “applications,” but it would be even nicer if widgets, applications, and web sites became one user concept. Why complicate matters?
Check out the the Mobile Widgets Business Issues slides (PDF).
