Software Everywhere — David Beers on Mobile Computing

Mention the growth of mobile data (or lack thereof) and most of us think wireless data: "what are the killer apps for 3G or 4G networks?" Let's face it. Taken as a whole, high-speed wireless networks are still an answer searching for a question that most consumers don't have yet. But there is another kind of "mobile data" that strikes closer to the question of user experience and solving real problems. That is the data that is stored locally on the mobile device. While everyone is focused on what will drive wireless data usage, mobile OS vendors like Microsoft, Symbian and ACCESS have made some interesting changes in how your data may be stored on your mobile and what you will be able to do with it: each is baking a relational database engine right into the next versions of their operating systems.

That may sound like information that only a software engineer would be interested in, but I'd like to outline what I think it could mean to users. There's the potential for this trend to produce meaningful improvements in the mobile user experience, and maybe even open up new markets for smartphones by addressing pain points of real consumers.

It's my data, let me use it how I please

That sums up the familiar backlash of the user against DRM of downloaded media. But many mobile platforms encourage or even force developers to treat your personal data as if it was protected under DRM, too. Would you like to search for a text message you received last week and then save it as a memo or attach it to an email? Or share a link in your bookmarks with a friend? These simple things are difficult for developers to implement because text messages, memos, bookmarks and buddy lists are each stored in binary formats that only the application that created them knows. Even if the developer knows the format, that data is for some platforms totally inaccessible outside the application that created it, Java MIDP being the most notable example.

Just as open standards for data like XML and RSS are turning the Web into a platform characterized by interoperability, extensibility and sharing, standards like SQL can bring these characteristics to mobile platforms. Data stores like contact lists, messages, call logs, task lists, and voice memos can be queried, and this data mixed and matched by applications to create a more complete and flexible user experience.

One important kind of data that users generate constantly is rarely captured despite the fact that it is tremendously useful for personalizing and simplifying the user experience: data about usage itself. Information concerning how often certain pieces of information are accessed by the user or how they relate in actual usage to other bits of information should factor into how software responds to input. For example, if I've sent a lot of text messages to Linda this week it would be nice if my phone predicted that I was probably sending her another one when I entered just the letter "L" as the recipient and offered to autocomplete this information. (Following the "L" with an "a" would correct the wrong guess and offer a revised one: "Larry" perhaps.) This requires fast search capabilities that are hard to implement with current mobile data storage techniques. Relational database engines like MS SQL Server CE and SQLite use indexes, internal data structures and algorithms that make such on-the-fly searches instantaneous for users and easier for developers. Without spending a lot of time tracing out the implications I'd just like to assert that thoughtful tracking of device usage can make all kinds of operations faster and easier for the end user and become an important factor in improving the mobile UI.

Sometimes data is the (killer) application

Two years ago I had the good fortune to see Michael Mace give a great presentation on the segmentation of the mobile user market, of which this article is a digest with some helpful new diagrams and insights. Michael has done more than anyone else I know to identify a large, but as yet relatively untapped segment of the mobile device market that he refers to as "Information Users," as distinguished from "Communication Users" and "Entertainment Users." At this conference he presented many striking video clips of consumers talking about how they use their mobile devices, and it was easy to pick the Information Users out from the rest. Where others talked about how their mobile devices helped them keep in touch or entertained them with music and games, these people echoed things like "it's my second brain," "it watches my back," or "I keep my whole life in there." These users carry a smartphone or PDA because they need a place to off-load their brain and a reliable way to retrieve that information wherever they are at a moment's notice.

To some extent this segment of the market really needs a new device that hasn't yet been produced. But for a lot of us, a smartphone could be a powerful digital assistant if it had two things: really bulletproof synchronization of data we keep in our PC or on the Web, and quick retrieval of a specific piece of data from many megabytes or even gigabytes of stuff. These requirements are not adequately met by current smartphones, but a sophisticated database engine like MS SQL Server CE or SQLite (which is starting to look like a new cross-platform standard) can go a long way toward filling the gap. Relational data allows you to, well, relate bits of data to each other in ways that are difficult to do otherwise. The "tagging" mechanism utilized to great effect by GMail and many other Web 2.0 applications is a good example of how retrieval of information could be dramatically improved. But consider being able to search for a note you recall taking down the week before your last vacation (date queries) or all the documents, phone logs and emails that are associated with a particular customer in your Contacts list.

An interesting thing about the applications that Information Users most need is that they share a pretty uniform set of operations affectionately known among developers as CRUD (Create, Retrieve, Update, Delete). These operations correspond with the basic SQL commands such that the application logic itself can be a pretty thin layer on top of the database. Thin enough that this logic, and even the GUI, could in many cases be represented using nothing but data in a database and a middleware engine that takes the place of the code that the developer would normally have to write. We call this a pure data-driven architecture, and it has two very interesting properties that are relevant to the future of mobile data on smartphones. First, these applications are very easy and fast to create and modify since almost all of the difficult stuff has been coded into the middleware. Second, once the middleware has been certified and tested (and perhaps even included in ROM by the ODMs and carriers) the applications that run inside it are safe and reliable from the perspective of the carriers. They don't execute arbitrary code against the operating system since they are completely sandboxed by the middleware. Since the carriers are wary about native applications for the risk they believe they pose to the stability of the network and (more realistically) for the costly support headaches they can create, a data-driven service-oriented mobile architecture like this would probably be welcomed with open arms, as would the developers who take advantage of it.