An Interview with Michigan's Carl Berger
An Interview with Michigan's Carl Berger" The Technology Source, September/October 2002. Available online at http://ts.mivu.org/default.asp?show=article&id=1034. The article is reprinted here with permission of the publisher.
Carl Berger is a pioneer in adapting information technology tools to enhance the educational process. Beginning his work with computers in 1957, Berger developed statistical software during the '60s and simulation software during the early '70s. His first major attempt to create educational simulations came in 1971 when, as director of education at the Detroit Edison Company, he developed the Electric Power Company Simulation. The process of creating this simulation sparked Carl's interest in how students learn to use technology. He then joined the faculty of the University of Michigan in 1972, started developing simulations for classroom teachers, and later explored how students improve their process skills by using microcomputers. A 9-year stint as associate dean and dean of education for the University of Michigan did not dampen his enthusiasm for continuing this kind of research, and, since his appointment as director of instructional technology in 1989, he has continued and expanded his work in higher education. I was able to talk with him after his presentation at the EDUCAUSE conference in Indianapolis in October, 2001.
James L. Morrison [JM]: Carl, how long have you been working in instructional technology?
Carl Berger [CB]: I have been working with instructional technology since 1971, when I created the Electric Power Company Simulation. We employed an early common computerthe PDP 8to help students realize that using electric power while protecting the environment involves tradeoffs and that there is no one, easy answer to such a problem. My in-depth work with instructional technology began at the University of Michigan in 1978, when we studied then brand-new microcomputers. We discovered not only that there was a significant difference between how boys and girls use technology, but also that this difference occurred primarily because of unequal access. If you literally forced schools to provide equal access for girls, then, after the second or third implementation of whatever project you were developing, you could not tell the difference between them in access, performance, or final outcome. The existing research at the time, which had not addressed this problem in much depth, always concluded that boys perform better with computers than girls. Since that time, I have been searching for ways to apply technology to help students learn. In addition, I've been looking for computer programs that provide much greater access for students that have differing learning styles. The next killer app in education must be able to take into account student variation in learning styles.
JM: What do you mean by "killer app"?
CB: A killer app is a ubiquitous tool that faculty, students, and support staff use in instruction, research, and learning within the university setting. For example, the early word processors that functioned more like typewriters with special features transformed into the current killer apps, like Microsoft Word, Microsoft Excel, and AppleWorks. I think that the next killer app will be so easy to use and so ubiquitous that its innovations will be comparable to the difference between the command language that we used to have and the WSYIWYG (what you see is what you get) design of the interfaces that we now have.
JM: Could you share your vision of the future of the killer app?
CB: I envision a student walking to campus one day when, suddenly, something inside her book bag starts to chime. She reaches down and pulls out a miniature computer, one even smaller than what we have now. She opens it, because it is chiming to tell her that she has received a series of messages, notes, and comments concerning group assignments that she is completing for a class. Of course, the entire campus is wired; her notebook computer chimed because it knew she had walked onto campus. She sits down on a bench and opens several documents on her computer. She finds a pen and starts sketching on the screen and/or typing on the keyboard. She makes changes to an assignment, circles them, sends a note to one of her friends, sends another note to her professor, and closes her computer, which chimes with a different tone to let her know that all of her messages have been sent. She continues her walk across campus, never realizing that she just used the next killer app.
JM: Can you describe the actual components of this killer app?
CB: We are building the pieces right now. Many universities have already installed the first piece, the technology for wireless communication, on their campuses. In addition, some institutions are beginning to develop "push" and "pull" technology. Pull technology describes when I sit down with my computer, open a browser, and click on a link to search for an item. In this context, I pull the information to me. Push technology describes when my computer automatically transfers new information on a given topic and sends me a message. In other words it pushes that information to me. The combination of push and pull technology is not quite here yet, but it is on its way.
We are also putting other pieces into place. One of these includes the portal technology that we are implementing in our university systems, portals that students can modify and personalize to give them information about their activities, course assignments, and notices from the university. So far, though, universities have not adequately linked these portals to their course management systems (course tools like Blackboard and WebCT) that allow a student to submit course assignments online. Some of the pieces in the background are even more important, because they can connect pieces of university-wide information (course catalogs, student billing, transcripts) to the student portal. One example of a consortium working to link the various pieces of information together is the IMS Global Learning Consortium, which creates specifications for how to combine these tools and helps university software designers build these specifications into their programs from the very start. Though its language is highly technical, the IMS project provides the specifications for the standards that we will all need to fit numerous independently developed programs together. Another useful tool, Multimedia Educational Resources for Learning and Online Teaching (MERLOT), holds no resources itself but instead refers users to existing resources, all of which are available for anyone's use. One such resource for understanding analysis of variance, for instance, is both proof of the power of using an inspired applet for teaching and learning, and also a fine example of a tool that will provide more information in a few minutes than many of us learned in entire stat classes! MERLOT brings that learning module to faculty by having a search engine designed for education and a review of the learning modules by discipline experts.
Much of what I have just described has been driven by the kind of administration that we do in our teaching and learning (e.g., taking care of assignments, class scheduling, announcements, resources). It is one thing for administrative tasks to drive an application; however, it is another thing entirely to have pedagogy drive an application. In other words, what knowledge do we have about teaching and learning that we need to use in creating the next killer app? We have to create a tool that does more for each individual student than current applications do. It is not enough for students to be able to see their assignments. The next killer app must have other features that, for instance, will identify visual learners and offer them links that demonstrate visual approaches as well as literal and analytical approaches to learning to provide them with the richest possible learning experience.
JM: In your EDUCAUSE presentation, you used a term that I hadn't heard before: "WINWINI." What does this mean?
CB: For students, faculty, and researchers, WINWINI means "what I need when I need it." For faculty and researchers, this term implies that the university information network has enough intelligence and communication to recognize each user and offer the data that will be most useful for that person's research. Students see the assignments when they need them and receive the appropriate resources when they need them, rather than instructors overwhelming them with an enormous reading list at the beginning of a course. The next killer app will include not only a change in how we bring technology together but also a subtle change in how we approach teaching and learning. Let's describe that change.
My colleagues and I at the University of Michigan are conducting a study of how students work in a collaborative laboratory. The students gather data, enter it into a large database, and then form teams to analyze the data, build PowerPoint presentations, and deliver these presentations to the class. If you are interested in seeing how this works, visit my Web site and look at the project titled "Understanding Student Perceptions of Collaboration, Laboratory and Inquiry Use in Introductory Chemistry." As you will see on that site, we noticed that different groups of students learn in different ways. Some students have a wonderful ability to organize presentations. Others are visually oriented and excel at analyzing data, and still others excel at understanding the content of chemistry. We are beginning to realize that, in the same way that we try to match teaching styles to students' learning styles, we should also take advantage of the way different students learn, not by teaching them directly, but by allowing them to teach each other. When we allowed students to teach one another, students' success in the course increased dramatically.
JM: What role did technology play in this project?
CB: Its role was very straightforward. Each group of students gathered data with slightly different parameters. We used a specifically designed data gathering program to build a database in which the data points, under different parameters, are displayed in a data table. The students could then take these data and use a spreadsheet program with graphing tools to graph the data, convert it into a slide, and present that slide to the class at large. In this process, obviously, we used several individual tools. In a killer app, those individual tools will all play a role within the larger framework of the killer app, just as today you can use AppleWorks or Microsoft Office to move materials seamlessly from one application to another.
JM: How do you know what components will play a role in this new killer app?
CB: Those of us interested in the support of academic technology around the country have talked about the pieces, and we have talked about what we want the application to look like, but determining its actual composition will be crucial. We have seen project after project develop a product that we think people will use, but they never do; these products languish on the market for a while and then disappear. Our first step in determining the composition of the killer app must be asking students and faculty what they need.
At the University of Michigan, we developed two surveys for this purpose. We have roughly 30,000 students at the university, and we sent out a survey to a random, representative sample of about 3,000 students and received 1,583 responses. We also have roughly 6,000 faculty; we surveyed a random, representative sample of 1,500 of them and received 743 responses. Since this killer app will be heavily Web-oriented, we asked our respondents how often and for what purpose(s) they currently use the Web; we also asked what they want to use the Web for in the future. In addition to sorting this data, we performed a factor analysis to help us place student and faculty wants and needs into certain categories. One of the surprises was that students did not choose "performing better in classes" as a top priority for the killer app; instead, they want to be able to transfer files and information across the university system without difficulty. As indicated on their survey, students realize that communication is crucial, that it has to be invisible, and that it has to work all the time. Our faculty survey indicates that faculty want integrated tools to help carry out real instruction. They do not have the time or skill to piece together multiple tools; they need an integrated tool.
The bottom line is this: Why do we want the next killer app? Why is it not enough just to use the individual programs that we have now? Both faculty and students express a need to use their time more wisely. There is so much information now that we have had to change our modes of teaching and learning to help the students create knowledge. It takes students time to think about, reflect upon, and create their knowledge. We should strive to offer them the most efficient tools possible to give them the best chance to be successful in this endeavor. So, the way that our understanding of teaching and learning has evolved makes it necessary for us to move toward the next killer app. We have the pieces, we have the understanding, we know what the faculty and students want, and we have the resources to respond to this need. The tough part is going to be convincing administrations that, though it will cost more to put this together than it did to install their current administration system, it is a necessary step. If we can secure administrative support, then we can have the "next killer app" about 10 years earlier than I currently predict that it will probably appear. We owe it to our students and our faculty to pursue it with all deliberate speed.
JM: Thank you, Carl, for sharing your thoughts on this exciting topic with us.hidden objects gamessimulation gamesmahjonghidden object gamespc games