Programmed Interactions: Spell It Out First

Programmed interaction generally refers to any combination of user andprogram interaction based on user input and programmed responses. For mypurpose here, I exclude games. What’s the difference between games andinteractions, you ask?

Clark Aldrich distinguishes between games and interactions, with theformer focused on scoring points or advancing through a series of challengesand the later more about improving levels of performance. (See the Referencesat the end of this article.) By this definition, programmed interaction can beas simple as branching navigation based on user selection and as sophisticatedas simulations of complex phenomena that morph with changes in variable values.One can accomplish  the former by linkingweb pages or using authoring tools, requiring little if any actual coding(i.e., using a programming language). One can only accomplish the latter throughsophisticated coding and a lot of calculations.

Some basics

Beyond a clear understanding of our learning objectives, there aresome basic concepts useful in designing interactive learning activities. Keepin mind that limited objectives generally make for a less complicated design.

Interaction components

According to Kristian Kiili, Designing programmed interactions needsto take into account four components (Kiili, 2005):

• Person: What instructions, feedback, pacing, or sense of progress do they need? Where do learners lie along the continuum between novice and expert?
• Task: Is it authentic to the occupation, profession, etc., or is it simplified or chunked for novices? Is there sufficient challenge without being overwhelming? Do you present the problem in full up-front or on a transaction-by-transaction basis? Does the task involve behavioral as well as cognitive elements?
• Artifact: Is it user-friendly, authentic, and easy to understand? Are resources available to assist?
• Other learners: Adds exponentially to interactivity, learning levels, and domains that can be addressed, and to design complexity.

Types of interactivity

Roxana Moreno and Richard Mayer describe five basic types ofinteractivity between learner and system.

Dialoguing—Learner receivesquestions and answers or feedback to his or her input—for example, usingcontext-sensitive help, clicking on a hyperlink to access additionalinformation, interacting with an avatar who guides the learner through theactivity, or making selections and experiencing the consequences.

Controlling—Learnerdetermines pace and/or order of presentation—for example, using the pause orforward buttons on a player; selecting from a set of options.

Manipulating—Learner setsparameters for a simulation, zooms in and out, or moves objects around thescreen—for example, setting parameters in a simulation and running thesimulation to see what happens.

Searching—Learner finds newcontent material by entering a query, receiving options, and selecting anoption—for example, using help and search functions.

Navigating—Learner moves todifferent content areas by selecting from available options—for example, clickingan option, and moving to the corresponding page or location.

Bridging to external activities

You can increase the number and scope of learning objectives bylinking programmed interactions with other learning activities. In this way, whenyou integrate the learning object with the larger learning enterprise it is morelikely to achieve its objectives. Moreno and Mayer cite an example wherestudents failed to improve their comprehension when asked to order the stepscorresponding to a natural causal event (e.g., rain, drainage, flooding). Whenthey modified the interaction to prompt students to reflect on the results oftheir activity, they scored better on comprehension tests and were better ableto transfer their learning to other natural processes. Some ideas:

• Provide pre-activity content that learners will apply during the activity.
• Learners share individual results and conduct an analysis of differences, using provided tools or not.
• Learners externally create materials or artifacts to fulfill a purpose within the activity.
• Combine programmed interaction with real-life activities such as creating artifacts, making group decisions, or completing a project.
• Program the interaction to prompt learners to reflect on and record their lessons learned, using starter prompts or not.

Communicating with programmers

When we communicate with programmers—coders, that is—they are thinkingin terms of data and data storage containers, the building blocks of programs,and the commands, functions, and operators to manipulate them. Not that we needto remember this when communicating with programmers, but these conceptscommunicate their responsibility for converting your specifications into usefulcode.

With this basic understanding in mind, I asked Shannon Peevy, aninteractions programmer at the University of Nevada Las Vegas, a few questionsabout communicating with programmers. An important distinction Shannon andother programmers make is between the actual customer and intermediaries likebusiness consultants and instructional designers.

Q: What are your most commonly encountered issues working with yourcustomers?

A: Surprisingly, one factor seems to have unexpectedly diminished withthe world becoming more tech-savvy: unrealistic expectations. People in generalhave learned there are limitations to what software can accomplish. More commonissues these days:

• Timidity in defining the vision. Too many times, customers approach the project with low expectations, saying they want something like a drag-and-drop activity when they really don’t. “Better to give me the organic, pie-in-the-sky vision of what you want to do, and then we can talk about specifics and limitations.”
• Undefined requirements. Having only a vague sense of what they need with the expectation that the programmer can fill in the blanks. “Be sure you know what you want before asking someone to code it.” Specify every item that should be available to the end user and what it’s supposed to do. Most importantly, what are the rules, the logic, of the activity; what is to be accomplished and how? “This is where the intermediaries come in—helping the customer define requirements.” Think in terms of components, interactions, and bridging with other learning activities.
• Lack of involvement. Typical of most technology projects, the customer submits the request then expects a fully developed solution at deadline. “Few understand the time required to work through the stages of development with the programmer, essentially consisting of testing and feedback on the customer’s part.” Again, intermediaries can help tremendously with this necessity.
• Feature creep. Largely a function of undefined or poorly defined requirements, customers frequently want to add features and functions midway through the development process. “Because changes are so labor intensive, programmers resist these requests as much as possible in favor of offering new functions in the next product version.”

Q: What is the ideal development process from a programmer’sperspective?

A: “Especially with interactivities, agile [methodology] is the way togo. Each step is a loop where the programmer creates, the customer providesfeedback, and the process iterates until the customer approves, and then we moveto the next stage.”

1. We work out the initial vision and rules. As stated above, the clearer the customer’s requirements, the quicker the project can proceed.
2. Initial interface mockup of the top level and one or two second-level interactions. “More and more often we use graphics to create initial mockups before actual coding begins.” Customer feedback and approval.
3. Coding for the top level and one or two second-level interactions. Customer feedback and approval.
4. Programmer completes the build with small feedback loops as necessary.
5. Complete user testing with feedback.
6. Fixes as necessary.
7. Final testing and approval.

Q: As an interactive programmer, what are some limitations you’veencountered while trying to meet customer requirements?

A: Three things come to mind:

• “Because programming is so rules driven, it’s often not possible to build for Bloom’s higher levels like analyzing, evaluating, and creating. For these levels, we can build pieces of the larger goal that can be integrated into a whole activity or process.” For example, using interactivities as the basis for discussion and problem solving.
• “LMS integration is another concern. While SCORM is simple in concept, we have experienced multiple obstacles to making it work reliably. Many of us think [the Experience API] will provide better results.”
• Time is probably the most limiting factor. “Even simple interactivities take two to three weeks of a programmer’s time—which is someone’s money. It quickly becomes a matter of return on investment. Of course, we like to repurpose and standardize some components, but that has its limitations too.”

Conclusion

Whether you are working with coders, HTML pages, or authoring tools,it helps tremendously to structure your programmed interactions into componentsand their interactions with the end-user. This is the realm of theinstructional designer or business consultant working with the customer. Theconstruction, the coding and linking, follow.

References

Aldrich, Clark. Simulations and the Futureof Learning: An Innovative (and Perhaps Revolutionary) Approach to e-Learning.San Francisco: Pfeiffer, 2004.

Kiili, Kristian. “Participatory multimedia learning: Engaginglearners.” Australasian Journal ofEducational Technology. 2005.

Moreno,Roxana and Richard Mayer. “Interactive Multimodal Learning Environments.Special Issue on Interactive Learning Environments: Contemporary Issues andTrends.” Educational Psychology Review,19(3). 2007.