Mobile Widgets
On the web, widgets have helped transform the way people create and distribute applications and services. Not only have widgets helped democratize the creation of web applications (i.e., accelerated the ability for end-users as well as software developers and engineers to create web applications), they have been instrumental in reinforcing a more distributed web strategy that has increasingly shifted the power of impressions from the portal to the network. Granted, not only have widgets introduced problems related to fragmentation, lack of inoperability between various engines and distribution outlets, they also lack effective and reliable methods of measurement and monetization. As with other nascent technologies and markets we can presume these are temporary setbacks.
In mobile, however, widgets not only face issues of fragmentation and monetization but they themselves have been targeted to solve another problem endemic to small screens with constrained interfaces: user experience. While there are certainly dreams that widgets will one day bring frictionless distribution to mobile, they are primarily being used to address the relatively poor user experience associated with having to navigate the world of networked content via URLs.
I would suggest that looking for widgets to solve the user experience problem is akin to treating a symptom and not the core problem related to user experience. Mobile widgets, I would contend, have other traits and characteristics – other than temporarily solving the usability problem related to mobile user interfaces – that will make them worth watching as they evolve.
Widget 101
Widgets can be defined in general as self-contained, portable, mini applications that often provide a narrow range of functionality (e.g., temperature) within single context (e.g., weather) in a format that can be installed and utilized across many distribution points (e.g., home pages, blogs) by end-users (i.e., without additional software development, compilation or integration).
The following types of widgets are often distinguished:
- Desktop widgets (e.g., Dashboard widgets from Apple)
- Web widgets (e.g., Yahoo! widgets)
- Mobile widgets (e.g., Nokia’s widsets).
It is worth noting that in mobile both phone-top widgets and mobile web widgets already exist.
The origins of widgets can be tied to a number of preceding capabilities, e.g., (i) early web page add-ons such as link counters and later banners, (ii) Apple’s accessories on the 1980’s Mac that included small apps like calculators and notepads, and (iii) the personalized “my homepage” capability enabled by Netscape Navigator and popularized by Yahoo!. Niall Kennedy has more details on the history of widgets as well as a nifty timeline here.
Widgets are part of what Lawrence Coburn calls “The Four Pillars of a Distributed Web Strategy” which, in addition to widgets includes (i) toolbars / extensions (e.g., Google, StumbleUpon), (ii) Facebook Apps (e.g., iLike, RockYou), and (iii) APIs (e.g., Yahoo! Maps).
Scott Weiss contrasts widgets with applications in the following manner:
| Widget |
Application |
| Single / Partial Screen |
Multi-Screen |
| More Client-Server |
Stand-alone / Client Server |
| Narrow Functionality |
One at a Time / Full-Screen |
| Faster / Easier Access |
Rich Functionality |
| NotePad |
Word Processor |
| Notifier (mailbox flag) |
Email or IM |
| Alarm / next appointment |
Calendar |
| Friend, etc. Finder |
Map |
Not a lot has been written on the size of the web widget market - let alone the mobile widget market - other than suggestions by Will Price (CEO of Widgetbox) that roughly $20 to $30 million is spent on services to build widgets. This obviously doesn’t take into account any ad revenue or traffic generated, or transactions that they drive to various networks and sites.
Widget Creation
There are primarily three main vehicles used to author widgets:
- Client-side scripting (e.g., Javascript)
- Markup (e.g., framed HTML)
- Plugins (e.g., Flash, Silverlight)
Of course these techniques can be combined in numerous ways, e.g., a widget can include both markup and scripting or scripting and Flash. Niall Kennedy has more details on the basic widget formats.
Mobile Widget Enablement
Regardless of how a widget is designed, created and implemented, there are primarily three main vehicles on mobile devices for presenting and “housing” the widget for end-users to find and use. They are:
- Browsers
- Players
- Media Players
- RIA Players
- On-Device Portals (ODPs)
- Homescreen Replacements
- Portal / Portlet Applications
Browsers
Browsers, in general, are used to navigate and view various types of content that is typically resident at remote locations and accessible via a network. Most common are browsers that enable users to navigate content available on the World Wide Web. These browsers were based on a content model that assumes a collection of linked pages (i.e., collections of images and text). With the addition of scripting capabilities (e.g., Javascript), browsers have moved beyond the page-based paradigm.
In mobile, there are essentially two types of browsers: WAP and mobile Internet browsers. Primarily mobile players like Access and Openwave have provided WAP browsers whereas Mobile Internet browsers are and will be provided by both mobile-specific companies as well as more traditional players like Opera, Apple, Nokia, Mozilla and Microsoft.
Players
Players, in general, are most often used to play back and render media or serialized scripts. In mobile, there are essentially two main types: Media Players and RIA Players. RIA Players originated as embedded plug-in objects for browsers. Media Players (e.g., most notably Real, Quicktime, Windows) have been primarily used to playback music and videos.
In mobile, Media Players are provided by both operators and others. Verizon, Sprint, and AT&T all have players that can be utilized stand-alone or launched via video links in WAP / xHTML sites. Companies like Real Networks, Microsoft and Apple also provide Media Players in mobile.
On-Device Portals
On-device portals (ODPs) are mobile applications that have been optimized for accessing and interacting with content and information without necessarily using the Wireless Application Protocol (WAP) or other markup languages (e.g., HTML) and associated protocols (e.g., HTTP). The two primary types of ODPs are Homescreen Replacements and Portal / Portlet Applications. They can best be distinguished by their method of distribution and core functionality.
Homescreen Replacements are ODPs that primarily pre-ship with the device and provide the primary user-interface from which the user accesses content and information directly from the phone-top. Portal / Portlet Applications are ODPs that are typically acquired over-the-air (OTA) and provide a self-contained application for content and information discovery and viewing. ODPs came about in response to problems associated with WAP browsers such as compounded network latency issues, poor user experience, and the high number of clicks required to access relevant data and content.
It is worth noting that the Portal / Portlet Applications are sometimes called “browser-less” solutions, which really means a network-based application that lets you interact with content but is not a full-fledged browser.
We are seeing both browser-based solutions and ODP-based solutions used as widget frameworks in the market. There has been less traction with the “players” in enabling widget discovery and usage.
It is still much too early to predict whether browsers or ODPs or some other, yet-to-emerge solution, will become the dominant vehicle for navigating and viewing content from the Mobile Internet. The enthusiasm accompanying mobile advertising and the growth in Mobile Internet traffic has led many to side with a browser-based view of the world. Yet, alternative approaches that do not utilize a browser are gaining traction (e.g., Yahoo! Go, Alltel’s Celltop) which could indicate a future in which the browser is present but not necessarily the dominant form of access to rich, interactive content. ODPs, which were declared dead several years ago, are still getting press and are getting design wins from operators and customer deployments. Other evidence of operators looking beyond the browser to provide a better user experience is the recent announcement that AT&T’s Media Mall 2.0 is to be delivered as an application rather than a WAP browsing experience.
User Experience
Widgets, and the collection of various enabling applications and frameworks (e.g., browsers, players, ODPS – defined below), provide an alternative approach towards addressing the user experience for networked, content-based services in mobile.
Both users and service providers have become attracted to the grid-based (i.e., tile-based, box-based) UI method for navigating applications and content packages. This type of intuitive UI has been utilized in a wide range of interfaces ranging from Zumobi’s to Apple’s iPhone. I’ll have to take my hat off to Harry Kargman (www.kargo.com) who not only has a patent on what he calls the 9-grid but has been a strong proponent of this method of navigation for over 8 years. This method of UI has also become the de facto standard for presenting and enabling the discovery of various mobile widgets.
While the user experience is primarily determined by the design and implementation of given application or service, it is also driven by the underlying technology, which in return is driven by the “paradigm” of the approach (i.e., browser, player, ODP). Beyond the core elements of design, which is not my direct area of expertise, I find it useful to distinguish between the core elements of user experience and the underlying technology critical to enabling the user experience.
Core elements of user experience related to rendering and presenting widgets and widget frameworks / containers:
- Usability (i.e., ease of use, navigation, intuitiveness)
- Configurability (i.e., personalization, customization)
- Responsiveness (i.e., perceived speed, degree of interaction)
- Accessibility (i.e., findability, discoverability)
- Richness (i.e., compelling, high-quality)
Underlying technology critical to enabling user experience via widget enabling engines:
- Protocol (e.g., RTSP, HTTP, TCP)
- Caching (e.g., adaptive, predictive)
- Transfer modes (e.g., synchronous, asynchronous)
- Data Encoding (e.g., XML, binary / serialized)
- Media Encoding (MPEG-4, H-264, AAC, AMR-WB)
Creating and Finding Mobile Widgets
Methods for creating widgets are relatively straightforward and the leading mobile widget providers have essentially based this on what has worked on the web (e.g., Yahoo! / Pixoria’s Konfabulator).
The methods for distributing and enabling end-users to find mobile widgets, however is messy and extremely fragmented. Not only does the problem of distribution and findability relate to the other general problems of finding content via mobile devices, but also contains additional complexity. I have written about the findability problem in mobile.
Part of the complexity surrounding mobile widgets is due to the fact that widgets often require a “container” application for their discovery and utilization. I find it useful to distinguish between empty containers and full containers when it comes to distributing widgets within mobile. In a full container model, you have an existing portal that has a variety of content (e.g., Yahoo! Go). Presumably, given that it has content, the application has been downloaded and has achieved relatively wide distribution. Then, widgets become an add-on to this “full container”. In this model, the widget provider benefits from the fact that the container is widely distributed and already exists on a number of handsets. In an empty container model (e.g., Nokia Widsets), the widget itself must be so compelling that the user is enticed to download the entire widget engine in order to utilize it.
In their white paper on mobile widgets, little springs design articulated areas that are impeding traction with widgets: (i) lack of common terminology – users need to know what exactly they are getting, (ii) lack of perceived value – what the user is getting of why is it relevant to them, and (iii) lack of immediate access by the user, i.e., remove their dependence on a separate free-standing application and therefore ability to use them directly from the phone top.
Mobile Widgets – the Net Net
It would be short sighted to believe that the main purpose of widgets is to solve the user experience problem in mobile. Providing a better user experience comes down to people that truly understand the combination of design and mobility. I would contend that the value widgets could bring to mobile comes down to the following:
- Mobile service extensibility
- The democratization of mobile content and service creation
- Better distribution and syndication of mobile content and services
Mobile service extensibility includes a wide range of vehicles for being able to add value to a service or application after it has been deployed. This includes not only widgets but other forms of micro-sites and integrated add-on environments.
With regards to the democratization of mobile application creation, I believe it is imperative that people are able to create mobile applications and services using their own tools and that they are based on standard web technologies. Furthermore, similar to the power that Frontpage brought to web site creation; widget-authoring environments (e.g., the web-based tools for creating and distributing widgets) and aggregation sites will increasingly enable end-users to more easily create, personalize and distribute applications and content.
When contrasted to the desktop or laptop experience, (i) the user interaction model is fundamentally different on mobile (i.e., without a keyboard and a mouse), (ii) the consumer touch points have the ability to be more tightly integrated (e.g., talking, texting, sending, receiving, listening, viewing), and (iii) mobility itself is an entirely different experience than being portable and / or always-on.
It seems self-evident that the mobile experience will certainly lead to more medium-conducive forms of content and service syndication. The question is whether widgets will round out this trifecta – I am still coming down after being in Vegas for CTIA – by providing better mobile service distribution and syndication.
Share and Enjoy:
These icons link to social bookmarking sites where readers can share and discover new web pages.