|
October 1, 2002 Math Design: the what and the why of it
Why do we need to design mathematics? Because currently, most onscreen mathematics is not designed, or at least not very well, and it shows. Allow me to elaborate: over the past several years, I’ve spent considerable time looking at examples of onscreen mathematics materials (CD ROM and web), particularly (but not exclusively) at educational materials. It’s been largely a disappointing experience: though the materials are often well produced, entertaining and so on, much of what I’ve seen tends to be off the mark to some degree when it comes to actually communicating the mathematics it purports to or when it comes to building appropriate and correct mathematical intuitions. An example:
Other examples:
And so on. What’s missing in most cases is a clear, intuitive and appropriate connection to the mathematics. However, it often takes quite a bit of analysis and puzzling over details to see exactly where the connection breaks down; many problems have quite subtle causes. Of course, given the present immature state of the technology, a disconnect between the math and its interactive behaviour onscreen is understandable: it’s hard enough just to get the stuff up there without worrying too much about design details. This means, too, that the teacher or mathematician initiating the onscreen project is often not the programmer who ultimately designs how it will look and function, a separation which exacerbates the disconnect. Nevertheless, as authoring tools become more reliable and easier to use, it becomes more and more important to discover (or invent) the appropriate interactive grammars and idioms to communicate with them - to learn to design with them. Can’t we just apply UID (user interface design) principles from computer science? Yes, to a limited extent, but that’s not really what’s needed. There’s a major difference between UID and mathematics interface design (MID): the goal of UID is to enable the user to accomplish tasks as quickly and effortlessly as possible, ideally without having to devote much thought to the process. The goal of MID, however, is to enable/encourage the user to perform tasks with as much mathematical understanding and/or learning as possible - to encourage the learner to think about what he or she is doing. The two goals are almost diametrically opposite. An example: Tangrams are often used to teach children about geometric transformations - translations, rotations, reflections, etc.. If the goal were merely to solve a tangram puzzle as a game, a good UID might allow a piece to be rotated easily by dragging it around its centre, for example, requiring a good eye for angles but little more. A good MID, on the other hand, might ask the child to decide on an appropriate centre for the rotation and to supply a numerical value for the rotation angle in order to move the piece into place - perhaps a bit slow as a game, but more interesting as a puzzle and a learning exercise? (For more on this point and the design of onscreen tangrams for education, see the paper Direct Object Manipulation vs. Direct Concept Manipulation: Effect of Interface Style on Reflection and Domain Learning.) Both UID and MID are important for onscreen mathematics; the key is to use each appropriately. John Sweller’s cognitive load theory is one useful way to think about this: use UID to minimize the cognitive load of tasks extraneous to learning (e.g. website navigation), and MID to structure the cognitive load that contributes to learning (e.g. interaction with concepts). Isn’t MID then just producing simulations, i.e. onscreen models of “real world” mathematics? Ah, but simulations of what, exactly? There’s a fundamental difference between modeling concrete, real world situations and modeling abstract mathematical ones. An onscreen physics simulation of colliding objects, say, is an abstraction of a real world collision: the onscreen objects are simplified representations of the real objects, and their motion and interactive behaviours are modeled on consistent and well understood laws of motion, elasticity, etc.. Onscreen mathematics goes in the opposite direction: it starts with abstract concepts and then places representations of those concepts on the screen. Though not actually “physical”, these representations are generally much more concrete than their ancestors; they typically have a visual forms that can be moved and modified, for example. But their abstract ancestry means that they come to the screen largely without pre-determined laws of motion and interaction. These laws have to be derived somehow from the objects' abstract mathematical behaviours or invented, and this can be problematic. An example: Probably the most striking occurrence of “concretization” in onscreen mathematics is the behaviour of circles and other objects in dynamic geometry programs. A near universal observation for those who play with such programs is that these geometric objects somehow feel and behave like physical objects. Suppose we have one fixed circle and another of equal radius moving past it with its centre constrained to a line through the first circle’s centre. When the circles are close enough but not coincident, they intersect in two points. Are the two points after coincidence the same two points as those before coincidence? and if so, which is which?
Which is correct? If we go by the principle that continuous motion should produce continuous consequences, then Cinderella avoids the sudden switching of the intersection points, and is more appropriate. But now suppose the centre of the second circle moves only very close to the centre of the first, along a line parallel to the original line. In both programs, the intersection points do a quick flip around the stationary circle as the other moves by. If we go by the principle that small perturbations in a configuration should produce only small changes in behaviour, then Sketchpad's flipping behaviour is more natural. I'm not arguing for either conclusion here, merely pointing out the problem. In fact, we have no real way of deciding this issue: it's not something that classical geometry has ever had to deal with, and we have no "physical" universe of points and circles to arbitrate appropriate behaviours. Here and elsewhere in onscreen mathematics, we will somehow have to make such decisions: by deriving behaviours from abstract mathematical relations, by choosing essentially arbitrary conventions, or otherwise. Onscreen mathematics is not just a matter of developing simulations of well-understood mathematical behaviour. --------------------------------------------- It's clear (I hope!) that mathematics design, like many other forms of design, is an important factor in the creation of quality onscreen materials for education. It should be equally clear that, while other design disciplines like UID can contribute a great deal to the subject, mathematics design has its own unique issues to contend with, and that contending with those issues requires a very clear and subtle understanding of the mathematical ideas to be communicated in the design. My goal in starting Math Design is two-fold. First I want to understand what it is that makes onscreen math work well or not - the language, if you will, the grammar, idioms and vocabulary of communicating mathematics with visualization, animation and interaction. Second, I want to develop that understanding into design principles for onscreen mathematics that I can apply to produce high quality, intuitive onscreen materials for myself and for others. Postings will occur as I get time and inspiration for them. Any and all forms of feedback are welcome; please click the "Comment?" link at the end of each article.
|