1. Software Reviews and User Instructions CSE/ISE 300 Spring 2011 Tony Scarlatos

2. Similarities In both cases the writer has to assess – The task (what are we trying to accomplish?) – The user (what do they know already?) – The context (what tools, environment, etc. can we assume or are required?) Within that framework, the author must – Explain how the product fulfills the need – Anticipate errors the user may make using the product

3. Software Review (general) 1.Have an idea who your reader will be – Typical end-user or a professional? New to computers or some class of software? 2.Provide context – Summarize the anticipated outcome. What should the user be able to do? What benefits will they get from using the product? How long will it take? 3.Establish the parameters – What knowledge does the user need before using the product? What other tools or preconditions are needed? Under what conditions was the product tested? 4.Keep the review short (less than 500 words) but try to make it entertaining (without being sarcastic or rude). A useful software program or a well designed game can bring a lot of joy to users – try to capture that feeling, or help them avoid disappointment.

4. Software Review (specifics) 1.Name and version number of the product. (Version history /manufacturer info, if useful…) 2.Price of the product, upgrade, or cost of subscription. How/where did the author obtain the software? 3.Context. What did the author wish to do with the application? Is the author a power-user or a typical end-user of this type of program? What class or genre of software does the program belong to? 4.What were the conditions under which the software was tested (platform, OS, processor speed, RAM, network connection)? What specifications does the manufacturer provide?

5. Software Review (more specifics) 1.Features and capabilities. Does not have to be an exhaustive list, but should relate to the task(s) defined by the reviewer. 2.Are there any accessories (joystick, graphics tablet, etc.) which are needed for the program, or which would make it more useful or enjoyable? 3.How does the interface look and feel? Assess the ease of navigation and use of the program. How good is the user help and documentation? 4.Reliability and speed. Did the software perform reliably? Was it responsive or were there long inexplicable delays? In the case of malfunction, how helpful was customer service or tech support? 5.How does the software compare to other programs in its class? 6.Provide a short summary of your findings. Do you recommend the product or not?

6. User Instructions (general) User instructions are very structured documents, somewhat like a resume It is very important to provide context up front – What do the instructions cover, and what should be the result at the end – What are the prerequisites (equipment, tools, user knowledge, etc.) – How long it should take to complete the task Good formatting of the sections is vital to making the instructions easy to scan Instructions should be written in short “consumable” chunks

7. User Instructions (sections) 1.Title 2.Introduction – Provides the context (task, prerequisites, length of time, expected result) – Should also provide any applicable warnings about safety, damage to equipment (or loss of data), etc. 3.Background – Optional, but can provide a valuable framework 4.Instructions as a series of numbered steps – Allows users to jump to advanced steps if certain conditions have already been met 5.Summary – May include troubleshooting FAQ

8. User Instructions Template Template from the online textbook

9. Advice from Bruce Tognazzini 1.Explain the problem being solved 2.Present the concepts, not just the features. 3.Give 'em more than they deserve 4.Make it enjoyable to read One final piece of advice: to gauge how effective your instructions are, observe an end-user trying to follow them before you publish!