Application Envisioning idea
C7.

Valuable functional support for cooperative or collaborative knowledge work activities may impact the larger structure of a computing tool. Product teams can envision pervasive cues within their application concepts that could highlight significant actions of other users acting in the same “workspace.”

Examples from three knowledge work domains:
(Illustrated above) An architect knows that one pane in her building modeling application contains a variety of information about what her collaborators are doing in the same project file. She uses this pane to understand who is working in the same building areas that she is, as well as to see who is available for conversation (see illustration).
A financial trader learns that a certain area of his trading application will visually indicate when another trader is acting on the same information that he is. This notification allows traders to prevent discoordination by initiating discussions about their current work.
A scientist knows that any time she looks at individual items in her analysis application, such as samples within a clinical study, a specific area of the screen will notify her of related actions being performed by other members of her lab. Also, when she first logs into the application, a special “welcome” display summarizes key changes that have been made to lab data since she the last time she accessed the tool.
Knowledge workers are often highly skilled at understanding how their own actions fit into the context of cooperative and collaborative activities in their organizations. Computers can have dramatic impacts on this understanding. For example, when interactive applications become a key focus of work practice, implicit visibility and communication (J1) that was once tied to the physical performance of work can easily become hidden or entirely lost (G4).
Product teams can envision structural cues that could promote useful types of workspace awareness across the range of tasks and larger activities that they are striving to support (A7, C). An application’s larger framework can include functionality for contact facilitation (J4) and other features that highlight shared opportunities or potential conflicts within a networked environment (B7, J5, H3). These structural responses can dramatically impact a product’s conceptual models (C1), interaction model (C2),
and permissions functionalities (C5).
When product teams do not actively consider how workspace awareness could be incorporated into an application concept’s cross functional framework, opportunities to promote cooperation and collaboration can be lost. Even though envisioning workspace awareness on a function by function basis can solve individual collaboration issues (G4), without structural support, collaborators may find that they have difficulty planning larger activities (D2, D3), communicating effectively (J), distributing effort (E), and preventing conflicts (C9, G3).
Conversely, too much visibility into the actions of others can be distracting (D4) and
can potentially lead to unwanted surveillance effects (A2, G7).
See also: A, B, F1, G, H, J2, J3, K, M1

Application Envisioning questions:
What structural, application level approaches might your team envision to allow targeted knowledge workers to stay usefully and meaningfully aware of others’ actions within the same data locale? What might these awarenesses feel like in practice?
More specific questions for product teams to consider:
How do targeted individuals currently keep track of their colleagues’ actions as part of the work practices that your team is striving to mediate?
How, specifically, do current forms of shared awareness promote the effective execution of loosely coordinated or truly collaborative work? How do they prevent conflicts?
What breakdowns currently occur due to insufficient awareness? Could these problems present opportunities for your product?
Where might the introduction of your team’s computing tool remove implicit and subtle awareness cues from targeted work practices?
What larger design and technology trends could influence your ideas about how workers might remain appropriately aware of others’ actions within your application concepts?
How might your sketched application frameworks aid workers by providing valuable workspace awareness cues at a structural level, across various functional areas?
What types of actions in your product’s shared workspaces could be tied to stronger, attention grabbing cues? To weaker, almost subliminal, cues?
Who needs to see various cues? How might awareness information relate to individuals’ permissions and tailored views?
At what point might users of your computing tool face information overload from awareness cues? When might it be more appropriate to tie workspace awareness to individual functions and contextual areas, rather than your tool’s overarching structure?
How long should specific awareness cues last in your application’s framework? How might they be tied to longer term, stored histories for certain functions and interaction objects?
What impact could overarching awareness functionality have on the larger conceptual and interaction models of your sketched products?
What unwanted surveillance effects could unintentionally occur from broadcasting specific actions to other workers?
How might any standards set by your structural workspace awareness designs influence your team’s envisioning of awareness cues within individual functionality concepts?
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
|