Next Up Previous Contents Index
Next: Building Subservient Systems Up: The Computer Revolution Previous: ``Go Do'' Considered

Son Of Batch

Let's consider a very different kind of user interface. I will take the business letter as an example. Suppose you get a letter from an irate customer who didn't get his product on time. All you can do is apologise and explain how you'll try to do better in the future. You punch ``answer that'', and the letter goes away. The system reads it, selects a reply, and maybe asks you a couple of questions (queuing them, not interrupting your current task), and eventually puts a draft reply in your in basket. You mark it up, making some marginal notes, and maybe inserting a personalised paragraph in the middle and send it away again. It comes back, with your spelling and grammar corrected, beautifully formatted in conformance with the corporate style sheet. You say ``send it'', and it's all taken care of in accordance with the standard procedures.

Or, today, you pound out a 20 page paper with hand written tables referenced by the text and mail it to IEEE Transactions on Computers. Your typescript may be full of erasures and arrows moving words around. A few months later you get back the galleys, perfectly formatted to fit in the journal, with all of the tables set up and placed in the proper locations in the text.

Before you say, ``that's very nice, but we don't know how to do that'', pause to consider: Isn't this what people really want? If you had a system that did this, that could go off and do the shitwork, wouldn't you prefer it to all the menus and WYSIWYG gewgaws in the world? Also, remember that the computer would not be perfect at its job. Neither are people: that's why they send you the galleys. But isn't it better to mark up the galleys than to have to typeset the whole works yourself?

Building systems that can go off and do useful things for people is going to be very, very difficult. But so is designing the highly interactive user interfaces we're all working on. Both dwarf the effort involved in writing an old-style program where you just solved the problem and left the user to fend for himself. If you're going to succeed, you not only have to solve the problem well, you have to solve the right problem. Maybe improving direct user interaction is solving the wrong problem.


Next Up Previous Contents Index
Next: Building Subservient Systems Up: The Computer Revolution Previous: ``Go Do'' Considered

Editor: John Walker