Application Envisioning idea
K11.

Product teams can envision functionality concepts that could allow knowledge workers to program different sorts of coded routines within their computing tools, such as the steps followed by an automated process. Interactive, task specific methods can make programming straightforward in the
context of workers’ own goals and technical skills.

Examples from three knowledge work domains:
(Illustrated above) A scientist writes her own algorithm within her analysis application to visualize the data from one of her lab’s clinical research studies. She starts with a standard algorithm provided by the tool, then exploits defined flexibilities to modify its rules toward the new visualization approach that she wants to try.
A financial trader is reviewing performance trends in his group in order to find potential areas for improvement. To locate only deals made within the last month that match highly specific criteria, he uses his trading application to compose and save a long and complex Boolean query.
An architect selects an option to have her building modeling application record her actions. Once she has finished recording the interaction sequence, she can then
easily apply the same sequence of steps to other objects within the same project.
When confronted with exacting and effortful processes (D2, D3), knowledge workers may want to program specialized additions and modifications to their computing tools that are tailored to meet their individual, local needs (E, A7, A8). They may, however, find the notion of tackling even small programming efforts to be daunting. For example, while functionality for coding macros can allow workers to extend some contemporary products in diverse ways, it may require them to invest significant effort in order to learn unfamiliar and abstract programming languages.
Since many people are not accustomed to writing code like a computer scientist, product teams can envision tailored programming methods that encapsulate known, inherent rules in targeted work practices and that are intrinsically appropriate for users’ technical skill sets. For example, end user programs can be constructed from sequences of restrictive, easily understood “blocks” that are relevant to workers’ goals and mental models (I2, I3). Alternately, more implicit methods, such as action recording functionality can allow workers to program their tools based on recorded interactions within a product’s “everyday” interface, which can then be “played back” on other interaction objects (B1).
When product teams do not actively consider potential needs for end user programming in their application concepts, resulting products may not be flexible enough to effectively support the diversity of workers’ practices. In some instances, completing certain tasks or larger activities may simply not be feasible without customized automation. In the absence of such functionality, product teams may receive a seemingly unsupportable variety of conflicting automation requests, each representing a granular need in local, adopted practice (M4).
See also: A, C8, D4, I1, K, M

Application Envisioning questions:
What functionality concepts might your team envision to allow targeted knowledge workers to create their own algorithmic rules in order to meet local and emergent needs? What inherent constraints, representations, and interaction idioms might you draw upon to promote clearly bounded and intuitive “coding” experiences?
More specific questions for product teams to consider:
What do targeted individuals and organizations think of any end user programming features in their current computing tools?
What programmed extensions have they created using these features, and who created them?
Which of the work practices that your team is striving to mediate contains important variabilities in rule based processes?
What types of changes might targeted knowledge workers want make to the default algorithms in your sketched application concepts? Are these changes predictable enough to become customization options — or are they diverse yet important enough to warrant some kind of programming flexibility?
Might programming needs be so infrequent and unchanging as to make technical openness to extension by IT staff more desirable than end user programming options?
What larger technology trends and advanced analogies to other products could valuably inform your team’s envisioning of potential programming concepts?
What interactive programming methods could allow users to flexibly “code” algorithms in ways that are appropriate for their skills and the targeted domain context?
How might your sketched functionality ideas for end user programming allow individuals to carve out particular yet easily understandable paths through well characterized spaces of rule based possibility?
How might people test out their own algorithms without any risks to valued data? How could these testing outputs reference your product’s larger error prevention and handling conventions?
How might your team eventually learn from the changes that your users will presumably make via programming options in your computing tool? How could
your product’s overall system promote community sharing of these local innovations?
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
|