Programmed Interactions: Spell It Out First

Written By

Kevin Wilcoxon

June 16, 2014

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

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

Some basics

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

Interaction components

According to Kristian Kiili, Designing programmed interactions needs to 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 of interactivity between learner and system.

Dialoguing—Learner receives questions and answers or feedback to his or her input—for example, using context-sensitive help, clicking on a hyperlink to access additional information, interacting with an avatar who guides the learner through the activity, or making selections and experiencing the consequences.

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

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

Searching—Learner finds new content material by entering a query, receiving options, and selecting an option—for example, using help and search functions.

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

Bridging to external activities

You can increase the number and scope of learning objectives by linking programmed interactions with other learning activities. In this way, when you integrate the learning object with the larger learning enterprise it is more likely to achieve its objectives. Moreno and Mayer cite an example where students failed to improve their comprehension when asked to order the steps corresponding to a natural causal event (e.g., rain, drainage, flooding). When they modified the interaction to prompt students to reflect on the results of their activity, they scored better on comprehension tests and were better able to 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 thinking in terms of data and data storage containers, the building blocks of programs, and the commands, functions, and operators to manipulate them. Not that we need to remember this when communicating with programmers, but these concepts communicate their responsibility for converting your specifications into useful code.

With this basic understanding in mind, I asked Shannon Peevy, an interactions programmer at the University of Nevada Las Vegas, a few questions about communicating with programmers. An important distinction Shannon and other programmers make is between the actual customer and intermediaries like business consultants and instructional designers.

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

A: Surprisingly, one factor seems to have unexpectedly diminished with the world becoming more tech-savvy: unrealistic expectations. People in general have learned there are limitations to what software can accomplish. More common issues 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's perspective?

A: “Especially with interactivities, agile [methodology] is the way to go. Each step is a loop where the programmer creates, the customer provides feedback, and the process iterates until the customer approves, and then we move to 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've encountered 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.”


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


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

Kiili, Kristian. “Participatory multimedia learning: Engaging learners.” Australasian Journal of Educational Technology. 2005.

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

More Design

You May Also Like