The Bangalore Technical Writers Meetup for June '07-Supported by STC India took place in Adobe Systems on June 23rd, 2007. Listed are the attendees along with their respective companies' names:
1. Preran- ADOBE
2. Darshin Naidu- HSB Technologies
3. Anindita Basu- Integra Microsystems
4. Arun Martin- Bally Technologies
5. Bibhudatta Mohapatra- Intergra
6. D.Hemadri- Sun Microsystems
7. Joy M J- TCS
8. S.Gopal- Consultant
9. Benazir Hussain- Metalearn Services
10.Rishi Rajpal-Metalearn Services
11.G Raghu-Metalearn Services
12.Shabith Prabhakar-Metalearn Services
13.Ajit Kumar-Metalearn Services
14.K Anantha Raman-Metalearn Services
15.Rajlakshmi Borthakur-Infosys
16.Aunindra Sinha- Infosys
17.Vidya Lakshmi-
18.Shwetha Shashidharan- SAP Labs
19.Dhanish P Bhaskar- Fomax
20.Ramesh-GE
21.Pradeep L.N- Metalearn Services
22.Prabhat Ramesh- Four-C
23.Gururaj BS-ADOBE
24.Surag R- Honewell
25.Jilna Surag- Freelancher
26.Shashi Prabha- TCS
27.Banurekha Balaji- Honeywell
28.Blessy Thomas- Citec
29.Vikash Kumar- Cognizant
30.Saseendran K- Proteans
31.Manoj Potdar-Proteans
32.L.Chelladurai- ABB Global Services Ltd
33.Sreeram MV-ADOBE
34.Rajdeep Gupta-Infosys
The meetup started at 10.35 am and the agenda was "Developing interactive content". After a quick round of introduction by everyone, Rajdeep requested the speaker Preran to initate the discussion.
• Preran who has 7 years experience in Technical Communication and Web Design, started off with an introduction explaining-Learning, Various types of Learners, Interactive Learning for Simulation etc.
• After that Preran discussed Adobe Captivate's TM features like adding interactive tools e.g. text box, mouseclock. He showed how to record presentations (for example, a demo), and explained the multiple output formats for publishing.
• Preran also showed us how to create a quiz question, and the various quiz types that can be created using quiz templates for assessing user at the end of any training presentation.
• After that, Sreeram M V, Product Manager for Adobe Captivate interacted with participants on the Captivate usage. He responded to the user's queries related to Captivate, which they face during projects. The discussion was lively with users providing feedback on the Captivate tool. The participants also tried to clarify questions posed by each other.
The session concluded at around 1 pm with some informal one-one interactions.
Click here to view the photos http://techwriter.meetup.com/2/photos/?photoAlbumId=177937&photoId=1602283
Also, the meetup presentation is available for downloading at http://techwriter.meetup.com/2/files/
Tuesday, June 26, 2007
Saturday, June 16, 2007
Interwoven Session on June 16, 2007
I had the privilege to attend the STC Learning Session on Usability conducted at Interwoven (June 16, 2007), and am sharing the session’ gist with you.
The first speaker was Sherrill Packebush, a User Experience Analyst with Interwoven who delivered a presentation on HCI and Tech Communication. She gave a basic idea of what HCI is, responsibilities and the role of tech communicators in designing.
Sherill said HCI does a lot of research on the designing and development activities. She also shared her experiences in creating wireframes, prototypes and all. In addition, She highlighted some case studies on usability namely on Amazon. com, move.com and staples.com.
She pointed out that one of the distinguished companies had to shell out $ 900, 000 on Usability issues for they ended up doing the test on the engineering team and never thought of performing it on end-users. Finally, she discussed some usability problems that are been encountered frequently.
Next was Suman Kumar, writer with DELL who delivered a session on Contingency Design, its importance and writers role in it. Citing examples, Suman said that Error messages should be treated as educating the customers. He also cited some practical examples wherein vague error messages have proved costly to the flagships of the product.
In addition, Suman thought that the following points in mind while writing error messages. Error Messages need to be identifiable, accurate, understandable, succinct, correct measure and explain what went wrong. According to Suman, writers are the perfect customer advocates and should play key roles in getting the customer requirements picture clearer to the design and development team. In a nutshell, always try to be on the user's shoes when writing error messages.
The session concluded with a Q & A.
Friday, June 01, 2007
Points on Documentation Survey
Hi Francis,
At the outset, an excellent chance to do something new out here!
Though I ain't in a position to disclose the Questionnaire (client policies and all), I will share my experiences. I had a chance of revamping the entire documentation for a particular XYZ client.
The first thing is that while I understand you are potboling with enthusiasm to be creative and come out with a new structure, please do not be in a hurry. If time permits, do an analysis of the existing manual; list out all the documentation issues in an excel sheet and try to figure out the possible alternatives to it.
Now, when you are done with that, try to chalk out in a piece of paper as what is MISSING in the document? If possible, have a coffee talk to your fellow mates, clients and end-users (if possible). If not, never mind. I suggest you to look into the customer support emails.
I am sure, there are documentation issues, which might be relevant in terms of language, structure etc of the document. Take this factors into consideration before you start with your new draft.
Create a list comprising of three sections- Major, Minor and Critical and correspondingly departments under which it should go. If there are technical documentation inaccuracy, which is major, the issue should be sorted out by the documentation team, in that case it is you.
If there are incorrect steps documented, which may lead to a wrong action on the part of the user-say an installation step, the issue is critical. If there is some mismatch with the GUI buttons failing to work and all, you need to get in touch with the development or design group. At the end, try to look out possible alternatives and come out with a solution and resolve the matter.
Try to also conduct out a test in the team itself of how users read the documentation. You will get a good idea of the readability of the documentation.
I don't know, but you can perhaps look to explain the features in a new manner-- how about creating a demo, identifying the unique features of the product.Also add a few quzzies in the note and provide feedback in the form of correct or incorrect messages. Always try to get the users in action.
My two cents
Regards Rajdeep
---------[ Received Mail Content ]----------
Subject : [twin] Documentation surveys
Date : Tue, 22 May 2007 19:06:30 +0530
From : "Francis Anthony"
Hi:
I'm starting out on a new documentation project whose content needs to be completely overhauled. I figured that the best way to go about overhauling existing documentation would be to understand:
* What is it that users found lacking in the status quo, and
* What is it that users would like to see in the revamped
documentation
To this end, I will be conducting a scientific survey of the documentation. Has any one undertaken a similar effort previously? If so, I'm interested in hearing from them about their experiences. Broad tips on how they went about it, how much time was spent in the effort,
what kind of questions formed part of the questionnaire, etc. would be greatly helpful.
Please feel free to write to me and to the group, if you like, to share your experiences and insights.
Any and all information would be much appreciated.
Many thanks,
Francis
At the outset, an excellent chance to do something new out here!
Though I ain't in a position to disclose the Questionnaire (client policies and all), I will share my experiences. I had a chance of revamping the entire documentation for a particular XYZ client.
The first thing is that while I understand you are potboling with enthusiasm to be creative and come out with a new structure, please do not be in a hurry. If time permits, do an analysis of the existing manual; list out all the documentation issues in an excel sheet and try to figure out the possible alternatives to it.
Now, when you are done with that, try to chalk out in a piece of paper as what is MISSING in the document? If possible, have a coffee talk to your fellow mates, clients and end-users (if possible). If not, never mind. I suggest you to look into the customer support emails.
I am sure, there are documentation issues, which might be relevant in terms of language, structure etc of the document. Take this factors into consideration before you start with your new draft.
Create a list comprising of three sections- Major, Minor and Critical and correspondingly departments under which it should go. If there are technical documentation inaccuracy, which is major, the issue should be sorted out by the documentation team, in that case it is you.
If there are incorrect steps documented, which may lead to a wrong action on the part of the user-say an installation step, the issue is critical. If there is some mismatch with the GUI buttons failing to work and all, you need to get in touch with the development or design group. At the end, try to look out possible alternatives and come out with a solution and resolve the matter.
Try to also conduct out a test in the team itself of how users read the documentation. You will get a good idea of the readability of the documentation.
I don't know, but you can perhaps look to explain the features in a new manner-- how about creating a demo, identifying the unique features of the product.Also add a few quzzies in the note and provide feedback in the form of correct or incorrect messages. Always try to get the users in action.
My two cents
Regards Rajdeep
---------[ Received Mail Content ]----------
Subject : [twin] Documentation surveys
Date : Tue, 22 May 2007 19:06:30 +0530
From : "Francis Anthony"
Hi:
I'm starting out on a new documentation project whose content needs to be completely overhauled. I figured that the best way to go about overhauling existing documentation would be to understand:
* What is it that users found lacking in the status quo, and
* What is it that users would like to see in the revamped
documentation
To this end, I will be conducting a scientific survey of the documentation. Has any one undertaken a similar effort previously? If so, I'm interested in hearing from them about their experiences. Broad tips on how they went about it, how much time was spent in the effort,
what kind of questions formed part of the questionnaire, etc. would be greatly helpful.
Please feel free to write to me and to the group, if you like, to share your experiences and insights.
Any and all information would be much appreciated.
Many thanks,
Francis
Subscribe to:
Posts (Atom)