Hey, Cal! Or embedded help might be an option. But we're guessing what they want. Ask *them* - they contact the writer asking for help. At that point, call them or email them asking for time to talk about what they need.
Altho it's really hard, explaining what you're doing doesn't help. You don't get to decide if what you've done is the right stuff. The users get to decide that. Your users are telling you that what you provide is the wrong stuff. Only they can tell you what the right stuff is. This is the ethnographic part of what we do - talking to people, looking at how they do what they do, asking questions about how they do it. Then you figure out how to provide user assistance that fits what they need. sharon Sharon Burton 951-369-8590 IM: sharonvburton at yahoo.com Blog: madcapsoftware.wordpress.com -----Original Message----- From: framers-boun...@lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] On Behalf Of Cal Callahan Sent: Wednesday, May 20, 2009 5:56 PM To: framers at lists.frameusers.com Subject: Re: Motivating end users to read the user manual I like Sharon's advice (ask the user directly). But I haven't seen anyone mention context-sensitive help or conditional text. I hope the lengthy paragraphs in your query are not representative of your manuals--that would certainly turn off users. A couple of guidelines: KISS--keep it simple, sir. Tell them what you're going to tell them, tell them what you want to tell them, then tell them what you told them Engineers like flow charts and logic diagrams, so fire up your Visio and try to put the points across that way. And everyone likes pictures, so see where you can use those. (Many people are visually oriented and don't like to read.) I hope I haven't insulted your intelligence. I'm just picking trees out of the forest. cal
