Agree with Shmuel. This is common in "higher" technical documentation, called Revision Highlights or Highlights of Changes or similar. Sometimes sent as a transmittal letter accompanying the distributed manual, and sometimes more like a part of the manual front matter pages.
Bodvar 2009/5/19 Shmuel Wolfson <shmuelw1 at gmail.com>: > I still say you have to figure out a way to make it easier for them to > find the information that has changed, without rereading the entire > manual. Perhaps you could list a version history with what's new in each > version. Then you could ask the engineer to check the version history > and read the related sections of the manual before complaining that it > doesn't work. > > -- > Regards, > Shmuel Wolfson > Technical Writer > 052-763-7133 > > Garnier Garnier wrote: >> Hello Nancy/Shmuel/Sharon,& others, >> >> Thanks for the response. I handle documentation for the EDA (Electronic >> Design Automation) industry. All user/reference/training manuals are very >> technical so am not sure if having a separate dos and don?t's page(s) would >> help because it will vary with each design and with simulator/synthesizer >> that the user selects for the simulation or synthesis. Still thanks for the >> suggestion I will try to explore the same. >> >> I agree with Nancy as the management support is definitely important. I am >> not defending myself. Whenver a new recruit has to go through the training >> as part of induction they are able to simulate each of the design convered >> in the training material. Since the new recruits are not aware of the >> product they end up reading each page of the training material and able to >> perform each step as required- like changing the block parameters before >> simulation or compiling the imported blocks before adding to the design for >> simulation etc. Whereas the existing field engineers are aware of the >> product so never bother to read the contents. For example one of the >> engineers attempted to perform C simulation for a design with imported >> blocks. This is because any design with imported blocks needs to be compiled >> separately before adding it to the design and then one needs to run >> Co-simulation or RTL Simulation. In this case C simulation will fail. This >> concept is clearly >> ?documented but the engineer kept sending nasty mails complaining that the >> design is faulty. I then sent him the page number of the material wherein >> the instructions are clearly mentioned. After that he did not bother to >> respond because he could then run the simulations successfully. Or the >> Engineer attempting to run the tool on a RHEL version that we do not >> support. The S/W and H/W requirements are clearly documented still whatever >> is available at the client end they attempt to run the designs on that OS. >> There are many such similar cases. During my appraisal this issue was >> brought up and I have been asked to find methods as to how I can compel the >> engineers to read the contents. How can I when the engineer is overconfident >> about his knowledge about the product? It is for the managers to bring this >> up. ?As already mentioned the new recruits have never complained and used >> the same training material to understand the product/module whereas the >> existing >> ?engineers are constantly complaining. The saddest part is whenever there is >> a feature addition/modification the contents are immediately updated and >> mails sent to all engineers with a request to exercise the new/modified >> features and also provide feedback. Nobody responds. When they go for >> customer training they start using the new feature without reading the >> modified contents. Assuming the working of a feature and actual working of a >> feature are different. When a feature does not yeild the required results >> because of the modifications then I start receiving harsh mails that the >> designs are not working as expected. Since I handle the training material >> all the barbs are directed to me even if the design is faulty for which the >> R&D is responsible. Though a writer over a period of time I have gained >> sufficient knowledge about the product so always test each feature myself >> before making it available to Engineers. Now I am definitely at a loss as to >> how the >> ?situation can be improved. As Nancy suggested the head of the Engineers >> should pressurize them to do their homework before visiting the customers >> for training or use the material during their free time to understand the >> module and also provide feedback for further improvement. Looks like I am >> asking for the impossible as this never happens. >> >> Thanks once again to each one of you. >> >> Warm Regards, >> >> Garnier >> >> >> -----Original Message----- >> From: Nancy Allison [mailto:maker at verizon.net] >> Sent: Monday, May 18, 2009 7:11 PM >> To: garnier_framescript at yahoo.co.in >> Subject: Re: Motivating end users to read the user manual >> >> And, again, this time with "Plain Text" selected. >> >> >> Hi, Garnier. I'm replying to you individually and copying to the forum, >> because I'm really interested in other people's responses, as well. >> >> I'm working at a company where the head of engineering says, "Nobody reads >> the manual." Basically, they've written off the value of what I do and >> therefore don't support it. Sounds a bit like your place. >> >> >> >> I believe the most important element to changing your situatkion is >> management support. If you can get a higher-up to start spreading the word >> that your manuals are valuable, good things will flow from there. If you can >> get the engineers' manager to push them to use the doc, that will make a >> difference. If it becomes unacceptable for an engineer to complain about >> something that is covered in the doc, they'll stop. If there's some way to >> measure their use of the documentation in their job performance reviews, >> they'll start using the documentation. >> >> >> >> Basically, if it becomes embarrassing for them (and if they lose points on >> their job reviews) for failing to perform procedures that are covered in the >> documentation, they'll start using it. >> >> >> If that happens, eventually you may even ?get useful feedback from the >> engineers. For example, maybe they'll tell you which procedures they follow >> again and again, and you'll get the go-ahead to create a Quick Reference >> Guide that is pocket-sized. That sort of thing. >> >> Without management support, though, it's almost impossible, unless you have >> an amazingly charismatic personality. (Do you???) >> >> Good luck. >> >> --Nancy >> >> -----Original Message----- >> From: Sharon Burton [mailto:sharon at anthrobytes.com] >> Sent: Monday, May 18, 2009 7:52 PM >> To: 'Shmuel Wolfson'; 'Garnier Garnier'; 'Framers' >> Subject: RE: Motivating end users to read the user manual >> >> Have you considered sitting with the users and asking them what the issues >> are and why they don't like the materials? Don't defend what you've done, >> listen to why these materials are not doing what you think they should be >> doing. Ask questions, lots of questions. >> >> It could be as easy as they are visual learners and they need flow charts >> and other graphics. It could be as complicated as they never see the >> training materials because those get locked away somewhere. Perhaps Job Aids >> and Quick Starts would help. >> >> But until you talk to the users and find out what they need that they aren't >> getting, you're only guessing. You don't get to decide the docs are >> sufficient, tho - your users get to decide that. >> >> >> sharon >> >> Sharon Burton >> 951-369-8590 >> IM: sharonvburton at yahoo.com >> Blog: madcapsoftware.wordpress.com >> >> >> -----Original Message----- >> From: framers-bounces at lists.frameusers.com >> [mailto:framers-bounces at lists.frameusers.com] On Behalf Of Shmuel Wolfson >> Sent: Monday, May 18, 2009 6:47 AM >> To: Garnier Garnier; Framers >> Subject: Re: Motivating end users to read the user manual >> >> The fact is that people don't like to read. Exhaustive training material >> is "exhaustive" to read. >> >> If there are specific "do"s and "don't"s that are *not* intuitive, make >> a short 1-3 page list, print it on color paper, and put it in the box >> with the product. That they might read. >> >> > > _______________________________________________ > > > You are currently subscribed to Framers as bodvar at gmail.com. > > Send list messages to framers at lists.frameusers.com. > > To unsubscribe send a blank email to > framers-unsubscribe at lists.frameusers.com > or visit > http://lists.frameusers.com/mailman/options/framers/bodvar%40gmail.com > > Send administrative questions to listadmin at frameusers.com. Visit > http://www.frameusers.com/ for more resources and info. > -- "Life is not only a game--it is also a dance on roses." --Fleksnes (Rolv Wesenlund)