UCG: Modelling User Context

filed under Crossover · 3 comments in the original

Zbigniew Lukasiak posed an interesting question for me yesterday relating to my notion of a User-Context Gateway (UCG). He asks:

So generally what you propose is something like a digital assistant managing your contacts. In my opinion we cannot rely too much on explicite instructions given by the user since it would quickly become too complicated for everyday usage. So the important question is how can we collect the implicite information clues on which the digital assistant can rely. I can imagine something similar to what we do for filtering spam messages - a bayesian filter learning while being used, after all both in the heart of the problem have the scarcity of our attention

I certainly agree that a system that relies completely on explicit rules would become overwhelming to use very quickly, however, I'm never one to take away too much control from the user. Here are some quick ideas on how to fold a User-Context Gateway (UCG) into the normal flow of a user's day.

Observation

The most natural way for a system to learn is by watching a user perform actions and then repeating them. I like this to the act of training voice software to recognize your voice or macro recorders that mimic user actions. To learn from this process, the system would have to observe a number of things:

Applications used
Length of time applications used without interruption
Time of day applications used
Contacts conversation initiated with during application use
Contacts conversation persists with during application use
Contacts immediately dismissed during application use

By looking at this information, we know who I may be seeking information from while working, who I might be chatting with throughout the day, and what times of the day certain types of behavior are dominant. Training could be omnipresent or staged. Depending on the hardware configuration and system requirements, an always-adapting system could be somewhat resource intensive. I use Bayesian filters (via Thunderbird) for my mail and as a result, I have noticed the mail is slower to process now than it was before as the data set has grown in size. I could see there being, instead, a Training Mode where I allow the system to monitor activity for a day, week, or even month after which I could disable the learning process.

Also, the IM and other presence-aware applications would ideally be adapted, or the UCG would assume control, to present me status alerts in a consistent manner. For example, when a user sends an initial request via MSN, a small alert box shows up letting me know. Unfortunately, this behavior does not last so I cannot tell after that first contact. If the alerts were unified such that all showed up, it would be easy to tell when I chose to engage a contact versus ignored.

The net result of this is an adaptive set of rules that would govern the system while not requiring special user facilitation.

Time Scheduling

Most business professionals use some form of scheduling software today, be it Microsoft Outlook, Act! or something else. This software has the potential to greatly ease the administrative burden of the UCG. I see three different approaches that could hook into the existing systems:

Scheduling of work time -- currently, we tend to leave our calendars open except when there is an explicit interaction (meeting, phone call, etc.) required. However, if those times were allocated to certain tasks, say "Preparation of Presentation" or "Phone Calls To:" the system would be able to pull out that the user is engaged in an activity as opposed to sitting idle. Naturally, this can be a burden as well, but could make for a reasonable way to better manage some aspects of one's time.
Activity Buffers -- a new field could be added to appointments that would allow a user to specify time buffers. A time buffer would be like a blackout period, say 1 hour before a presentation, that I use to tie up loose ends and review my materials. These buffers could be explicit or adaptive, adapting to the persons attending, location, or content.
Status Indicators -- another new field could also be added to appointments that allows me to specify my Presence Status. This would be an easy way to toggle my ability to respond the time-sensitive issues. For some meetings I am simply present to observe or for support, while others I am the presenter. I may choose to allow no requests through when presenting, trusted ones through when I am supporting, and all through when I am observing.

Scheduling will help to tie my efforts to manage my time to my efforts to manage my online presence.

Explicit Rule Definition

As I mentioned earlier, I am not often fond of closing doors when it comes to functionality. Certainly there have to be restraints in place, and usability considered from start to finish. That being said, I believe that explicit controls of the UCG are also required for three simple reasons:

Rules are never enough since there are always exceptions
As user's grow familiar with a system, they tend to realize the holes and require more sophistication
Power users always demand more sophistication from the beginning

I do not believe that the rules need to be overtly complex, however. In fact, these rules would allow one to drill deeper down (towards more specificity) as desired. The path might start from either the application or the contact, as both are pivot points. Also, there are already common systems in place that individuals are growing more and more familiar with.

A "Do Not Disturb" list for applications for which I did not want to be interrupted could be very useful. Continuing with how this might flow towards specificity, I might be able to then add a time, term, or contact filter. The time dimension would allow me to say that between 10 A.M. and 2 P.M. I want this to apply. The term dimension might apply to the length of time I am using the application uninterrupted, so if I am using for "30 minutes straight" then I might be on a roll and not want interruptions. A contact filter might allow certain individuals in or stop them at the gate.

Utilizing White, Gray, and Black Lists for contacts would enable me to setup more global rules about who I want to provide access. These lists could be linked to explicit groups in my presence-aware application or could be comprised of a list of other identifiers like e-mail address, company, etc. This provides room for exceptions that are meaningful to me that might not be easily caught or understood by the underlying adaptive agent.

Defaulting Behavior

I think on top of all of the above, the most important part is to manage user expectations properly from the start. No system is perfect, especially ones that are intuitive and adaptive, like a UCG would be. Setting a reasonable goal for the system, say to reduce interruptions by 25 or 50% would be a great way to start and move onwards.

When all else fails, a good system of default behaviors would go a long way and categorize "unknowns" in the manner most desirable for the user. For example, the general rule for the system might be "If unsure if I should allow the message through: _ Always Send Through _ Always Queue For Later _ Always Deny" would more than suffice. Then based on the overall success, the user could choose to re-train, schedule better, add more rules, or toss the entire system :)

I welcome feedback on how anyone else would improve such a system