CaBLE Tutors, or any truly interactive systems for that matter, are difficult to design because of the inherent complexity of the design process. This problem applies to all human-computer interfaces, but particularly to CaBLE Tutors because the designer must be able to predict and deal with a wide variety of learner actions. The learner’s role (i.e., telephone operator, human resources manager, etc.) must be carefully designed to compel the learner to pursue a variety of appropriate actions, it must be meaningful and interesting to motivate the learner, and the goals that the learner tries to accomplish through the simulation must compel him or her to perform the target tasks. Then relevant and realistic actions must be selected for the learner to take and an interface created that allows the learner to easily initiate these actions. Feedback must also be given to the learner, and a knowledge browser must be designed which will provide information on the knowledge domain in a way that makes sense for every context learners find themselves in. All of these components must interact successfully within the system to produce the desired learning goals. Furthermore, the Tutor is designed around a model of how an expert would accomplish these tasks, so the designer needs to know the knowledge, skills, and beliefs involved in that domain, as well as the mistakes that can be made and their natural consequences.
In addition, the designer must be able to generalize from an example to a new domain, which requires separating the surface features of a particular Tutor from the essential elements that must be included in every
domain. A designer must also adapt those features so that they make sense in the new domain and allow the learner to take actions particular to that domain. Consequently, it is extremely difficult to jump from reading about how to design a CaBLE Tutor, or seeing one, to actually doing it. In fact, it is difficult to design anything
by just reading about it --- learning is easier when you get a chance to do it in a meaningful, guided context. Therefore, following the learning-by-doing model, we are in the process of designing a CaBLE Tutor that will allow people to experience designing a CaBLE Tutor in a simulated and guided environment.
Learner’s Role
“The Recursive Tutor”, will allow learners to play the role of an educational software designer who has been asked to design a CaBLE Tutor for the fictitious Learning Company. They can choose from three domain areas to work in; domains are limited to three because the system must store information and expert models for each domain -- this would be impossible to do with an unlimited choice of knowledge domains. Also, since the goal of the Tutor is to learn design skills, not the knowledge associated with the chosen domain, this choice then
becomes a matter of simply selecting a domain that the learner is interested in -- and there is a good chance that at least one of the three choices will be somewhat interesting to the learner.
Learner’s Goals
A learner who is using The Recursive Tutor will be given the goal of designing a “successful” CaBLE Tutor to teach users the target goals and objectives specified for the knowledge domain he or she chose.
Actions
The actions a learner takes in The Recursive Tutor are similar to the things that would be done in the “real world” when designing a CaBLE Tutor, such as choosing a role, choosing a goal, choosing interface items that allow users to take actions and specify the meaning of actions to the Tutor, choosing interface items that will convey information and feedback to the user, specifying mistakes, and obtaining stories to use in the Tutor. Learners will execute these actions by selecting items on a tool palette. They can select input devices, such as buttons, calendars, telephones, or appointment books to allow their users to make choices. Feedback devices, such as meters, charts, character agents, or memos provide feedback to their users.
Resources
During the course of the simulation, the user can get advice from several sources. For example, a senior designer is always available to help whenever the learner asks for it by providing advice on multimedia design, tips for designing CaBLE Tutors, research findings, etc. The designer acts as a mentor, helping the learner determine what to do next by pulling out information from her desk to give to the learner, answering a question through a video, or modeling a skill, if appropriate. The information is stored in a hypermedia knowledge browser, but it is presented through the mentor, making the learner feel like he or she is interacting with a real person. The learner can also consult with a Subject Matter Expert (SME), who provides information pertaining to the knowledge domain. This SME is also a hypermedia knowledge browser, but again, to the learner, he appears and acts like a real person who answers questions by retrieving the requested information from the computer and presenting it in a way that a “real” SME would.
Stories
Throughout the simulation, learners make choices and take actions that will affect the success of the Tutor. There are no right or wrong actions, but some combinations are more optimal than others. Therefore, it is important for learners to choose goals, roles, actions, or resources that will encourage their users to practice the skills they want them to learn. For example, some combinations will allow users to execute more appropriate actions or will facilitate learning the goals for the Tutor, while others will detract from that process. When the user makes a critical mistake during the design process, a videotaped “expert” will arrive who recalls a story of a similar mistake he or she made when designing a CaBLE tutor and how it was successfully handled.
Learners will also be able to get feedback at any point by pilot testing their design with potential end- users. They will receive comments from their users about how easy it was to use, how much they learned, how they liked the Tutor, etc. If end-users liked the Tutor and found that the interface was easy to use, they will provide positive feedback about the experience; if they were frustrated because the actions they were allowed to take did not allow them to accomplish their goals, they will provide feedback accordingly.
Sample Interaction
The learner begins by selecting a project and is then given a description of the facts, skills, beliefs, and concepts that the client wants to be taught through the Tutor. In this example, the learner chooses the “Political Process” knowledge domain to work in, and is given a list of learning objectives from the client, such as “learn how to make an informed decision about a political candidate in an election”.
After reviewing the learning goals for the simulation, she begins to design the Tutor by making a series of choices and taking any one of the available actions. She clicks on the “Role” button first to see a list of possible roles her users can take, such as Candidate, Voter, Campaign Manager, or Senator.
After choosing “Campaign Manager,” she clicks on the “Goal“ button to decide what goal her users will pursue [see Figure 1]. She chooses from the following list: create a platform, raise campaign funds, raise a candidate’s standing in the poles, get a candidate elected, or win a debate. She chooses “get a candidate elected.” This is an important selection because the goal must motivate users to complete the goal tasks, and must require them to take actions that will help them learn the objectives. Thus, there are no are no right or wrong combinations of learner goals and roles, but certain combinations will be more effective than others.
Goals Get candidate elected Raise campaign funds Win a debate Create a platform Raise poll standings
Role Pilot Test Consult SME Help! Why? Objectives Interface Mistakes Now What? Story Lib Goal
Figure 1: Learning Goals
Now the learner chooses icons on the tool palette that represent interface items that will allow her users to execute actions. She chooses the calendar tool and drags this icon to the corner of the screen [see Figure 2]. A dialog box appears which asks her to specify what should happen when the user clicks on the calendar; she chooses actions, such as “schedule a press conference,” or “meet with voter groups.” The learner also chooses the newspaper tool, and a dialog box appears asking the learner to specify actions that can be taken through this interface item. She chooses “write an article describing the candidate’s platform” and “write a press release.” At this point, if she realized that the actions a Campaign Manager would take will not allow the user to accomplish the goal of the simulation or the learning objectives of the Tutor, she could change the role or goal.
Tools button March Extra fhsk ftert ut fhsk ftert ut 0 1 Memo March Screen 1 Calendar Tool
What do you want to happen when the user clicks on a day?
Actions Huh? OK Cancel Meet voters Meet my opponent Role Pilot Test Consult SME Help! Why? Objectives Interface Mistakes Now What? Story Lib Goal
Figure 2: Interface Items
Now she specifies which combinations of actions represent mistakes. She notices that one mistake a user might make is to schedule a press conference without creating a campaign platform. She specifies this order of actions as a mistake and clicks on the “Story” button to generate a story pertaining to that mistake. After
searching through the story library, she does not find anything useful and decides to generate a new story. When she clicks on “New,” an interview window opens which contains a series of questions that she could ask an expert to generate a better story. She clicks on the question “Have you ever gone into a conference unprepared?” The expert responds by telling the story, and the learner decides to keep that story by linking it to the mistake.
Now she adds some feedback indicators to the interface. She chooses a meter tool by clicking on the meter icon in the tool palette and dragging it to the screen. A dialog box appears which asks her what the meter will measure. She chooses “projected voting results” and labels the ends of the meter with 0% and 100%, respectively; her meter is a voting poll which measures a candidate’s projected share of the votes ranging from 0% to 100%. This will notify her users of how well they are doing during the simulation.
The learner now clicks on the “Pilot Test” button to test her design with her end-users. A screen appears containing feedback; users indicated that they liked the simulation but they couldn’t do things in Tutor that they would have done in the real world. Based on this feedback, she decides to change her design and clicks on the “Advice” button. The Senior Designer appears and asks how she can help. The learner clicks on the feedback item she did not understand and then clicks on the “Why?” button. The mentor responds with a video clip describing some of the decision points the learner might want to “rethink” pertaining to that feedback item.
Conclusion
We believe that the value of the Recursive Tutor lies in its ability to deliver a hands-on learning experience that models the principles it is trying to teach. This system provides an opportunity to practice designing a CaBLE Tutor with the support and guidance that is not readily available in reality, as well to experience using a CaBLE Tutor to understand what this feels like from a user’s perspective. Because the actions that are taken in the simulation are only those that are integral to the ability to design CaBLE Tutors, learners can practice in a simplified environment. Learners also have the benefit of a hypermedia browsing system containing helpful information they will need as they execute a task. And, more importantly, they can practice and get feedback without the complications of having to build an actual Tutor. Thus, the Recursive Tutor is truly an example of “practicing what you preach.”
References
[Collins 1994] Collins, A. (1994). Goal-based scenarios and the problem of situated learning: A commentary on Andersen Consulting’s design of goal-based scenarios. Educational Technology, 34 (9), 30-32.
[Collins et al. 1989] Collins, A., Brown, J. S., and Newman, S. E. (1989). Cognitive apprenticeship: Teaching the crafts of reading, writing, and mathematics. In L. B. Resnick (Eds.), Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser (pp. 453-494). Hillsdale, NJ: Lawrence Erlbaum Associates.
[Feifer 1992] Feifer, R. G. (1992). Cognitive issues in the development of multimedia learning systems. In S. Reisman (Ed.), Multimedia Computing: Preparing for the 21st Century (pp. 285-322). Harrisburg: Idea Group Publishing.
[Feifer et al. 1991] Feifer, R. G., & Soclof, M. S. (1991). Knowledge-based tutoring systems: Changing the focus from learner modeling to teaching. In Proceedings of the International Conference on the Learning Sciences, (pp. 151- 157). Northwestern University, Evanston, IL: Association for the Advancement of Computing in Education. [Ferguson et al. 1991] Ferguson, W., Bareiss, R., Osgood, R., and Birnbaum, L. (1991). ASK systems: An approach to
story-based teaching. In Proceedings of the International Conference on the Learning Sciences, (pp. 158-164). Northwestern University, Evanston, IL: Association for the Advancement of Computing in Education.