Page 137



definitions for “functional area” and “functionality.” Information management application: In the context of this book’s examples, this term refers to a computing tool for clinical research. These applications, also known as a Laboratory Information Management Systems (LIMS), can keep track of all stored data about a laboratory, from the stock on the shelves to the results of genetic tests. Many of these systems also provide functionality for defining and monitoring laboratory workflow, allowing scientists to design and distribute experimental protocols for lab technicians and automated instruments to follow. Since LIMS are often open to integration with other applications, they can become a central hub for connecting all of a laboratory’s computing infrastructure. See the “Primer on example knowledge work domains” section for additional background information on the clinical research computing examples used throughout this book. Interaction object: The comprehensible elements within an application that workers act on in order to accomplish their goals. Interaction objects are defined from users’ activity oriented perspectives, and they do not necessarily correspond to the idea of “objects” in the computer science sense of the word. Product teams can translate key interaction objects from artifacts in workers’ existing practices, which can then become meaningful elements of an application’s intended conceptual models. Other objects can represent novel system ideas that would otherwise not exist in targeted knowledge work culture. Interaction objects can nest and interrelate, and ideas for additional, low level objects may emerge during the product development process. The notion of interaction objects is derived from Ben Shneiderman’s “Object-Action Interface Model” (1998), without its emphasis on direct manipulation. Interaction pattern: A reusable convention in the design of interactive applications. These conventions are often thought of at the “literal” level, containing specific arrangements of information and user interface controls. Interaction patterns can also usefully represent larger commonalities in conventional interactions, such as approaches to entire application structures or task processes. Interactive computing: In the context of knowledge work, applications of computing that workers directly interact with, as opposed to an increasing number of embedded applications that are effectively hidden in artifacts in a way that prevents users from having direct control over their behaviors. This book primarily focuses on interactive applications that could be feasibly implemented on personal computers at the time of writing. Interactive application: A specialized computing tool for mediating targeted activities, including both installed products

and those that are accessed via the Internet. In the context of envisioning potential user experiences in knowledge work, the emphasis of this term falls less on the technical construction of a tool and more on its potential definition and design opportunities. Interaction model: The highest level expression of an application’s structure. A “shell” that determines how interactive behaviors and disclosures essentially flow within a computing tool. An interaction model frames the full scope of an onscreen product, outlining the interactive approaches and points of access for its constituent functional concepts. In contemporary personal computing, where some sort of keyboard and pointing method are essentially a given, interaction models may reside largely in the onscreen structure and behaviors of a knowledge work tool, rather than in specialized hardware controls. Knowledge work: A broad category of human activity that is focused on inventing, producing, interpreting, manipulating, transforming, applying, and communicating information using specialized skills and knowledge. Knowledge workers: Individuals who, in their working lives, are valued for their specialized intellectual skills and their ability to act on and with complex information in goal oriented ways. This term can refer to specialized professions (such as the architect, financial trader, and scientist found in the examples throughout this book) or more generalized vocations. Object: See definition for “interaction object.” Organization: Any group of individuals working together with shared goals and, in many cases, a division of labor and responsibilities. This umbrella includes groups such as non profits and online collaboratives, as well as those that are more commonly associated with knowledge work in the business world. Magic happens expectation: A problematic expectation in product teams that a successful, even visionary, product will somehow emerge solely from the sum of countless detailed definition, design, and implementation decisions — without a larger design strategy or application concept as guiding road map. See also definitions for “straight to the details progression” and “single vision and concept design.” Market information application: These computing tools allow financial traders to investigate current and historical data about specific market sectors and traded financial instruments from a variety of different perspectives. The feeds and visualizations in these applications can help traders to stay current on market happenings and to better assess potential deals. See the “Primer on example knowledge work domains” section for additional

background information on the financial trading computing examples used throughout this book. Mediate / mediation: Refers to an interactive application’s interfacing role between workers and their goals, as coarsely borrowed from Alexei Leontiev’s Activity Theory. Each approach to supporting a work practice with technology presents different “mediating” changes to the essential nature of that practice. Knowledge workers will inevitably view some mediation approaches as more attractive and successful than others. Models of problem spaces: Artifacts that summarize meaningful primary research, secondary research, and design research insights into clear and informative representations that map out relevant regions of product possibility. These models can take a variety of forms, ranging from graphs, to textual stories, to storyboards, to video exposition. Offloading: Reducing the work needed to accomplish an action by distributing some of the effort to an interactive application, collaborator, or another part of a distributed work system. Actions that initiate offloading can range from deliberate and intentional to implicit and subconscious. Offloading effort can change the essential nature of work practices. After a computing tool has been appropriated into a workplace culture, participating individuals, in their accommodated ways of thinking and acting, may not even recognize how they opportunistically offload effort to the external artifact. Operation: Within a product team’s rationalized models of work practice, operations are low level actions that workers can perform. Individual operations are typically enacted in a sequence in order to accomplish larger goals for interacting with a system. Operations are one part of the “operations, tasks, and activities” hierarchical approach to modeling work (see other definitions in this glossary), as coarsely borrowed from Alexei Leontiev’s Activity Theory. Multiple operations comprise a task.

This broad definition can include anyone from high level management to knowledge work “customers” who are brought on as advisors and design participants. Progressive disclosure: A design approach which can decrease perceptual load and promote more effective use of limited screen areas by “hiding” some content and functionality until it is interactively accessed, as needed, through users’ goal oriented pathways. Scaffolding: Borrowed from Lev Vygotsky’s ideas on the Zone of Proximal Development, scaffolding is application content or functionalities that provide workers with supporting structures for their learning, based on an understanding of their current knowledge and abilities. Users can accomplish more with the support of scaffolding, and by doing so, they can make learning leaps that may be more difficult without such support. After an individual has learned a scaffolded interaction, the supporting features can often be removed from day to day use. Alternately, in some cases, these features may be left in place to provide some ongoing utility. Scientist: See definition for “clinical research domain.” See also the “Primer on example knowledge work domains” section for additional background information. Settings: Meaningful parameters in an application that workers can have some measure of control over. These parameters can be highly flexible and numerous in applications for early adopters. By contrast, in highly developed products that target less invested user segmentations, guiding product settings may be relatively few in number and more constrained in scope.

Product: See definition for “application.” In many cases, the term “service” could be equally applicable (though it was not extensively used throughout this book in order to promote brevity). Although the term “product” has a commercial connotation, the applications discussed here could also be created by an open source community or internally developed within specific organizations.

Single vision and concept design: The problematic approach by which product teams iteratively create only one de facto design strategy and corresponding application concept. These singular progressions often begin with a rush toward implementation and only limited ideas about product direction and potential meaning. Although teams practicing this type of design may evolve their own conceptions about their applications at a detailed level, their lack of early, divergent thinking about work mediation can be considered a failure to strategically explore potential directions within their initial, high level charters. See also “straight to the details progression” and “magic happens expectation.”

Product Teams: The primary audience of this book; a group of people creating an interactive application for knowledge work. For the purposes of this text, product teams’ memberships can include anyone who plays a role in product development, with a special emphasis on those individuals who are (or could be) involved during early, strategic, application envisioning efforts.

Sketch: A rough representation of a framing idea or potential design direction, generated within a product team during the application envisioning process. Teams can sketch at many levels of granularity, ranging from an application’s overall vector to the diminutive shape of a small functionality concept. During early envisioning, teams typically create sketches to capture and con-

Working through Screens (Tabloid Size)  

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