Application Envisioning idea
J5.

When workers make annotations in a specific context, they can direct their commentary to an intended audience, potentially reducing the difficulty of composing their communications. Product teams can envision concepts that could allow workers to annotate selected functional areas or interaction objects in ways that are visible and meaningful to desired recipients.

Examples from three knowledge work domains:
(Illustrated above) An architect uses her building modeling application to work on early studies for the overall form of a new hospital. As she creates different versions of a central form idea, she inserts annotations of her design rationale in the models, knowing that these notes will be visible when she eventually presents the options to her colleagues, or if anyone happens to take the initiative to review the files on their
own time.
A scientist uses her analysis application to review a number of data sets that have been recently generated in her clinical lab’s ongoing experiments. As she explores the new results, she leaves comments about each data set so that when colleagues in her lab later review the study, they can agree or disagree with her interpretations.
A financial trader, at the end of his work day, posts some thoughts on some recent, high value deals to a shared area of his trading application. He knows that colleagues in other global locations will likely read these notes when they first log in
to start their day.
Successful knowledge work can rely on meaningful graffiti of a sort. Workers may place annotations in specific contexts, to be viewed by an anticipated “public” that will presumably interact with that location at a later time (C5). In some circumstances, these “markings” may only be valuable for a set duration. In other cases, contextual annotations can become essential elements of work artifacts, providing persistent, historical value in organizational memory (I7).
Although public annotations are often created for communication purposes, they can also serve as working annotations (H2) that offload workers’ individual or collective memory effort (E1, E2), thereby supporting later reconstruction and cognitive tracing (H). Like working annotations, product teams can envision functional support for public annotation as textual notes, onscreen drawings, standardized categorical facets, attachments, links, and other means.
When product teams do not actively consider how public annotation could be supported in their application concepts (J1), resulting products may drive workers to use other media and communication channels in relation to certain onscreen content. These outside annotations may be difficult to coordinate with corresponding points within a computing tool (B1, B2, F1). The act of turning to outside media and channels can also be more effortful (D2, D3) than making a note directly where one is presently working. Lastly, real time communication used in place of public annotations may demand receivers’ attentions at inappropriate times (D4).
See also: A, B6, J

Application Envisioning questions:
Where, when, and how do knowledge workers currently annotate shared artifacts and environments in the work practices that your team is striving to meditate? How might targeted workers valuably communicate by annotating your product’s functional areas and interaction objects with
intended recipients in mind?
More specific questions for product teams to consider:
What workplace locations or objects in targeted organizations currently receive public annotations? What form can these annotations take?
What value do these public communications often provide within current work practices? Who are the intended audiences of specific kinds of annotations?
Who else may view them?
What duration do various types of annotations have? Are they relatively static or are they iteratively placed and revised in a form of asynchronous conversation?
Which communication scenarios in your team’s application concepts might be usefully supported through contextual notes and markings rather than interrupting, “separate” messages?
What methods of annotation could be appropriate, based on characterized communication needs, in your differing functionality concepts? Might textual notes, onscreen drawings, standardized categorical facets, attachments, or links be useful?
How could visual representations of public annotations contextually tie them to their onscreen subjects?
Who should be able to view whose notes, based on their permissions within your computing tool? How might workers select certain audiences for their annotations?
What useful supplemental interactivity and information might your team envision around various public annotations? For example, should workers be able to set durations after which their notes will fade from prominence?
How will collaborators discover that an annotation is present? Might contextual flags and synchronous messaging be useful to ensure that certain annotations are viewed by intended parties?
What supplemental attributes, such as a timestamp and authorship information, could be usefully included as part of public annotations?
What privacy and security issues could be important to consider when envisioning functionalities that would track workers’ lightweight, unstructured conversations?
How might your team’s approaches for supporting public annotation relate to your other functionality concepts for supporting cooperation, collaboration, and workspace awareness?
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
|