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)

Reply via email to