See: Pictures of Robert
Robert does most of the hardware and software user's guides at Wizard Textware. In the past year, he has moved from doing exclusively printed documentation to doing on-line Help, with accompanying printed documentation.
"The most important thing to remember when creating documentation is that customers do not buy software so they can play with it (except for games, of course). They buy software to solve a problem. The problem might be writing memos, composing symphonies, or controlling their finances, but they spent their money hoping that the software is going to solve this problem and make their lives easier.
"Documentation, therefore, must show the user how to use the program to solve their problem. Customers aren't interested (at least initially) in what the "Rotate Widget" command on the "Widgets" menu does, unless they use it to solve their problem.
"This sounds like a pretty simple philosophy, but it has profound implications for documentation. Instead of giving the customer a tool box and saying 'Here, go build whatever you want,' you give them a tool box with instructions on how to build a doghouse.
"This means that documentation may involve describing a procedure for the customer to use (some of which may not involve using the program). For example, we documented a program to help managers track work assigned to their employees. In order to get the most benefit from the program, the managers needed to estimate how many hours would be needed to complete each task.
"This meant that the documentation needed to describe how to go about estimating work. Although this wasn't part of the program, it helped to solve the user's problem (scheduling work). So we did some research and proposed a method of estimating how much time it would take to complete a task.
"I really like using both on-line Help and printed documentation, because the on-line part can deal with the nitty-gritty of how the interface works and the printed documentation can help the customer learn a process for solving their problems."
He's also currently developing a proposal for JoE, but only Elizabeth really cares about that. He's also working on a web site for OMAX, but again, only Carl really cares.
May 1985 to present
- Wizard Textware
- Self-employed. Writing, editing, and page layout for various types of documentation. (See Documentation for software and hardware for a complete list of projects.)
April 1984 to May 1985
- Northwest Computerworks
- I designed database systems for accounting, payroll and inventory applications for clients. This is also where I got a chance to work on documenting a product, and found out that it was a lot easier than programming, and more fulfilling.
April 1983 to April 1984
- Wizard Software
- This was the first incarnation of our business. At this point, I did database design and consulting, and miscellaneous programming in Pascal. After a year of doing this, I realized I was losing money and needed to get a regular job for a while.
May 1981 to April 1983
- Parametrix, Bellevue, WA
- I ran a Xerox 850 dedicated word processing system. Although this was pretty much just typing in what other people wrote, I learned a number of valuable skills. I got comfortable writing on an electronic system (instead of using a typewriter) and doing page layout. I also improved my typing skills considerably (nothing like using something for 8 hours a day to get better at it). I also ended up doing the billing for the office, which came in really useful later, when I had my own business.
October 1980 to May 1981
- Boeing Commercial Airplane Company
- I was assigned as a clerk typist to a group looking at the "Office of the future." I turned out to be the only one who knew anything about computers, so I ended up writing programs and figuring out computer systems and other pretty cool stuff. This was my first exposure to microcomputers, and I fell in love with them (no more calling operators to change tapes, or waiting while they rebooted the system).