Here is a small bonus addendum to my series on the attributes that make context useful.
My thesis states that to be useful, context must be:- Relevant
- Focused
- Individual
- Meaningful
- Flexible
- Bonus: Transparent and Trustworthy
The previous posts have started to lay out an ambitious vision of what context can do to help. Underlying that vision is a flexible, evolving, rich and complex set of information being managed on behalf of individuals and used to their benefit. I believe that people have to understand what is in their context and how it will be used before they can trust it and rely on it.
Right now trust is vested in individual applications. For example, you trust your email client with the addresses of all of your personal contacts. That trust is based on an understanding of how the email client will use that information, limited to helping you find addresses so you can contact people, and identifying people based on their addresses. Sometimes that trust is broken, like when malware gains access to your email client and sends out mail on your behalf.
Trust is granted based on an understanding of an application’s access to information and its intended use of that information. For an email client its access to information is limited to the set of addresses that you choose to provide to that application and it’s intended use is to send and receive mail. The boundaries around access and use are now changing in ways that users are only starting to appreciate.
Applications are starting to integrate with each other through APIs to access a broader set of information. For example, an email client could use an API from a social service like Facebook or LinkedIn to leverage your existing contacts. That would give the email client access to more than a few email contacts and to more information about each contact. Intended use can also change subtly in this arrangement because the email client might do a little more than just look contacts up in your social network.
The email application could call an API every time you send or receive email telling it which contacts you are using most frequently. That could be very convenient if it helped increase the priority of frequent contacts to make them more easily accessible. It’s also a side effect of the intended use of the email program, one that some users might be uncomfortable about. How to inform the user of that use and ensuring they understand what is being communicated is important to making the feature useful, and safe to use.
Context brings information together from a broad range of applications and can potentially make that information available across applications. That’s both the promise and power of context, and the challenge. By now most people are familiar with the pop-ups they get on their phone asking if a particular app can access their location data. That’s a good example of the challenge facing applications that want to use context data. Applications need to inform users when they are accessing information outside of the usual scope of their own internal data. The simple prompt for location information works because the type of information is somewhat understandable and limited. Context however will be a richer set of data, more applications will need it, and they’ll use it for a wider variety of purposes. transparent toaster
Context needs to be extremely transparent and self-explanatory to help people understand what’s in it, what applications are doing with it and whether they should be allowed access. At ThoughtWire we’re working hard to crack the code to make that level of understanding and control seem simple and natural.
