Aucbvax.2447 fa.works utzoo!decvax!ucbvax!works Sun Jul 26 21:50:03 1981 mundane systems >From JWALKER@BBNA Sun Jul 26 21:46:04 1981 I have to voice my strong support of Joe in his message against "mundane" systems. The original message advocating mundane systems used an analogy of a car -- you choose a boring automatic because you don't care what wonderful things you might be able to do with a standard transmission. Let's point out a few things that make this analogy somewhat less applicable to the current case (system/software design). Notice that with the kind of technology people are accustomed to, once you choose one (automatic), you can't have the other (standard). (This can lead people into defending their choices with more reasons than they originally had for making the choice. Some psychologists talk about related phenomena under "cognitive dissonance".) With the kind of technology we use, you can either follow the same design philosophy -- make things in a limited number of flavors and make people choose -- or you can design to support redesign by the purchaser. Surely with the flexibility of computers behind us, we can do at least as well as the kludge in the car that chooses 4, 6, or 8 cylinders depending on load, mileage goals, or whatever. People don't like the illusion of choice nearly as much as they like having the choice. The reason that so far we don't find ordinary people looking for software modifications is that they don't expect to be able to have them. (The old technology of course has molded people's expectations about the new one.) While I am on the car analogy... I hear a lot about providing systems for people who want to be able to use a computer without any training or practice. How many people do you know who wanted to just jump in and drive a car without any training or practice? (Not many!) Why do you suppose that difference exists? Consider that a car has one primary purpose -- transportation. They all have standard components and operating procedures. Even people who have never driven know a lot about cars, for example, that they have a little slot where you put a key and turn it in order to start the engine. The point is that cars are simpler in purpose and operation than computers, yet people don't expect to just hop in and drive away until they know from cars. Maybe the real lessons in this analogy come from considering training, learning, and transfer issues. The ideal way to provide software is to offer something that a new user who knows about the application of the software (for example, editing, drawing) can start using it with the help of a good summary and maybe 15 minutes of explanation. The next hurdle to pass is in discovering that things can in fact be changed. A well-designed and documented program helps you make this discovery and then provides good support tools to help you find out what it is possible to change and how best to do it. Jan (JWalker@BBNA) ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.