Current Editor: Chris Merrill, firstname.lastname@example.org
Previous Editors: Mark Sanders 1989-1997; James LaPorte: 1997-2010
From the Editor
Applied Latin and a Caveat on Virtual Problem Solving
When I was an undergraduate student in industrial arts in the early 1960s, nearly every practical course required the preparation of three items before proceeding to build a "project." First, a complete set of plans had to be prepared. Second, a bill of materials was required. Third, the order of procedure, a listing of each of the steps necessary to complete the project, had to be submitted. This triumvirate was the sine qua non of instruction. Incidentally, the notion of a required project, where every student followed the same set of plans, was abhorred in those earlier days just as it is today.
Having attended a private, parochial high school that emphasized Latin and other classical studies over more practical pursuits, I was ill-equipped to prepare the three requisite documents. I did the best that I could, but most of the problems that I solved were done, ad hoc, as the project was being built, rather than in forethought. What I actually did to complete the project and how it looked in the end were quite different than what my trio of documents had indicated. In the eleventh hour I decided to prepare a new set of plans, order of procedure, and bill of materials to reflect what I actually did to complete the project. I explained to the professor what I had done. Judging by the particular glint in his eyes, I was confident that I was not the first student to do my planning, ex post facto.
New computer graphics software has recently become available to technology education from several companies that enables the student to model ideas in three dimensions on the screen of the computer. The software is much easier to learn than the computer assisted design packages with which the field has become familiar. This software is much more intuitive and is based upon a "sketching" sort of algorithm in which students can quickly move a design idea from their head to the computer, worrying about the exact sizes and proportions of the parts and components at a later point in the development process. The objects created can be effortlessly rotated and viewed from any angle. Mechanisms can be simulated and tested virtually in far less time than the construction of prototypes or mockups requires. The iterative process whereby designs can be developed, evaluated, and redesigned requires little effort and students do not become bored and frustrated as they often do when building and revising a prototype over and over.
The new software significantly reduces compromises in designs, resulting in an increase in the quality of technological problem solutions that is analogous to the editing advantages of word processing software and the higher quality prose that has resulted. The conventional orthographic and isometric views can be quickly generated from the solid model when required. In short, this new genre of software enables students to develop nearly final solutions to technological problems before they actually begin to build the solutions. They confront many of the same design constraints and problems in the virtual world of the computer that they would confront when working with real materials. The reduction of material waste alone should garner the attention of even the more computer-wary teachers.
The new software enables students to design practically anything that might be built within a technology education laboratory. Traditional wooden products, solar collectors, structures, as well as the ever-pervasive CO2 powered vehicle, can all be designed with relative ease. In addition, the software allows students to design products that could never be built in a typical laboratory, opening up many new opportunities for learning. Examples are limitless, ranging from nano-machines to jumbo jets. I can personally attest that this software is engaging and fun to use!
Nonetheless, there are some potential unintended consequences, akin to Tenner's (1997) treatise on the subject. In the wake of this new design software, the problem-solving process might never go beyond the virtual world of the computer. Even modeling systems like Lego blocks have crossed the line into the virtual world, as evidenced in the article by Kurt Michael in this issue. Students can now virtually model a modeling system that, itself, is intended to model the real world.
There are compelling reasons to move technology education into the virtual world. The expense of the learning facility is reduced significantly since a computer lab requires far less space than a facility with real tools and materials whereby students can actually build what they design. Student management problems might be reduced as well, providing that students remain engaged with what they are doing in their virtual world. Concerns about student injuries and the resultant liability by the school system would be on par with most other school subjects. The environment in which the students learn might be considered more consistent with the advanced world outside the school. Certainly, the virtual world is "cleaner" than the world in which real tools, machines, and materials are used.
So what might some of the trade-offs be in ending the design process at the virtual stage? What do students learn in the design phases of solving a technological problem compared to what they learn in actually building the solution? What role does building a solution play in psychomotor development? What are the affective outcomes of the design-and-build experience? Is there something unique that occurs when students bend, push, feel, smell, and see real materials and how tools interact with them? What are the unique contributions that technology education offers to the teaching-learning process? Most experienced teachers would agree that both designing and building are essential in the education of the child. Yet this assertion and the questions posed before it beg for research evidence.
Calls are increasingly being heard, especially from outside the field, for evidence of what students learn from their experiences in technology education. This has been a perplexing demand on my psyche for some time now. My thoughts consistently lead me back to the same, simple conclusion, as naïve as it may be. That is, are not the solutions to the technological problems that students design and build the defensible evidence we are seeking? Would not this evidence be parallel to measures of achievement in other subjects that focus on doing, such as solving a mathematical problem, playing a musical instrument, and throwing a clay pot on a potter's wheel? If the evidence is acceptable, then we need to focus our efforts on the nature of the problems that we engage our students in solving, how they can best be sequenced and articulated, how they can be assessed with reliability and validity, and how they can be made universally exciting and challenging with respect to gender and ethnicity. Or, on the other hand, is the evidence we seek in the form of filled-in blanks on a worksheet or a quiz? Et sententia tua, conlegium meum?
Tenner, E. (1997). Why things bite back: Technology and the revenge of unintended consequences. NY: Alfred A. Knopf.