Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site ulysses.UUCP Path: utzoo!linus!decvax!harpo!eagle!mhuxt!mhuxi!mhuxa!ulysses!gsp From: gsp@ulysses.UUCP Newsgroups: net.cog-eng Subject: Re: User-Friendly Re-Defined Access-Efficient Message-ID: <590@ulysses.UUCP> Date: Wed, 31-Aug-83 22:30:52 EDT Article-I.D.: ulysses.590 Posted: Wed Aug 31 22:30:52 1983 Date-Received: Thu, 1-Sep-83 10:11:24 EDT References: <976@ittvax.UUCP> Organization: Bell Labs, Murray Hill Lines: 107 Alan Wexelblat (decvax!ittvax!wex) has genuine concerns about programmer investments and run-time efficiency, but he has put forth the programmers' "party line" that we have heard for years. His ideas are plain wrong, and I think dangerous. I will summarize his ideas, explain why they are wrong, and provide a solution. His first idea is that my last name is spelled Perelman. It is Perlman. His two problems with the concept of "access efficient" software (my backlash at "user friendly") follow. My comments are indented. (1) Programmer time: It takes a lot to put pop-up menus (etc.) into programs, and this will cost money for end-users. This is wrong on two counts. First, if programmers were given good tools to build user interfaces, having a pop-up menu would be no more time consuming than using printf to prompt for input. Because of the lack of good tools, I have worked on the Interface Arsenal, a set of C libraries for developing user interfaces (presented at the last USENIX). Second, programmer time is a negligable investment compared to fixed costs like equipment and risks like marketing. I should point out that one of the major programming investments in the Interface Arsenal has been to make it easy for PROGRAMMERS to program user-interfaces. Of course, these tools are supposed to make the programs easy to use by USERS. The point is that good tools can do powerful things with little effort; that is why we build libraries. 2) Cost in machine space/time. Having all this fancy software will slow our machines. There is some truth to this, but it is not reason enough to throw away the idea of building good user-interfaces. Two points: First, much user-interface software is poorly written (it is often done by well meaning psychologists who don't know about program efficiency). Huge imporvments in most programs are possible. Second, user-interface software is io intensive, not compute bound (typically), and so does not necessarily slow down a system. It usually does not slow down a user as most processors are fast enough to keep up with user reading and typing speeds. Moral: don't over-generalize. When you're building a system, get an idea of the people who will be using it, the equipment they'll be using it on, and so forth. Then design in as much 'human factors' as you think necessary. A shop of UN*X hackers won't care about the same things a brokerage house would. And (this is for you, Laura) don't let the customers tell you how to build your product! You're the programmer. You can listen to their suggestions, but if you let them dictate HOW you build your system, you're doing a poor job. Knowing your end-user population is highly desirable, but designing exclusively for "what you think they are" can get you into trouble. You may find your programs used by people you never anticipated, and they will have troubles if you did not provide a general solution. Then people like Don Norman will write nasty articles about you in Datamation. Knowing the equipment they will be using is a similar problem. If you design for systems like 1200 baud dumb terminals, you may find your software is outgrown. Certainly fancy things can be done on fancy terminals, and trying to do them on dumb terminals is a mistake. While a menu might be good at 9600 baud, it might be a nuisance at 1200 or, ugh, 300. By developing user-efficient software, I really mean it has to bee efficient for the users' time, so in many cases, the software must be baudrate/terminal/etc. sensitive. To design for one hardware configuration is wrong in most cases (that means for a blit as well as for a printer). Designing adaptable software is harder, but with libraries, it can be done. Look at termcap (forget curses for now) for terminal independence! Years ago, people would have said, "It can't be done. I won't listen. Look, I'm blocking my ears." Shortsighted. We must have vision and hope. Telling a programmer to "design in as much human factors as you think necessary" is like telling soldiers to exercise as much force as is necessary, except in the opposite direction. Programmers do not know best. It is just that simple. I'm not saying psychologists do, nor end-users, but I put most programmers just above marketing types when it comes to insight in these areas. When I program, I lose track of many objectives and need outside criticism to get a clear view. I think everyone does. Don't forget that UN*X hackers and brokers are all people who have similar cognitive limitations. To say they are completely different (X doesn't care about what Y wants) is shortsighted. That last part about not listening to customers is also shortsighted and a huge overgeneralization. I don't like to shoot down what people say, but that article was rediculous. I would not have cared, except that his ideas are dangerous, of the bipolar type I have argued against. You can't get up on a pedestal and shout out ideas without weighing all sides. Developing user-interfaces is a complex balence between user AND programmer AND hardware limitations. What must be done is: IDENTIFY WHAT MUST BE DONE AND WORK TOWARD IT I do not like to find myself in the company of people who say "can't." Yes, I know this really isn't a solution, but I doubt you're going to be able to concoct a good, general solution. The best you can do is set up guidelines which can be loosely followed. Ugh! Gary Perlman BTL MH 5D-105 (201) 582-3624 ulysses!gsp