Context comprises location, time, activity and co-presence
Aliases: context-aware computing · context dimensions
What it is
In context-aware computing, context is any information that can be used to characterise the situation of an entity — the working definition from Dey (2001). In ambient-computing design practice, the core dimensions are four: location (where), time (when, including schedules and rhythms), activity (what the user is doing) and co-presence (who else is there, and their relations).
Context is not the same as environment. The environment is everything that objectively exists; context is the subset relevant to the interaction at hand. Living-room humidity is an environmental fact; it enters context only when you are deciding whether to run the humidifier. Context is defined by the task, not by the sensors.
Why it happens
Why these four? Each answers one question the system must resolve before adapting:
- Location answers "where do which rules apply" — home modes and away-arming are anchored on it. Location is also a hub for further inference: knowing where imports the conventions of that place (a person in the bedroom at 11 p.m. suggests "should be sleeping", not "should turn on the lights").
- Time answers "what behaviour is appropriate now" — the same utterance means a weather query in the morning and possibly a plea at night. The time dimension has three layers: clock time, schedule (calendar events), and rhythm (personal routine), and they are not interchangeable.
- Activity answers "what currently occupies the user's attention and hands" — which sets the cost of interruption and the availability of input channels.
- Co-presence answers "who is the audience and who must be negotiated with" — the appropriate intensity of the same action (playing music) differs alone versus with guests; co-presence also determines control (who may change things, whom to notify).
Together the four dimensions constitute the situation of an interaction: the system uses them to decide what to do, at what intensity, through which channel. A system missing dimensions adapts at the wrong level of abstraction — one that tracks location but not activity will run "arrival mode" on a sleeping occupant.
Studying it
- Concept and survey literature: Schilit and Theimer coined context-aware computing in 1994; Dey's 2001 Understanding and Using Context supplies the widely adopted definition and discusses why context cannot be sensed directly — it is inferred.
- Empirical work on dimensions: field deployments of early location-aware and ambient applications repeatedly found that acceptance depends on sensitivity to activity and social setting, not on location accuracy alone — purely location-driven automations are among the first to be switched off in real homes.
- Operationalisation studies: build annotatable taxonomies of context — experience sampling has participants report location, activity, companions and affect at random moments, producing a self-report baseline against which sensor-driven inference is scored for coverage and accuracy.
One methodological caution: self-report baselines carry their own biases (label smoothing in recall, social desirability); triangulation across sensor logs, self-report and observation is the standard configuration, and no single source suffices.
Where it stops holding
- The four are a design checklist, not a complete taxonomy. Physiological state (heart rate, sleep stage), device state (battery, load) and environmental quantities (noise, illuminance) are frequently added. For a given system the criterion is "would missing it cause a wrong action", not "is it on the classic list".
- Dimensions conflict. Location says home; activity says working (a late-night deadline in the living room). A rule with a single-dimension priority must get one of them wrong — arbitration across dimensions is the real difficulty, not enumeration.
- Part of context is socially constructed. Whether something counts as work or rest, whether a guest is close family or a stranger, cannot be sensed; it must be learned from the user's conventions or asked. Treating social dimensions as physical quantities produces systematic errors.
Applying it
- Before designing any adaptive behaviour, write down which context dimensions it depends on, which signal infers each, and what follows if the inference is wrong — a three-column table is the minimum.
- Location and time are the most dependable dimensions (mature sensing, stable semantics); activity and co-presence are the least (long inference chains). The heavier the consequence, the more the behaviour should anchor only on dependable dimensions.
- Always model co-presence explicitly: whether anyone is home, and who, shapes nearly every interlocking behaviour; a system that cannot perceive presence should not run "when someone is…" automations at all.
- How to check: for each adaptive rule, sample trigger moments and record the true values of all four dimensions (self-report plus logs); measure the share of cases where every dimension was judged correctly yet the behaviour was still inappropriate. A high share means a dimension is missing — not that inference is inaccurate.