Bristol Wearable Computing

[ Home | Plans | Meetings | Members | Search | Papers | Links | CyberWear | LocoSoft]


Triggering Notes

While note triggering seems simple enough, in fact there are a few hidden complexities.

From the user's point of view

A note is triggered when the context associated with the note matches the user's current context. Context can be measured from the environment (for example, location, time and temperature), or it can be obtained from the user (for example a topic of interest). The context associated with a note is normally formed from the note-creator's context at the time the note was created.

When the user's context changes many notes can be triggered at once. In this case the notes are placed in a queue to be rendered. Even if the user's context changes these notes remain in the queue and are eventually played. The exception to this is if a new context causes a new note to be triggered. In this case the render queue is emptied and replaced by the new note(s). Any notes currently playing are interrupted and any unplayed notes are dropped.

The only other complexity here is that notes have a 'suspend profile'. This profile is used to prevent users from becoming irritated by repeated triggering of notes. The profile sets a minimum time interval between successive renderings. This interval may be short for the first few times, but then perhaps longer for notes that have already been played many times to the user. Eventually the note may be deleted altogether. The suspension and deletion profile are controlled by policy under the control of individual users.

From the system point of view

Ideally the system would be driven by 'context-change' events, in practice certain contextual dimensions such as time, change so frequently that they would overload the system. Instead the system regularly polls the current context in order to establish whether any context changes mean that a new note should be triggered.

The system compares the current context [1] of the system against the context associated with each note [2] held in its local database. All matching notes are placed in a 'context-set'. The system compares the current context-set with the context-set it constructed for the previous poll cycle. If there are new members in this context-set compared to the previous one, then the system assumes that the context has changed. As a result we flush the render queue and replace it with the members of the current context-set.

This two-stage 'set and queue' process, called 'micro suspension', prevents notes from being repeatedly added to the render queue, in the case where the context remains the same over successive poll cycles. This is in contrast to 'macro suspension' controlled by the suspension profile process, which is intended to suppress repeated rendering when contexts change rapidly with the same context emerging frequently. Micro suspension is the one that the user doesnt know or care about, because they assume the system is event driven and thus wouldnt see why a note might be repeatedly added to the render queue if they remained in the same context for a while. Macro suspension is the one users do know about and want to control according to their preferences.

Things get difficult when a note comes out of suspension while we are at particular context. In the original design the note database formed the context-set by selecting notes whose context matched the current context and then removing notes that are suspended. This sounds right, but can result in a context-set suddenly acquiring a new note as it comes out of suspension. This causes the system to wrongly guess that the context has changed, causing a surprise interruption of the current render queue. To overcome this the context-set is formed without reference to suspension. Suspended notes are only eliminated at the point when the context-set members are passed into the render queue.

This final scheme still has two interesting features:

footnotes:

[1] The significant dimensions of the current context are set by the user with 'matchUserContext' and 'matchSensedContext' policy statements. The value of these dimensions are then established by consulting the appropriate context drivers via the device manager.

[2] The context of a given note is specified by the 'render' attributes of that note.


unicrest.gif (4191 bytes)

The material displayed is provided 'as is' and is subject to use restrictions.
For problems or questions regarding this web contact Cliff Randell.
Last updated: January 14, 2000.
logoep.gif (1404 bytes)
ęCopyright Hewlett-Packard 1997-2000.