Simulations in "The Future of Higher Education"

| | Comments (0)
The New Media Consortium recently published its study on the future of technology in higher education. For the most part it was pretty much as I would have guessed. A couple things stuck out for me, though... 

"Online gaming and simulation software are cited by 54% of higher-education respondents and 59% of the corporate respondents as an innovation likely to be adopted among universities over the next five years."

And they go on to say...

"Teaching will become more outcomes-based and student-centered. Instead of focusing on memorisation of material by their students, instructors will focus on the application of knowledge to particular problems." 

This struck a chord for me. I really think that online simulations are an area, like gaming, that has yet to be exploited by educators. They can cover a variety of disciplines, from teaching medical students the process of intubating a patient, to business management students learning to deal with change in the workplace, to police cadets learning to make safe traffic stops, simulations give students a more outcomes-based approach to learning important problem solving skills that they just can't get from books. Simulations give students the opportunity to observe the situation and apply their knowledge. Facial expressions, body language, props, and the spoken word can all be clues to help the student make a decision. Feedback can be built into each situation to tell the student which clues should have tipped them off and what the best decision might be at each turn. A coach could also be called on at any time prior to making the decision who might give the student a hint by maybe suggesting something they may not be taking into account.

Simulations can take a lot of work to put together to be sure. The planning stage is most important. This would require a content expert working with an instructional designer to map out the role play and create an outline of the whole simulation. The main teaching points should be identified first and each scenario can then be built around the best way to teach each point in a realistic manner. This will eventually take the shape of a flow diagram, each box in the diagram representing an individual scene. Each scene might be categorized as either informational or decisional. Informational scenes of course would only be giving the student more building blocks on which they will base their next decision. A decisional scene may have more information, but will also pose a question with several possible answers. Each answer may send the student to a different scene in the flow diagram. Each answer may also be worth a set number of points. Each scene might also have a photograph or a video to let the student know what's going on. Students could get stuck in a loop of the flow diagram until they finally make the correct decision that allows them to proceed. Finally, when the student has made his way to the end of the simulation, they can be presented with  feedback on how they did, both in general or scene by scene.

Getting a good working flow diagram is probably the hardest part. The "engine" if you will, could be a Flash module that may only be two or three frames long. It will include an invisible counter that increments and would be the basis for which scene is loaded next. For instance, if the student picks choice number two, that choice may be destined to send them to scene eight. Once the counter is incremented to eight, all the data for scene eight will be loaded into the Flash module. Using a naming convention on the data for each scene would make it easy to load the data for that particular scene. The Flash module would have (depending on whether it was informational or decisional) a component for a video or photograph, a text area that can be dynamically populated, another for the question, radio button components to load the choices, and a Submit button.

The flow diagram will also supply the videographer (or photographer) with a handy shot list that could be put onto index cards. Each scene would have a description of what the video would be like, what would happen, and what the actors would say. So you could save a lot of time planning the video. It would not have to be shot in order. 

The flow diagram would also provide the data that a data entry person would use to input the information for each scene into a FileMaker Pro database, each record being a scene.You might have a scene title, body text, question, name of the movie, name of the JPEG background, the question, each possible answer, the destination scene that each answer would direct the student to if chosen, points associated with each answer, feedback associated with each answer, and what a coach might suggest the student to make note of. 

Once the data for each scene is entered and the videos and photographs are shot, the database would then be exported as an XML file and read into the Flash module. And it would  just run, feeding itself new scenes at each click of the Submit button. A small development team consisting of an instructional designer, a Flash developer, a videographer, and a few actors would be all that is needed to create some really engaging simulations. Once the main Flash module is created, you might not even need the Flash developer unless there are changes to the format. You could easily use the same Flash module to run other simulations and even games with entirely different content, so development time could be shortened quite a bit after the first iteration. The time savings between being able to reuse the Flash module "engine" and the efficiencies of creating a shot list from the flow diagram might just make creating simulations an interesting addition to our arsenal of engagement. 

 




Leave a comment

About this Entry

This page contains a single entry by PATRICK JOSEPH BESONG published on December 5, 2008 9:23 PM.

New video conferencing service at Penn State was the previous entry in this blog.

Which way from here? is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.24-en