Download E-Book or Order Softcover Book

In addition to this website, Working through Screens is available in several other formats:
- Softcover print on demand books
- Free letter size .pdf
- Free large format .pdf
- Free "Idea Cards" .pdf
View all Working through Screens Formats
|
|
 |
Application Envisioning idea
D6.

Knowledge work often involves event driven signals and actions, which the boundaries of computing displays may hide from an application’s users. Product teams can envision timely and salient messaging that could reduce or eliminate the need for workers to continuously monitor for certain events that might impact the sequence or outcomes of their efforts.

Examples from three knowledge work domains:
(Illustrated above) A financial trader, while analyzing a potential trade in his market information
application, is presented with a message that reminds him that an earlier, unrelated offer is about to expire in his trading tool. The message also provides him with direct options to accept or decline the pending offer.
An architect receives a text message from her rendering application, which informs her that a lengthy image creation process has just been abandoned due to a critical error. She stops what she is doing to find a computer, log into the networked rendering server, evaluate the incident, modify some settings, and restart the process.
A scientist receives an alert from her lab’s information management application that all of the samples for a clinical study have been processed and that the study’s experimental data can now be analyzed.
Actively attending to multiple threads of complex knowledge work at the same time — roughly speaking — can be mentally taxing, if not impossible. The ability to effectively monitor for key situations across more than one thread of work is often considered a useful and valued skill.
Interactive applications with features that intensively support collaboration (B7, C7, G4) or automation (E) can change the nature of what it means to attend to conditional and time sensitive events. Maintaining diligent attention under these circumstances can be difficult for a variety of reasons, generally rooted in the sense that progressive disclosure can often effectively “hide” important realities.
When it is not essential for knowledge workers to actively monitor a process, product teams can envision concepts for automated (E3, E4) alerting and reminding cues. Relevant, visible, and timely messages can usefully reduce or eliminate the need to remain vigilant for certain application (C10) or object states (B5, B6). Similar to appropriate error messaging (C9, G3), teams can generate these notifications from a strong understanding of workers’ goals, avoiding unnecessary distraction (D4) and providing direct access to related actions (G1, C4).
When product teams do not actively consider how their application concepts could offload attentional effort through alerts and reminders, resulting tools may require workers to persistently attend to the presence or absence of certain cues in order to efficiently transition through their practices (A). Since these automated messages are commonly included in many genres of computing tools, workers may find vigilance tasks without these triggered notifications to be tiring and unnecessary user
experiences (D2, D3).
See also: C5, C8, D, E, H3, K7, K13

Application Envisioning questions:
What events in your team’s application concepts will targeted knowledge workers likely want to know about and monitor for, either as insight into mediated work process or as event driven support for their own memories over time? How might the automated presentation of relevant messaging allow users to stay attuned to these events without maintaining vigilant attention for them?
More specific questions for product teams to consider:
How do targeted individuals currently remind themselves of important, time sensitive information in the work practices that your team is striving to mediate?
What conditions do they monitor for in their activity contexts?
Which of the automated functionalities that your team has envisioned could potentially benefit from alert and reminder options? How might these options provide value by reducing or eliminating effort that would otherwise be needed
to attend to your product’s workings?
What information and conditional events in your application concepts might workers like to have reminders about over time? How might they set up these memory supporting messages?
What relative priorities could be appropriate for the different types of alerts
and reminder messages that your team has sketched?
How directive should various types of messages be? Which could be strictly informational? Which might workers need to actively address within a certain timeframe?
How might lower priority alerting and reminding cues be presented at transitional “seams” between attention demanding tasks and larger activities?
What communication channels could be most effective for delivering different types of alert and reminder content? Is notification within your computing tool enough?
How could interrupting messages present related pathways of action so that targeted workers do not need to locate relevant navigation options?
How might individual users customize their own alerts and reminders to call out those events that they value and to ignore those that they do not?
How might these messages be experienced within groups of cooperating or actively collaborating workers?
How might your team’s approaches for alerts and reminders relate to your other concepts for supporting cognitive tracing, cooperation, collaboration, and workspace awareness? How could these messages relate with your product’s error prevention and handling conventions?
Do you have enough information to usefully answer these and other envisioning questions? What additional research, problem space models, and design concepting could valuably inform your team’s application envisioning efforts?
< PREVIOUS PAGE | NEXT PAGE >

Back to top | View Table of Contents
|
|