Printer Friendly

ACM forum.

Designing Computing

Curricula

I was dismayed by the computing curricula report in the June 1991 issue (pp. 69-84). The authors claim to be providing a curriculum for all undergraduates in the nebulously defined "Computing as a Discipline" area. In fact, they have produced a curriculum which--while possibly adequate for computer architects and electrical engineers--fails completely to address the real educational needs of software engineers.

In specific, I draw readers' attention to the discrepancies in the "Summary of the Common Requirements." Architecture is allocated 50 lecture hours and operating systems get 31 hours. By contrast, user interfaces get (presumably half of) eight hours. Human factors and usability are nowhere mentioned. This may be an adequate curriculum for someone who will end up building circuit boards, but is far from acceptable for someone who must produce usable software systems.

In addition, the curriculum designers continue to separate the area of user interfaces from areas such as software engineering and social, ethical and professional issues. This false dichotomy had led to many an entry in Peter Neumann's "Risks" column. Undergraduates victimized with this curriculum will someday no doubt contribute their share of unusable systems and in-use horror stories to the field.

A curriculum designed for those of us who must build usable systems would balance this inequity by removing the separate section on user interfaces and blending in a real education in building usable systems into the sections on programming languages, software engineering, and social, ethical and professional issues.

I hope the task force will make this or a similar change before putting out a final curriculum report.

Alan Wexelblat Bull Worldwide Information Systems, Inc. 300 Concord Rd. Billerica, MA 01821

Response

The balancing of material within the common requirements among the nine subject areas is surely uneven. If the common requirements were all that an undergraduate program in, say, software engineering were to provide, then the user interface area would certainly be underrepresented. However, the article emphasizes that each undergraduate program should add depth to its curriculum by requiring advanced material that explores areas such as the user interface in much more detail. Of course, different programs will achieve depth in different ways, and the full report, "Computing Curricula 1991" provides several sample implementations that suggest some of these alternatives. One of the sample implementations, in fact, emphasizes the interests of software engineering programs, and in fact gives more emphasis to the user interface area than is found in the other examples.

Additionally, it would be inaccurate to conclude from the article that we are separating the area of user interfaces from that of software engineering or social, ethical, and professional issues (or any other area, for that matter). In fact, the provision of smaller knowledge units in these areas encourages curriculum designers to integrate user interface topics, software engineering topics, and other topics together within a single course. Again, the full report contains many examples of such integration.

We do want to correct the misconception that the full 154-page report has not yet been published. As the article points out, the report was in fact published in March 1991, and can be obtained directly from ACM. We believe that if Wexelblat had read that report, his concerns would have been fully addressed. We are grateful for readers' thoughts on the issues raised by these curriculum recommendations. We would welcome the opportunity to respond to other concerns and comments as they arise.

Joe Turner Department of Computer Science Clemson University Clemson, SC 29634

"Log On Education"

I am glad to see the addition of the column, "Log On Education," by Elliot Soloway to Communications. I applaud the editor's desire to promote dialogue about educational issues. My comments are about the first column (February, 1991, pp. 29-32).

It is unfair and unwise for Soloway to heap all the blame for education's ills at the schoolhouse door, specifically targeting "those directing our educational system." He seems to assume that today's children arrive in the classroom pert and fresh, untouched by all the problems of their communities and families, ready and eager to plunge into the "active" learning that s/he advocates. Of course this is untrue; the problems faced by "those directing our educational system" include every social problem in the book, from students who speak no English, to children of crack addicts, to the passivity and ignorance that come from a surfeit of television and a lack of the active pastimes that engage a child's mind. The effects of child abuse, high rates of divorce, and inadequate medical care (there are millions of children in our country whose families have no medical insurance) weigh heavily on the schools. Schools are mandated to help children with myriad "special needs," from physical disabilities to "attention deficit disorder," but they are given insufficient funds to meet these needs. We will get nowhere blaming educators who, in addition to daily confronting the ills we have visited on our children, also face a discouraging combination of increasing school populations and declining school budgets.

But let us ignore these problems for the moment. Do Soloway's proposed solutions to our educational problems, generally speaking, have merit? I think the answer is no. Soloway's main argument is that it does not matter too much exactly what students learn, as long as they learn how to learn. Since the substance of what is learned is unimportant, learning specific facts is not very useful. Instead, students should engage in constructive hands-on learning that emphasizes high-level problem-solving skills such as finding and synthesizing information. Computers in the classroom will encourage this kind of hands-on learning.

Soloway argues that education has been damaged by teachers' insistence on teaching a "core set of facts" (p. 29). The "core set of facts" argument is a straw man--it is easy to ridicule the idea that education consists of a rigid set of specific facts that everyone has to learn. Of course we reject such an idea. But that does not then mean that all substance ceases to matter. Students should have exposure to an intellectual foundation specifically composed of mathematics, science, art, music, geography, literature and history. Would an intellectual foundation composed of filmaking, basketweaving and break dancing be just as good? Carefully handled, these (admirably hands-on) activities could yield the general problem-solving skills that Soloway advocates, but I think it is safe to say that few would be satisfied in the long run.

The what of education does matter. We are always going to be revising course content to reflect changing sensibilities (I am as happy to read Chinua Achebe as Theodore Dreiser)--but do we really want students who are not conversant with the theories of Darwin, the literature of Shakespeare, the history of the Civil War, and the basic tenets of algebra?

Learning a laundry list of facts is clearly not an inspiring idea. But that does not mean dispensing altogether with facts. Facts have their place. Learning involves the inculcation of facts--there is no way to know what Darwin was talking about if one does not know what a finch is. The point is to go forward from there and do something interesting with the facts. Caching away a fact is not an end in itself; what we really want is to be able to understand things, for which facts come in very handy. One cannot construct an argument, or make a comparison, or render a judgment without recourse to facts. There is no shame in accumulating a fact; Soloway badmouths the learning of facts by labeling it a "passive" activity, but it is quite the opposite, and definity requires active cognition.

Soloway attempts to reinforce his argument against the value of learning facts by speaking of "decontextualized facts." The nonsense behind the specter of "decontextualized facts" is the notion that a fact is a disembodies wraith, connected to nothing, and thus meaning little or nothing. Who cares if Columbus arrived in the New World in 1492? A child may learn this fact in the abstract, and it may be relatively uninteresting at the time it is learned. But one day the child may hear about the Viking explorations of North America, and suddenly the date of Columbus's voyage becomes much more interesting. It is the same fact--perhaps something s/he parroted back on a test at one time--but now with this knowledge s/he can do something with the fact, make sense of it, interpret it, understand it, use it. It is no longer "decontextualized" (if in fact it ever truly was, which is doubtful). And the child had to learn it somehow. If we can make the learning of such facts more interesting and exciting, that is all to the good, but the denigration of facts themselves as useless is consummately wrong-headed.

For inquiring minds, facts do not long remain "decontextualized." My understanding of the Civil War, which we can use as an example, is a great deal different now that it was when I first studied it in the fourth grade. But the "core facts" about Abraham Lincoln, the Union and Confederate armies, the plantation economu, etc. that my teacher patiently taught remain of interest. In particular I learned interesting facts about the participation of Ohioans in the Underground Railroad (I was a public school student in Columbus, Ohio at the time), and those facts formed a part of my moral as well as historical sense. I am grateful for having learned them.

If we squirrel away facts, it is to bring them out when the time is right, to make sense of a problem with which we are confronted, or to achieve understanding of something that is puzzling us. We cannot learn all the facts we might ever hope to need--and the skills in finding new information that Soloway mentions are truly important--but at the same time, we cannot "construct an understanding that ties new ideas to old" (p. 30) if we do not have any "old ideas." Intellectual activity is a constant drawing together of thoughts and ideas, turning them over, recasting them, criticizing them, seeing them in a new light. Each problem does not present an entirely new set of material completely divorced from anything previously encountered; thinking is a synthetic activity in which we draw on as much knowledge as we can, and, we are served by knowing more not less.

When in the sixth grade (still at the same school) I was taught that slave owners were usually "kind" to their slaves, I was able to bring a certain amount of skepticism to this pronouncement, based on the simple facts I had previously learned about the extreme risks taken by both slaves traveling the Underground Railroad, and those who maintained the Underground Railroad stops. Education--and life--are always going to be full of misinterpretations (and worse) such as that of my sixth grade teacher, and it is precisely a commond of the facts, and the habit of critical thinking (a lot easier if you have some facts to reason about) that allow people to think for themselves--surely the primary goal of education.

Soloway quotes Herbert Simon to the effect that we need not learn "what" only "how." But if there is one thing that AI research has taught us, it is that "general problem solvers" do not work. Programs only begin to get a glimmer of intelligence when they are infused with rich domain-specific knowledge--the dreaded facts! Programs cannot be made to reason in useful ways unless they are possessed of detailed knowledge of a very particularistic sort. Facts are an intrinsic, indispensable part of reasoning, whether it be machine or human reasoning.

If facts are unimportant, then how should we educate our children? Soloway proposes constructive, hands-on activities such as "building" book reports which students share with one another (ideally via computer) to further cooperative problem-solving skills. But a book report is not "built;" it is not an engineering task in which reasonably well-defined components are combined until the desired functionality is obtained. A book report requires writing and research skills, the application of logic and rhetoric, and a vocabulary with words precise enough to say what you mean. Those are the hard won skills--and they are not of an engineering nature; they are not primarily hands-on.

As for cooperative problem solving, sending an electronic mail message to someone about your book report, or sharing the book itself electronically may be useful activities, but they have little to do with actually writing a book report that is worth reading. Education is the difficult, demanding, time-consuming thing it always was, and simplistic solutions such as helping students "build book reports" or "do more science experiments" (p. 32) do not even begin to scratch the surface of what it takes to acquire an education. Science experiments are great, but students still need to absorb a large body of fundamental scientific knowledge. Just what is natural selection? How do we think stars are born? What is Einstein's theory of relativety? What, for that matter, is a theory? Understanding these things requires the acquisition of difficult concepts best expressed linguistically--it is not simply a hands-on matter, but is fundamentally cerebral. The very freedom from the physical world enjoyed by the human mind permits and encourages complex though--one does not have to go to the Galapagos Islands--or indeed engage in any but the purest mental activity--to achieve a profound understanding of natural selection as Darwin thought about it.

I think--but only at the most impressionistic gut level--that there is an important place in the classroom for computers. But no one has the foggiest idea of how to use computers in the classroom; the research has not been done. Many hard questions lie ahead: which students benefit, what kind of intruction is necessary so that students can effectively use the computer, must computers be as freely available as pencils to have real value, are Macs really the answer, what software is appropriate, how much retaining do teachers need, and last but not least, are computers in the classroom cost-effective? It is likely that the cost of really provisioning classrooms with useful computers and appropriate software would be staggering. Even if industry donated enough computers to outfit every classroom in the nation (an extremely unlikely event), the on-going costs of software, up-grades, maintenance and training would be high. Soloway advocates "new-generation" classroom computers that are connected to sensors for real time data input, networked together to support cooperative work, and provisioned with data-bases, spreadsheets, word processors and electronic mail (p. 32). Desirable though this might be, I cannot squelch my "get real!" reaction; it is impossible to view this scenario as anything but the most naive techie fantasy. Given the very limited budgets that public schools have today, schools have to ask things like: Does it make more sense to buy new books for the library, or musical instruments for music class, or computer hardware and software? Do we hire a computer specialist or someone who can help children with attention deficit disorder? These are not rhetorical questions: school systems face questions like these every day. We must find ways to get some answers to these questions, as it is literally a case of new books for the library vs. geometry tutor, and many other unhappy tradeoffs, given the constraints under which today's schools attempt to educate American children.

Bonnie A. Nardi Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94040

Response

Without question, Nardi's comments are most thought-proviking. Let me respond to the key points. First, Nardi is certainly right that I did not emphasize the need for learners to know "content." For the record, I do believe kids ned to know some content; but of course! How could it be otherwise? The real issue is how they come to understand that content. By and large our educational system supports didactic instruction: teaching is a process of telling content at students, learning is a process of putting that content directly into one's head, and assessment is a process of finding out how much stuff got accumulated. And as every study shows, that method is not working.

Dewey hat it; one learns through mindful, direct experience. In project-based learning, kids are actively engaged in inquiring, in synthesizing, in communicating, in participating, in expressing themselves. What is the quality of my water? And why do two fountains in my school have a different water quality? And what is the water quality at other schools? It is through the doing os such activities, through attempting to use what one learns, does one come to understand "content."

Second, I do not think it is a productive use of time to argue over which particular content areas need to be acquired; whatever is needed to solve authentic problems should be learned. But, by focusing on which specific content area to choose, knowledge becomes further disembodied, decontextualized, divorced from the experience of the learner; knowledge is just goods to be delivered; facts to be learned. It is not a coincidence that expert, experience, and expectations all have the same root. An expert is a person who builds up expectations based on reflections on their experiences. To seriously pursue questions of water quality, students will of course need to dip into the major knowledge groups.

Third, I am not as pessimistic on the cost issue as Nardi: while funding for education is not (now) growing by leaps and bounds, funding for technology in education is in fact exploding! Local school districts all around the U.S. are passing multimillion dollar bond issues that support the acquisition of technology. Technology has acquired a good reputation, even if the reasons were not always so honorable. (The negative is that those bond issues do not typically provide funds for humans to support teachers and students transitioning into the technology.)

And the real cost of those little gadgets is dropping dramatically. By Christmas 1993 we will be able to buy portable information appliances at our supermarket or toy store for $250. Pop in a CD and you have a calculating/spreadsheet environment; pop in another and you are jumping up and down on the Moon with knock-your-socks-off graphic quality.

Cost is not the issue, the issue is: what is the priority? When defense was a priority, the U.S. built an amazing system. If the U.S. decides to pump that Peace Divident back into refurbishing its educational infrastructure, the education system will also be amazing

Finally, Nardi is certainly also right that technology per se will not fix society's ills. Yes, and hungry children do not learn. But as techies are wont to do, I view the glass as half full: the involvement of adults in education, even if it revolves around the use of little gadgets, can only be a positive thing. We all contribute in our own way; the issue is only that we do contribute.

Elliot Soloway University of Michigan 1101 Beal Ave. Ann Arbor, MI 48109

Pen-Based Products

I would like to correct what is probably an inadvertent error of fact in Larry Press's report on "Notes from Comdex" (July 1991, pp. 25-29).

Press's comments on the many announcements by new vendors of pen-based computing products was very informative. The recent marketing efforts my MicroSoft, GO, Slate, and various hardware vendors have attracted a great deal of new attention to this class of technology. However, his remark that Linus Systems was the first to market a pen-based computer system is not correct: several other companies' products predated Linus's introduction.

The earliest commercial product I am aware of was the Alphabec-70, a pen-based handwriting recognition system sold by Xebec Systems Inc., which had a product announcement in IEEE Spectrum in 1974. This product differed from the current crop of products in that it used an electronic pen with a cord, but did not require a digitizing tablet.

Pencept, Inc., based in Waltham, Mass., introduced a pen-based terminal product with handwriting recognition and gesture-based "front ends" to the user-interfaces for several CAD software products at Comdex in the fall of 1983, called the PenPad 200. Pencept shipped a similar product, the PenPad 320, for the emerging PC market one year later. This product was featured on the cover of BYTE in 1985. Wang Laboratories recently announced a development program including some of the Pencept technology licensed from E&S, Inc.

Cadre System, Ltd., U.K., showed and marketed a pen-based handwriting recognition terminal, called Inforite, also at Comdex in 1983.

Communications Intelligence Corp., in Menlo Park, Calif., also marketed a similar product in 1985, known as the HandWriter. A Japanese-writing version of this product was marketed in 1984 by CItoh Corp. under the name "Fit-in-1." CIC's handwriting recognition technology was included in the recent NCR demonstration of a pen-based computer product, along with other software products Press did mention.

Anatex, S.A., of Paris, marketed a product in the U.S. in 1987, known as the Personal Writer, which included context-sensitive handwriting character recognition.

Nester, Inc., using a neural-net recognition technology, announced a pen-based computer product, also in 1987, under the name Nestorwriter. Nestor is currently quite active in marketing their technology in the pen-based computer market.

Two things stand out to me as new in the current flood of announcements of pen-based computing products: for one thing, these products are now widely available on the new generation of lap-top portable computers, while previously vendors (except for Linus) sold their products primarily as extensions to the desk-top computers which were most common. Secondly, for the first time, major companies, such as IBM, NCR, Microsoft, and others are announcing products in this area.

The range of developments in computer technology is over-whelming: one would expect the marketeers and the developers for these new products to emphasize their own developments, and not other companies' products that may have been invented first. Press's report was an excellent thumb-nail sketch of the sheer staggering number of new announcements from one of the largest trade shows the computer industry has ever known.

The earlier products mentioned here are only a partial list of the wide range of pen-based handwriting products that have been actively marketed in the last ten to fifteen years. For a broader report on these earlier products, I recommend a recent survey article by Charles Tappert (Tappert, C.C., et al., "On-line handwriting recognition--a Survey." IEEE TRans. on Pattern Analy. and Machine Intell. IBM T.J. Watson Research Center, Yorktown Heights, N.Y.).

Jean Renard Ward Wang Laboratories One Industrial Ave. Lowell, MA 01851

Response

There appears to be a misunderstanding between Jean Ward and myself. I was discussing portable, pen-based computers in which the pen is used on the display surface. I am not familiar with all the products Ward mentions, but many of them are desktop products using separate writing surfaces. Research and product development on handwriting recognition in general dates back at least to the early 1960s with the work of Mort Bernstein and others with Rand Tablets.

Larry Press 10726 Esther Ave. Los Angeles, CA 90064

Regarding Minimalist

Documentation

I agree wholeheartedly with Marc Rettig ("Nobody Reads Documentation," July 1991, pp. 19-24) that minimalist documentation is a most fascinating and promising notion. Anyone who spreads the word about strategies which could help us produce more effective documentation for less development and production costs cannot be all bad. Whatever strategy one may use in developing documentation, however, checking for accuracy is one step that will never go away. Rettig cites R.J. "Brockman" in this article; the correct spelling is "Brockmann."

Gwen L. Stimely Minitab, Inc. 3081 Enterprise Dr. State College, PA 16801

In my opinion, the primary reason that technical documentation is underutilized is that nobody has the time to read the stuff. Take a quick look at the size of the documentation that accompanies your hardware. Pretty thick, is it not? Ditto for applications software. Operating systems are the worst, though. Documentation for these is of epic proportions. As an example, the manual set of DEC's VMS 5.4 consists of three-ring binders numbering in the dozens.

Vendors now supply their documentation on CD-ROM to reduce the costs of distribution. With that in mind, it should be no wonder that no one actually reads the stuff.

Forget minimalism, hypertext, and whatever. The answer to the question of "How to get users to read documentation" is not "better" documentation. Rather, the solution lies in giving us more hours in the day!

Al Friebe USA-European Trading, Inc. 7092 Spencer Street Omaha, NE 68104

Marck (sic) Rettig's endorsement of minimalist documentation ignores the effect of time.

It is true that many software buyers have little use for the manuals when they rip off the shrink wrap and eagerly attack their new toy. But it is another matter later when they are somewhat familiar with the product and want to work with some of its features in greater depth. Minimalist documentation is not much help at this stage.

Everyone should spend some time with their manuals after working with a product for a few weeks or months. They will learn a lot about many little and not so little features that are not obvious in normal use.

Clearly there is need for Getting Started documentation for new users and also for the old fashioned manuals that patiently explain everything for those who are ready to work the product for all its worth.

P.S., Rettig misspells John Brockmann's name throughout the article. As Rettig and his editors should know, Brockmann is chair of SIG-DOC and the correct spelling of his name--with both n's--is readily available in the list of SIG chairs on page 7.

John Rigo Sysdoc Inc. 1385 York Ave. New York, NY 10021

Response

In response to Gwen Stimely, I blushingly apologize to John Brockmann. Unfortunately my spell checker rejects both spellings (up until today). But it does recognize "minimalist."

To Al Friebe: I have the opposite problem. When I am reading manuals an hour seems like a day, and the days seem endless. Most documentation has this power to extend time.

Aside from the space it takes (a problem solved by CD-ROM), I do not mind voluminous documentation, as long as I only need to read 5% of it to use the software and I can find the right 5% when I need it.

For minimalist documentation to work, the software must be designed in such a way that one can learn it without reading more than a very thin manual (that is where the extra hours come from--less time is spent reading or puzzling over mysterious behaviors). For complex software a complete reference is just the thing, as long as one can find what is needed when it is needed. To guarantee this, every aspect of the software must be documented for reference, so it will be hard to get away from sheer bulk. My hope is that getting the documents off the shelf and into the machine (with a thoughtful design!) is going to be a big help.

To Joe Rigo: Exploring the full feature set is a different activity altogether than first learning to use the software, and good documentation will make clear every feature of the system. If my emphasis on documentation for learning could be taken as a suggestion that we forget about reference manuals, that was not my intention.

But I do believe reference material and documentation for experienced users will benefit from minimalism. For minimalism to work, the software must support exploratory learning. That is, the commands and features need to be out where you can find them, and their purpose should be clear from their appearance. Further, the online documentation should be able to answer these questions: "What do I do now?" "What does this do?" "How can I [underscore] ?" "What is possible?"

Given this, the reference manual might be pretty thin. I have used two complex products extensively without using paper reference manuals. Apple's HyperCard comes with reasonably helpful reference on a HyperCard stack, and I am able to build applications--even ones that include features I have never used before--by referring solely to the online reference. GKS's Prograph, a visual programming language for the Mac, has many clever ways of guiding both new and experienced users. Neither lives up to the high standard set by the previous paragraph, but both support exploratory learning well enough for an experienced user to find answers quickly.

Minimalism and "product as documentation" extend well beyond "Getting Started" manuals. While I am not suggesting we throw out our "old fashioned manuals," we all agree that there is plenty of room for improvement.

P.S., I apologize again to John Brockmann for misspelling his name. And I am sorry, but I can not resist a cheap shot: as Rigo should know, the correct spelling of my name--with a "c"--is readily available on the title page of my column.

Marc Rettig Summer Institute of Linguistics 7500 W. Summer Camp Rd. Dallas, TX 75236
COPYRIGHT 1991 Association for Computing Machinery, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1991 Gale, Cengage Learning. All rights reserved.

 
Article Details
Printer friendly Cite/link Email Feedback
Author:Wexelblat Alan; Turner, Joe; Nardi, Bonnie A.; Soloway, Elliot; Ward, Jean Renard; Press, Larry; Sti
Publication:Communications of the ACM
Article Type:Letter to the Editor
Date:Dec 1, 1991
Words:4829
Previous Article:What do system administrators really do?
Next Article:Wide-area collaboration.

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters