Professor James Fleck visited the IDEAs lab on June 4th, 2004 from the Management School and Economics at the University of Edinburgh, to present a talk on "Processes of Innovation and Design for Usability".
This was a very interesting seminar, if not immediately relevant to my own research. Not only was some of the content fascinating, but the method of presentation was also novel. Professor Flack uses mindmapping software to prepare his presentation and then uses the mindmap as a navigation tool during the presentation. By clicking on a mindmap element, a separate page would be opened where he could explore that concept in detail or perhaps an image clip launched.
Here, belatedly, are a copy of the abstract and my notes from the seminar.
In this seminar I will outline a range of theories of innovation within the broader context of technological development, to draw lessons about how the design process may be facilitated or constrained, especially with regard to usability. The discussion will be grounded with reflections about several empirical cases. These will include the design of a particular "smart Product" (Persona--the electronic contraceptive) and the development of a "Personal Learning Appliance" for a new e-learning initiative at Edinburgh (The Global Innovation MBA--GIMBA).
Conclusions will address the need for practical trialling; the need for mapping the space of behavioural interactions (behavioural ergonomics?) and the need to overcome "default satisficing behaviour" among prospective users.
Technology, according to Pacey, is only successful when technological, cultural, and organizational components are all in place. Ownership, for example, in the case of a water well is important in keeping the pump running and maintained. This is one theoretical underpinning to understanding the process of innovation and designing for usability.
One of the fascinating case studies that Professor Fleck discussed was about the robot milking machines. Mackie's of Scotland make ice-cream from the milk of their own Jersey herd. They were interested in increasing milk yields and decreasing the cost of human labour required to obtain the milk. They implemented a series of portable robotic milking stations in the fields. Using RFID or some such similar technology, when a cow comes to the milking station, she can be identified and the milking station automatically configures itself to milk that particular cow. Milk yields rose by 19% in the first year. It took the cows three months to adjust to the new system. It took the human staff almost a year. It was easy for the cows to adjust to because it required very little training on their part. They went to get food when they were hungry. They went to be milked when they felt full. The process here also had an unintended side benefit. While the primary goal was to increase milk yields, because the opportunities for human intervention in the supply chain (milk to ice-cream) were significantly reduced, the liability was subsantially reduced. Their cost of implementation was quickly repaid by the savings on the liability alone. Good for the cows. Good for Mackie's. Good for the ice-cream too.
One problem of implementing new technology is that people are reluctant to change their behaviour of usage beyond what works for them. Professor Fleck called this "default satisficing behaviour." In many cases, this manifests iteself as resistence to learning anything beyond basis usage of a piece of technology. Innovation and technology requires many components (bits and pieces from many seemingly unrelated fields) and customer context is important.
With respect to learning, we need to realize that in a bricks-and-mortar university, learning is an interaction between the instructor and the students, not between the student and the materials.
David Jonassen visited the IDEAs lab on May 11th from the University of Missouri to present a talk on "Model-Building for Conceptual Change (Cognitive Tools in Action)". While this isn't (or so I thought) related to my own research or interests in any way, we were all encouraged to attend if possible and I'm always interested in talks about learning in general. Here, belatedly, is a synopsis of my understanding of his presentation.
The key underlying principle seemed to emphasize having people fail in their problem solving attempt at some issue because then conceptual change has a change to be engaged and then students will learn. This failure need not be catastrophic; in fact, it probably should not be, I would say, or the failure would foster a strong sense of discouragement, which is not going to get a student into the "learning zone." So, how do you put students into a non-threatening environment where they can safely experiment and fail? David Jonassen's idea was to encourage them to engage in model building which demonstrates their conceptual understanding of the problem/issue at hand. When learners build models,their understanding of the problem domain is deepened because you cannot model what you do not understand. Model building also allows you, as the instructor, to view the learner's level of conceptual change as their models evolve. It is therefore possible to assess their underlying understanding without resorting to formal assessment tests. Finally, David Jonassen suggested that model building also improves critical reasoning and thinking because model building forces the model builder to examine the process and problem solving methodology.
David Jonassen researches (among other things) the use of technology in educational settings to improve understanding. More information on his approaches to problem solving are available from on the following web site page: http://tiger.coe.missouri.edu/~jonassen/PB.htm.
I think this is some interesting research, but obviously not applicable to every learning situation. Physical processes, like volcanos, weather, chemical reactions, etc. are very appropriate for model building. Or maybe I just need to change my understanding of what constitutes a model? For example, I'm teaching students how to program in JavaScript. In a way, a program is sort of like a model and we give students programming projects where they model some kind of answer to a stated problem to demonstrate their understanding of the process. Most students do not implement the solution correctly intially, so they need to refine their understanding of the problem and its solution over several iterations. Failure is forcing them into a state of conceptual change and as they repair their assumptions and their "model" code, they are learning valuable lessons about what works and the process of both developing and fixing. I guess, in fact, I've been doing this all along; I just didn't have a name for it!