Recently I wrote a conference paper for Motorola about using context-awareness to improve the end-user experience. Context awareness is about bringing any additional data, not generated by the application itself, into an application in order to enhance the user experience. For example, if I go to make a call to Fred, the "dialling app" on the phone could detect that I have an urgent email from Fred. Therefore, I may choose to read the email before making the call. The app found out about the email by asking my Gmail account. Context can include all kinds of data from anywhere, as long as it is somehow relevant to the task in hand.
In the age of Web Services and Mash-Ups, it is becoming increasingly possible to augment services in this way. Moreover, I have argued in the paper that many service creators will begin to incorporate two levels of service in their application. The first is the core functionality and the second is generating meta-data about the usage of the application. This meta-data shall be made available via an open API for other services to consume and use as context. In this way, a context pool shall slowly emerge on the Internet. It will become commonplace for services to share data, but this will need to be done in a secure and reliable fashion to guard user privacy and so on. Identity federation will probably be a core enabling technology so that services can talk to each other with the users' permission.
The use of tagging shall be important in the context pool. For example, tagging can transform a "coffee shop" in a mapping application into a "meeting place", which will be useful context for a meeting application (as per the opening chapter of my book). Additional tagging by a variety of users can transform "meeting place" into "good meeting place" and so on. It won't be necessary to know the tagging taxonomies in advance because applications will increasingly have "soft interfaces" by incorporating search into the workflow. In other words, when I use an application to set up a meeting, the meeting place could be selected via search to allow the user to play around with different tags as keywords. Of course, the search will be conducted by giving precedence to the context pool before going out to the net for more results. If the search knows that a user relies on Acme Maps for finding places, then it will look in the user's tagged favourites there first.
This is a big topic, but one of the keys is the unleashing of context data, which comes from a variety of sources, particularly from services that we use every day (and other key sources, like the clickstream in our browser, which is more likely a useful pointer into the context pool).
There are so many potential generators of context. Let's consider in this post (for idea #95) my phone call habits, or my phone records: received, dialled and missed calls. This is a potential gold mine of context data for other applications. Imagine these records are available via a Web Services API on the net and that using identity federation a user can give permission to another service on the net to access this API. A task management application could use these records as useful context data. For example, it could tell whether or not a scheduled call was made to a particular number. An online phone book could also use the data by importing unrecognised numbers and prompting the user to add names. There are plenty of other applications, but it isn't for me or any service provider to dictate them. Once open APIs become available that release service usage and context data into the net, users will have much greater power to create useful and interesting services. Sooner or later, operators will realise (some are already) that this kind of net-friendly and open approach to services is the only future for mobile applications.
Buy my book (Amazon US
)Join my email listSubscribe to my "100 Mobile Product Ideas" free e-book