Page 42

100 APPLICATION ENVISIONING IDEAS | B. DEFINING INTERACTION OBJECTS

WORKING THROUGH SCREENS

B9. Common Management Actions for Objects Some types of interaction objects in computing applications will typically require a conventional set of management actions, such as create, copy, edit, and delete. Product teams can map available management actions for different types of interaction objects, envisioning what common functionalities might look like in different object contexts. Examples from three knowledge work domains: An architect is refining an early design exploration in her building modeling application. She creates a building element, copies it, and pastes a duplicate element in another part of the building design. She likes how easy it is to create repetitions within the model, allowing her to quickly visualize her ideas for building form (see illustration). A scientist deletes a file in her analysis application where she had pursued the wrong approach to a clinical research problem. By deleting the outputs of her faulty exploration, she ensures that it will not be mistakenly accessed by herself or others in her lab.

I’ve just finished this shape that I want to try out as a repeang element in the exterior of this new building that our team is currently generang ideas for...

Architect

Conversely, for some types of interaction objects, providing certain management actions, or even the ability to create multiple instances, may not provide sufficient value to warrant the additional complexity (A9, K6). See also: A, B, C3, C4, H1, H2, I1, I2

More specific questions for product teams to consider while envisioning applications for knowledge work:

Which of the interaction objects in your sketched application concepts will have multiple instances, requiring some range of management actions? Which will not? How might the understood “location” of individual objects factor into usable object management interactions? When is it not an issue?

So I select the element in my modeling tool...

Which object types should users not be able to delete? Why? Beyond the basic set of management actions, what other actions could become standards within your computing tool, such as creating objects from a template or resetting objects’ attributes to their default values? How might your functionality concepts for managing different types of objects retain clarifying and learnable similarities? What important differences could be useful for managing particular object types?

Interactive applications typically need to provide knowledge workers with some standard actions for working with multiple instances of onscreen objects (B1). Whether the interaction object in question is an overall file or a much smaller element, the clarity and directness of “management” actions can be an important usability concern.

When product teams do not actively consider object management actions in their application concepts, they can easily overlook central requirements due to their shared assumptions about what will be defined and implemented. When these oversights are present, users may, for example, be forced to view out of date content that they cannot delete (D4, I). To overcome some object management deficiencies, knowledge workers may need to develop and repeatedly enact excessively effortful work arounds (D2, D3).

What common management actions, such as create, copy, edit, and delete, could the interaction objects in your team’s application concepts require or benefit from? What important management actions might you be overlooking?

How do targeted individuals currently “manage” artifacts, in the computing sense of the word, while performing the work practices that your team is striving to mediate?

A financial trader creates a new categorizing attribute in his trading application to supplement the product’s defaults. From that point on, he and other traders in his group will have the option of tagging the new informational attribute onto their pending and completed deals.

To ensure that these interactions are sufficient and coherent, product teams can map the breadth of object management scenarios presented by their application concepts (B8, C3, G2). Management actions frequently include create, copy (E3, E4), edit, and delete. Other actions, like creating from a template (B10) or resetting to defaults (C8), can be usefully considered as “standard” for some types of objects (A4). In collaborative computing environments (A7, C7, G4), the presence or absence of management actions may depend on dynamic rules that prevent negative impacts on the activities of other workers (C5, J4).

42

How could object management functionalities provide strong feedback about action outcomes? What novel interactions and cues could reinforce the successful completion of these important tasks? And then I repeat it...

How might rules supporting collaborative practices influence the range and availability of object management actions? What error prevention and handling concepts can your team envision to prevent loss of valuable information during object management actions? How could associations between interaction objects be impacted by certain management interactions? When might workers benefit from understanding the lineages of these evolving associations? What options might allow targeted organizations to appropriately set up different user permissions for managing different types of interaction objects?

And maybe that feels like one too many for what I want, so I’ve deleted one of them...

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?

Working through Screens (Tabloid Size)  

Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work This heavily illus...

Advertisement