billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (09/03/89)
From markd@salmon.rtech.com (Mark P. Diamond): > if this is my first time using a computer, how do I know that the > power comes from the outlet, and not say the bridge lines, cabling > or other wires? Obvious? My telephone doesn't have an AC plug. [...] An excellent point. Another example: I just came from a laundromat at which I encountered two gentlemen from a foreign country, who had considerable difficulty figuring out how to operate the washers and dryers. Both of them spoke excellent English, and both seemed quite intelligent, but the directions printed on the washer were NOT clear. Their primary problem was that the washer directed them to insert their coins into the slots (not bothering to specify the precise type of coin, of course), and then failed to tell them that they had to push the coin holder in and then pull it back out again. They waited for a while for the washer to start, but to no avail. Whose fault was this? Not the user's... this was totally a result of inadequate user documentation, caused by a failure on the part of the technical writer to identify and describe all relevant actions. Here's another example: automobile owner's manuals frequently specify that one is to change the oil periodically, but manage to avoid any indication of where one is to put the oil in after draining out the old oil. Since there are quite a few caps on the engine, the question of which one to pour the oil into is nontrivial. The failure of the owner's manual would not be fatal if the caps were labeled with letters like "OIL", and indeed letters are placed on practically everything on the engine which indicate obscure part numbers, etc. But there is absolutely NO lettering which is designed to help the user figure out which cap is associated with which fluid!!! Once again... a very poorly documented product. Most software engineers understand completely the need to define variables before using them; why do technical writers not understand the need to define precisely what is to be manipulated and precisely how to go about manipulating it, for each possible user action??? > What I am really arguing against is the arrogance of engineers who can't > design real systems for real people to use, and the arrogance of service > people who believe their time too precious to waste on "stupid" people. > Maybe, just maybe the system you designed Mr. Engineer isn't as easy to use > or install or fix or whatever as you think. Don't pass the buck onto me > for being stupid. Or worse, if I the user haven't mentally put all the > pieces together, if I'm having a bad day and my boss is pushing me to get > this system online and I run into what I think is a problem, and I call you > Mr. Field Sevice Person, don't treat me like an idiot. Help me solve > our problem. Precisely. Bill Wolfe, wtwolfe@hubcap.clemson.edu
rcw@scicom.AlphaCDC.COM (Robert White) (09/09/89)
In article <6376@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From markd@salmon.rtech.com (Mark P. Diamond): > [good story on the faulty washing machine documentation deleted] > > Most software engineers understand completely the need to define > variables before using them; why do technical writers not understand > the need to define precisely what is to be manipulated and precisely > how to go about manipulating it, for each possible user action??? Several reasons. Most companies are unwilling to put what it takes into technical documentation. They hire inexperienced people who may or may not be technically oriented. I think a willingness to "play user" with the product that is to be documented is a prerequisite. You also must be willing to learn everything there is to know about the product. You can't be good at technical writing until you have written some, issued it, interacted with end users, revised it, and issued it again. You also can't write well unless you use the product in a real life situation. That's a problem shared with test data as well. The parameters of the user application must be understood to write decent manuals. > Bill Wolfe, wtwolfe@hubcap.clemson.edu I can't find it right now, but there is a book with a title something like "The Design of Everday Things" containing excellent discussions on the design (or lack thereof) of everything from hot/cold taps to computer software. For example, if taps are arranged vertically, how do you know which is hot and which is not? Highly recommended. I will try to find the author and title if someone else does not beat me to it. Robert White rcw@scicom.alphacdc.com
eugene@eos.UUCP (Eugene Miya) (09/10/89)
In article <1888@scicom.AlphaCDC.COM> rcw@scicom.UUCP (Robert White) writes: >I can't find it right now, but there is a book with a title something >like "The Design of Everday Things" containing excellent discussions >on the design (or lack thereof) of everything from hot/cold taps to >computer software. That's The Psychology of Everyday Things (POET) by Don Norman UCSD (dnorman@ucsd.edu). A moderately pleasant antecodotal book bashing "form over functionality" [my words]. Would be nice if it went further. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "You trust the `reply' command with all those different mailers out there?" "If my mail does not reach you, please accept my apology." {ncar,decwrl,hplabs,uunet}!ames!eugene Live free or die.
sommar@enea.se (Erland Sommarskog) (09/11/89)
Robert White (rcw@scicom.UUCP) writes: >For example, if taps are arranged vertically, how >do you know which is hot and which is not? I haven't been confronted with vertical tap arrangements, but I have been to places where hot tap was the one to the right. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/12/89)
In article <1888@scicom.AlphaCDC.COM> rcw@scicom.UUCP (Robert White) writes: >Most companies are unwilling to put what it takes into technical documen- >tation. True.... >They hire inexperienced people who may or may not be technically oriented. ^^^^^^^^^^^^^^^^^^^^ That's rarely the problem. Far more common is that companies hire writers for their technical expertise, but don't bother to find out whether they know how to *write*. What you end up with is user documentation that looks like it written by an engineer who came late into the project. I can teach someone the technical stuff, if they are willing to learn. But I sure can't teach 'em how to write. Followups to comp.software-eng only. <csg>