Mobile musings and wireless wanderings

Carnival of the Mobilists #120 is now up at Skydeck.
- a great collection of writing as usual.

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:

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
  • WAP
  • Mobile Internet
• 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.

Carnival of the Mobilists 118 is now up at Mobile Point View by Paul Ruppert.
- a great collection of writing as usual.

I propose using the distinction between “place” and “location” as a useful framework for making comparisons between Web 2.0 and Mobile 2.0 in general, and location and locale, in particular. During a roundtable (”Web 2.0 Hits the Handset”) this week hosted by Airwide and Mobile Messaging 2.0, Tim Solt (from go2 media) introduced the distinction between location and locale to highlight the difference between a geo-location and where you are at a given point in time (e.g., Caesars in Vegas).

This clearly relates to the importance of “context” in mobile, which I recently wrote about in Context Is King. It also relates to the difference between the general and the particular, the objective and subjective, etc.

Post-modern geography highlights the difference between a place (my house) and a location (Princeton, NJ is located in the Western Hemisphere at 40.5 degrees latitude and 74.3 degrees longitude). Location is essentially a set of functional relationships whereas place captures the specificity and subjectivity of location. My house is much more than a location; it is a place that is infused with meaning and context.

Location is one element of place. Similarly, listening to music is not merely sound waves within some three-dimensional environment - a Cartesian space where everything can be located on a uniform grid. For me, listening to Scott Joplin’s Heliotropes, John Zorn’s Naked City or Bill Evan’s A Simple Matter of Conviction all connote distinct spaces of listening infused with past experiences of listening, performing and experiencing this music in particular places and contexts.

I contend that Mobile 2.0, when compared to Web 2.0, has more to do with providing users a personalized, localized and ever-present experience to the social web. On the phone you are able to create and consume content in a much wider array of places and contexts. Connecting wirelessly via a laptop is certainly liberating because it is portable but remains an entirely different experience; being mobile is more than simply being un-tethered.

Internet vs. Mobile

Prior to the roundtable on Web 2.0 on the Handset, Steve Bratt (CEO fo W3C) presented the following comparison between the Internet in 1994 and Mobile Data Services as of 2005.

Web 1.0, 2.0 vs. Mobile 2.0

To continue with this style of comparison, I suggest the following distinctions between Web 1.0, Web 2.0 and Mobile 2.0.

W3C and the semantic web

According to Steve Bratt and the W3C, we are moving from a Web of linked documents to “one web” of “creators and consumers” (i.e., Web 2.0) with linked data and services from everyone to everyone (Web 3.0 – the semantic web).

With regards to mobile, I contend that concept of “one web” does not presuppose a browser-based solution on the phone. Steve reinforces this concept by suggesting that the “one web” may involve different user interfaces and experiences but what is common across platforms is that people are accessing the same data with some type of “thematic consistency.”

Widespread adoption of Mobile 2.0

The overarching question that was posed during the Airwide Solutions and Mobile Messaging 2.0 roundtable (“Web 2.0 Hits the Handset” video coverage here), was what does the mobile industry still have to overcome in order to achieve widespread adoption of Web 2.0 from the consumer market?

My answer to this question was consistent with other posts I’ve done on Mobile 2.0. The enablers and drivers for Mobile 2.0 are:

• ubiquitous wireless broadband
• frictionless distribution
• reasonable access fees (e.g., flat-rate pricing)
• open, enabling platforms for service creation

The industry also needs to continue to push for standards and interoperability, i.e., consistent interfaces to ad platforms, social networks, messaging infrastructure and content across mobile and PC).

The Web 2.0 Round Table Final Comments

I had the good fortune to sit next to Rudy De Waele and was at a table hosted by Paul Ruppert.

Steve Bratt provided a succinct summary of the observations raised during the roundtable:

• One web becomes more possible as wireless bandwidth gets more plentiful and devices get more capable
• Users are spoiled due to bandwidth and capabilities they currently get from the Web
• We must make the experience seamless
• Ads need to be better targeted and relevant in mobile
• Personalization is important
• The are many concerns about privacy
• Search and discovery needs to be done efficiently
• Carrier interoperability is critical and carriers don’t need to be dumb pipes

These comments are consistent with Arun Sarin’s (CEO of Vodafone) CTIA keynote. Although he made a similar speech at the Mobile World Congress in February, his points are worth reiterating.

Sarin’s main point is that “the Internet on mobile is the new, new thing.” The increase in data revenues across the Vodafone properties certainly reinforces this contention. Furthermore, “the mobile phone will be the primary touchpoint for continuous use of web services.” He outlined the following challenges to the industry:

• We must move from dozens to 3-5 operating systems
• We need to invest in wireless broadband networks. Furthermore, WiMax should be folded into the TDD section of the LTE standard
• We have to continue to build out better customer information systems and customer relationship management systems.

Finally, Sarin succinctly summarized the key drivers for mobile data services, whether they are communication, entertainment, or mobile Internet services

• Speed (i.e., wireless broadband at speeds moving updwards to 14.4 and 28.8 mbits)
• Simplicity (simple plans and easy to user products and services)
• Value (bundled services)