And the saying goes, "what's there to cook when you have crap in your mind?". I have often wondered what it takes to get popular in a proffession? Whether it is necessary to be proactive and simulataneously beat the drums? or is it to keep quietly doing one's job and have an innovative approach? A mixture of both should be ideal, and I am saying after some years of working in an IT Industry.And that's even more the reasons I think we need to understand what's that we want from our profession?
I've been part of the technical communication circuit from the past 3 years; a large part of my time has been devoted to understanding the intricacies of technical writing, which I am sure will take some from time. Anyway, continuing with the mailing lists, there are discussions of all sorts; from highly technical to non-technical aspects. The addresses have been mainly writers with some experience in the field. Though the writers mainly post their queries on the mailing lists, they do want them to be personally shooted an email.What results is just the apposite.
Friday, December 22, 2006
Wednesday, December 20, 2006
An article on face-to-face communication
A fantastic article on face-to-face communication by Sunder Ramachandran.
How face-to-face communication helps at work
Sunder Ramachandran (-- Sunder Ramachandran is a managing partner at WCH Solutions (http://www.wchsolutions.com), a training solutions organisation. He can be reached at sunder@wchsolutions.com.)
Today, most of your clients, colleagues and stakeholders are just a phone call or email away -- technology has made communication that simple. However, while tools like telephones and computers score high on convenience and speed, they lack the warmth and emotion that face-to-face communication provides.
In my earlier features, I have highlighted the importance of telephone etiquette, making use of online networking and business chat etiquette. However, there are some occasions where you must revive the by-now forgotten art of face-to-face communication.
Appreciating colleagues
In the words of Helen Keller, 'We are all walking with a signboard on our forehead which reads -- 'Appreciate me'.' It seems we have replaced the pat on the back with 'Thank you' and 'Good job' emails. But there is nothing that motivates someone more than seeing their boss walk up to them and appreciate them in front of everyone.
Go to your colleague's cubicle and congratulate them on the great report they sent or the presentation they made recently. I remember one of my ex-bosses who used to call us team members to his cabin just to say 'thanks' and pat our backs. The team immediately took a liking to him as most people expect a warning or feedback when the boss invites them to their cabin.
"It's difficult to build rapport over an email; I would feel much better if my boss appreciates me in person," says Ashok Krishnan, a CA with Nestle.
Criticising or providing feedback
When you provide feedback over an email or a phone call, the receiver may have a completely different perception about its relevance. This effect is amplified when you are not communicating face-to-face. The reader or listener may think you are cold and indifferent and that's why you avoided meeting them in person to discuss the issue. A face-to-face meeting gives you the opportunity to put your point across, while being sensitive and diplomatic at the same time.
"I have noticed that colleagues often use emails to avoid confronting the real issue. If someone fails to meet their target, I would prefer they tell me in person than offer an explanation over email," says Vidhanshu Bansal, a director with Pixel Webtech.
Assigning new responsibility
There is a great risk of the message getting diluted when a responsibility gets delegated through email or a phone call. Don't be surprised if your team does not show a sense of ownership or complete tasks on time if you are not communicating face-to-face. Nonverbal communication, such as tone of voice, facial gestures and eye contact help individuals understand the importance of a task and the need to complete it on time.
"We rely on conference calls, video conferencing and online meetings but, from my experience, there's nothing more impactful than meeting the team in person," says Delhi-based Ashu Gosh, a manager with Aviar IT Consulting.
Damage control with clients
If you haven't provided the product or service the client expected, you are putting your relationship with the client at stake. An apology mail would not suffice in a sensitive issue like this. Go to the client's office, if possible, without them having to call you for an explanation, and reassure them that the confidence they demonstrated when they gave you business was not misplaced. Your client would be pleasantly surprised that you took the time to come and meet them, especially when things went wrong.
"I used to interact on almost a daily basis with a client over emails without ever figuring out whether the person was male or female. When a report I was supposed to send got delayed, I made a rude comment about a female colleague which offended the client who happened to be a lady herself," says Deepak M.L, a manager with Convergys.
Resolving conflicts
Workplace conflicts are common in most organisations. The lack of interpersonal communication only worsens the situation. It's important to remember that 55 per cent of meaning in an interaction comes from facial and body language and 38 per cent comes from vocal inflection. Only seven per cent of an interaction's meaning is derived from the words themselves. So, trying to resolve a conflict over email or a phone call is often a bad idea.
"A colleague complained about another colleague and copied the senior management on the mail. I was surprised to see that mail translating into a flood of mails providing and seeking explanation. The person who sent the original mail was just one floor above the person who was at the receiving end. I had to sit down with both of them in person to resolve the conflict," says Kailasam R, a manager with Lufthansa Airlines.
Your communication style says a lot about you as a professional. In the words of Ralph Waldo Emerson, 'You are always under examination by people around you, awarding or denying you very high prizes when you least think of it.' So leave the comfort of your cubicle and build trustworthy relationships by communicating face to face.
How face-to-face communication helps at work
Sunder Ramachandran (-- Sunder Ramachandran is a managing partner at WCH Solutions (http://www.wchsolutions.com), a training solutions organisation. He can be reached at sunder@wchsolutions.com.)
Today, most of your clients, colleagues and stakeholders are just a phone call or email away -- technology has made communication that simple. However, while tools like telephones and computers score high on convenience and speed, they lack the warmth and emotion that face-to-face communication provides.
In my earlier features, I have highlighted the importance of telephone etiquette, making use of online networking and business chat etiquette. However, there are some occasions where you must revive the by-now forgotten art of face-to-face communication.
Appreciating colleagues
In the words of Helen Keller, 'We are all walking with a signboard on our forehead which reads -- 'Appreciate me'.' It seems we have replaced the pat on the back with 'Thank you' and 'Good job' emails. But there is nothing that motivates someone more than seeing their boss walk up to them and appreciate them in front of everyone.
Go to your colleague's cubicle and congratulate them on the great report they sent or the presentation they made recently. I remember one of my ex-bosses who used to call us team members to his cabin just to say 'thanks' and pat our backs. The team immediately took a liking to him as most people expect a warning or feedback when the boss invites them to their cabin.
"It's difficult to build rapport over an email; I would feel much better if my boss appreciates me in person," says Ashok Krishnan, a CA with Nestle.
Criticising or providing feedback
When you provide feedback over an email or a phone call, the receiver may have a completely different perception about its relevance. This effect is amplified when you are not communicating face-to-face. The reader or listener may think you are cold and indifferent and that's why you avoided meeting them in person to discuss the issue. A face-to-face meeting gives you the opportunity to put your point across, while being sensitive and diplomatic at the same time.
"I have noticed that colleagues often use emails to avoid confronting the real issue. If someone fails to meet their target, I would prefer they tell me in person than offer an explanation over email," says Vidhanshu Bansal, a director with Pixel Webtech.
Assigning new responsibility
There is a great risk of the message getting diluted when a responsibility gets delegated through email or a phone call. Don't be surprised if your team does not show a sense of ownership or complete tasks on time if you are not communicating face-to-face. Nonverbal communication, such as tone of voice, facial gestures and eye contact help individuals understand the importance of a task and the need to complete it on time.
"We rely on conference calls, video conferencing and online meetings but, from my experience, there's nothing more impactful than meeting the team in person," says Delhi-based Ashu Gosh, a manager with Aviar IT Consulting.
Damage control with clients
If you haven't provided the product or service the client expected, you are putting your relationship with the client at stake. An apology mail would not suffice in a sensitive issue like this. Go to the client's office, if possible, without them having to call you for an explanation, and reassure them that the confidence they demonstrated when they gave you business was not misplaced. Your client would be pleasantly surprised that you took the time to come and meet them, especially when things went wrong.
"I used to interact on almost a daily basis with a client over emails without ever figuring out whether the person was male or female. When a report I was supposed to send got delayed, I made a rude comment about a female colleague which offended the client who happened to be a lady herself," says Deepak M.L, a manager with Convergys.
Resolving conflicts
Workplace conflicts are common in most organisations. The lack of interpersonal communication only worsens the situation. It's important to remember that 55 per cent of meaning in an interaction comes from facial and body language and 38 per cent comes from vocal inflection. Only seven per cent of an interaction's meaning is derived from the words themselves. So, trying to resolve a conflict over email or a phone call is often a bad idea.
"A colleague complained about another colleague and copied the senior management on the mail. I was surprised to see that mail translating into a flood of mails providing and seeking explanation. The person who sent the original mail was just one floor above the person who was at the receiving end. I had to sit down with both of them in person to resolve the conflict," says Kailasam R, a manager with Lufthansa Airlines.
Your communication style says a lot about you as a professional. In the words of Ralph Waldo Emerson, 'You are always under examination by people around you, awarding or denying you very high prizes when you least think of it.' So leave the comfort of your cubicle and build trustworthy relationships by communicating face to face.
Thursday, December 14, 2006
Moments of the 8th STC Annual Conference, Bangalore
”Exclusivity” was the theme for the recently concluded 8th STC Regional Conference held at Bangalore. The theme was appropriate as skilled technical writers presented multiple presentations on diverse technical writing topics in a gala event, spanning three days. Hotel Grand Ashok was the venue for the occasion, which it created a record turnout of more than 600 delegates. With companies like Infosys, Wipro, Dell, CSC, SUN Microsystems, Oracle, Symphony Services, and various others coming under the same roof, it was destined to be special, and it turned out to be so.
Conference Opens on December 7th
Geoffrey Hart opened the 8th STC regional conference on Thursday, 7th December. Popularly well-known in the technical writing circuit, Geoff Hart is a freelance writer, editor, and translator who specializes in scientific and technical communication. Geoffrey Hart delivered the first workshop on Editing, where he spoke of the intricacies of editing in detail, streamlined the editing process, and was never short of jokes. The audience couldn’t help but laugh when he addressed “technical writers as rabbits in a jungle.”
In a concurrent session, Timo Nevalainen addressed writers on the usefulness of content management for online writing. Timo emphasized the importance of content management saying that it is having “the Right systems for the Right People.”
Rajeev Jain (Zilog), Mary Ann Alexander (Pivotal), and Deepak/Siddarth delivered additional workshops that covered the API Style Guide, FrameMaker Insights, and Project Management. The highlight of the pre-conference workshop was undoubtedly the presentation delivered on Leadership Development/ Management excellence by SVP, HR, Symphony Services, Mahalingam. The speaker emphasized the importance of leadership in a project and supported the cause of “working with a business-oriented mind. Seasoned writer, Gyanesh Talwar, spoke on the “hot” topic brewing these days: XML in documentation and also spoke about Structured FrameMaker.
Conference Continues on December 8th
The following morning, December 8th, saw quite an unexpected turnout of technical communicators. The organizers were stunned to see the last minute registrations. Gururaj BS, the president for the STC India Community delivered the address keynote speech and shared the podium with Adobe Systems, Naresh Gupta, and Geoffrey Hart. After Gururaj’s welcome address, Chief Guest Naresh Gupta took the center stage. Naresh delivered a walk-through of Adobe’s products and the projects they are currently working on. Naresh also spoke a bit on the Adobe Captivate Beta version. During a Q&A session, when Naresh was asked if Adobe is planning to come out with a Content Management System (CMS), Naresh said they were not at all, and they are happy to work with their clients who are creating CMSs.
It was a red-letter day for STC India as Dr. Kiran Thakur, Head of the Department of Communication, University of Pune, talked on the inclusion of Technical Writing as a University program. It was the first such program in India, and Dr. Kiran introduced the gathering to the stalwarts behind the program, namely Makrand Pandit, Dr. Sunil Gokhale, and Frederick Menezes. He also gave a brief history of the program, the people developing it, its curriculum outline, and the challenges faced. He urged companies to support the program, as Pune University is a private institution and requires financial assistance to function.
Dr. Pradeep delivered “Exploiting the power of communication in Aerospace Industry,” which was followed by an interesting DITA session by Sandhya Ravishankar (Citec Academy), who suggested Darwin Information Typing Architecture (DITA) for large documentation projects with large content. DITA is an XML-based, end-to-end architecture for authoring, producing, and delivering technical information, which was developed by IBM. She also highlighted training as a core component for writers to fully use DITA.
Next in the pipeline were interesting presentations on “MS Office Security” and “Business of Technical Communication” by Khushboo Jitra (NII Consulting) and John Rosberg (Interwoven).). Khusboo, articulate in her presentation, provided a few strategies for the password protection of MS Word documents and related some document security incidents. John Rosberg identified the business aspects of technical writing and laid a path for technical writers to identify and analyze those issues in real-life scenarios.
But the speaker of the day (in my opinion) was Francisco Abedrabbo. Francisco delivered a keynote on “Tips to Grow Your Writing Career: A Manager's Perspective.”
Amidst all this activity, Frederick Menezes (Symantec) hosted the Quiz preliminaries. Four teams qualified for the finals from the written round. In the evening, a jam session was organized for the technical writers to unwind and "kick up their heels." It certainly grew entertaining as the DJ played some peppy numbers.
Final Conference Day Activities
The final day of the conference began with a presentation on “Documentation Program Management” by Vasanth Vaidyanathan and Anjana Sriram. It was followed by Suman Kumar’s (Dell) session on usability testing. Suman briefed the audience on the principles of usability testing, with suitable examples, but did not have of time, to not go into detail. Mary Alexander, a master in her own right, spoke on RSS Blogs and forums.
Everyone was geared up to witness the all-important panel discussion comprising stalwarts like Makrand Pandit, Gururaj BS, and Sai Kavitha, which was moderated by Manoj Bokil. Each of the dignitaries spoke on their respective arenas. Mak provided his views on making technical communication a business; Gururaj spoke on the career path for a technical writer; and Sai Kavitha delivered technical communication from a manager’s perspective as a panel discussion with a Q&A session following the presentation.
Frederick Menezes hosted the Quiz final session with the gathering cheering for their favorites. The team of Akash Dubey, Vasudha Rangarajan, and Anthony Francis took the winner’s title.
Conclusion
Amidst all this knowledge sharing, the conference was a hub for various companies to set up their stalls, not only to promote their companies, but also to solicit feedback from the delegates. In addition, there were organized contests and hordes of prize awards. The 8th STC Regional Conference–Bangalore proved to be a showcase for sharing knowledge and dispersing the diversity of technical communication.
Conference Opens on December 7th
Geoffrey Hart opened the 8th STC regional conference on Thursday, 7th December. Popularly well-known in the technical writing circuit, Geoff Hart is a freelance writer, editor, and translator who specializes in scientific and technical communication. Geoffrey Hart delivered the first workshop on Editing, where he spoke of the intricacies of editing in detail, streamlined the editing process, and was never short of jokes. The audience couldn’t help but laugh when he addressed “technical writers as rabbits in a jungle.”
In a concurrent session, Timo Nevalainen addressed writers on the usefulness of content management for online writing. Timo emphasized the importance of content management saying that it is having “the Right systems for the Right People.”
Rajeev Jain (Zilog), Mary Ann Alexander (Pivotal), and Deepak/Siddarth delivered additional workshops that covered the API Style Guide, FrameMaker Insights, and Project Management. The highlight of the pre-conference workshop was undoubtedly the presentation delivered on Leadership Development/ Management excellence by SVP, HR, Symphony Services, Mahalingam. The speaker emphasized the importance of leadership in a project and supported the cause of “working with a business-oriented mind. Seasoned writer, Gyanesh Talwar, spoke on the “hot” topic brewing these days: XML in documentation and also spoke about Structured FrameMaker.
Conference Continues on December 8th
The following morning, December 8th, saw quite an unexpected turnout of technical communicators. The organizers were stunned to see the last minute registrations. Gururaj BS, the president for the STC India Community delivered the address keynote speech and shared the podium with Adobe Systems, Naresh Gupta, and Geoffrey Hart. After Gururaj’s welcome address, Chief Guest Naresh Gupta took the center stage. Naresh delivered a walk-through of Adobe’s products and the projects they are currently working on. Naresh also spoke a bit on the Adobe Captivate Beta version. During a Q&A session, when Naresh was asked if Adobe is planning to come out with a Content Management System (CMS), Naresh said they were not at all, and they are happy to work with their clients who are creating CMSs.
It was a red-letter day for STC India as Dr. Kiran Thakur, Head of the Department of Communication, University of Pune, talked on the inclusion of Technical Writing as a University program. It was the first such program in India, and Dr. Kiran introduced the gathering to the stalwarts behind the program, namely Makrand Pandit, Dr. Sunil Gokhale, and Frederick Menezes. He also gave a brief history of the program, the people developing it, its curriculum outline, and the challenges faced. He urged companies to support the program, as Pune University is a private institution and requires financial assistance to function.
Dr. Pradeep delivered “Exploiting the power of communication in Aerospace Industry,” which was followed by an interesting DITA session by Sandhya Ravishankar (Citec Academy), who suggested Darwin Information Typing Architecture (DITA) for large documentation projects with large content. DITA is an XML-based, end-to-end architecture for authoring, producing, and delivering technical information, which was developed by IBM. She also highlighted training as a core component for writers to fully use DITA.
Next in the pipeline were interesting presentations on “MS Office Security” and “Business of Technical Communication” by Khushboo Jitra (NII Consulting) and John Rosberg (Interwoven).). Khusboo, articulate in her presentation, provided a few strategies for the password protection of MS Word documents and related some document security incidents. John Rosberg identified the business aspects of technical writing and laid a path for technical writers to identify and analyze those issues in real-life scenarios.
But the speaker of the day (in my opinion) was Francisco Abedrabbo. Francisco delivered a keynote on “Tips to Grow Your Writing Career: A Manager's Perspective.”
Amidst all this activity, Frederick Menezes (Symantec) hosted the Quiz preliminaries. Four teams qualified for the finals from the written round. In the evening, a jam session was organized for the technical writers to unwind and "kick up their heels." It certainly grew entertaining as the DJ played some peppy numbers.
Final Conference Day Activities
The final day of the conference began with a presentation on “Documentation Program Management” by Vasanth Vaidyanathan and Anjana Sriram. It was followed by Suman Kumar’s (Dell) session on usability testing. Suman briefed the audience on the principles of usability testing, with suitable examples, but did not have of time, to not go into detail. Mary Alexander, a master in her own right, spoke on RSS Blogs and forums.
Everyone was geared up to witness the all-important panel discussion comprising stalwarts like Makrand Pandit, Gururaj BS, and Sai Kavitha, which was moderated by Manoj Bokil. Each of the dignitaries spoke on their respective arenas. Mak provided his views on making technical communication a business; Gururaj spoke on the career path for a technical writer; and Sai Kavitha delivered technical communication from a manager’s perspective as a panel discussion with a Q&A session following the presentation.
Frederick Menezes hosted the Quiz final session with the gathering cheering for their favorites. The team of Akash Dubey, Vasudha Rangarajan, and Anthony Francis took the winner’s title.
Conclusion
Amidst all this knowledge sharing, the conference was a hub for various companies to set up their stalls, not only to promote their companies, but also to solicit feedback from the delegates. In addition, there were organized contests and hordes of prize awards. The 8th STC Regional Conference–Bangalore proved to be a showcase for sharing knowledge and dispersing the diversity of technical communication.
Monday, November 13, 2006
Ten commandments of a successful author
Ten commandments of a successful author..EXTRACT FROM Author: vrflash
United States, English translator
1. Read. Otherwise, how will you know you haven’t written something what has already been done?
2. Cut, cut, cut. To keep or not to keep? To be or not to be? If you can live without that word, than the answer is not to keep.
3. Listen to the editor. Follow the publication’s guidelines. They exist for a reason. You may not understand these reasons yet, but why annoy an editor?
4. Check the checker. Let the computer spell-check the work first and then proofread it manually. Computers might be not very smart, but they have a mind of their own and are happy to create havoc with your manuscript if you let them.
5. Avoid clichés like the plague. Why write something that has already been beaten to death?
6. Bring new things into the world. Be creative so that they will publish and read you instead of Joe Shmoe or Jane Doe.
7. Be persistent. Submit your work for publication. Too many talented writers keep a heap of dusty manuscripts under their beds.
8. Start a new. Once you’ve sent your manuscript out, don’t bother the editor with requests for status. Write the next one.
9. Don’t despair. If the manuscript is rejected, edit it and send it to another publication.
10.Know when to quit. If the manuscript gets constant rejections, put it away. Your bestseller is waiting for you to be written, so why waste your time with a dud
United States, English translator
1. Read. Otherwise, how will you know you haven’t written something what has already been done?
2. Cut, cut, cut. To keep or not to keep? To be or not to be? If you can live without that word, than the answer is not to keep.
3. Listen to the editor. Follow the publication’s guidelines. They exist for a reason. You may not understand these reasons yet, but why annoy an editor?
4. Check the checker. Let the computer spell-check the work first and then proofread it manually. Computers might be not very smart, but they have a mind of their own and are happy to create havoc with your manuscript if you let them.
5. Avoid clichés like the plague. Why write something that has already been beaten to death?
6. Bring new things into the world. Be creative so that they will publish and read you instead of Joe Shmoe or Jane Doe.
7. Be persistent. Submit your work for publication. Too many talented writers keep a heap of dusty manuscripts under their beds.
8. Start a new. Once you’ve sent your manuscript out, don’t bother the editor with requests for status. Write the next one.
9. Don’t despair. If the manuscript is rejected, edit it and send it to another publication.
10.Know when to quit. If the manuscript gets constant rejections, put it away. Your bestseller is waiting for you to be written, so why waste your time with a dud
Wednesday, June 14, 2006
Good Writing Leads to Good Quality Testing
This is an extract from "Benefits of Written Artifacts by Mike Alexander"
______________________________________
While the process of writing can be helpful to your testing efforts, the results of those efforts provide unique benefits of their own. Again, not all test groups produce the same types of documents, and the terms "test plan" and "test case" mean vastly different things to different people. In any case, any written documents you produce as part of your test efforts will provide some, if not all, of the following benefits.
Documents serve as useful artifacts that can be shared with other departments within your company, with regulatory agencies, with test partners, and with any other interested parties. If written well, your documents will provide these third parties with the information they need. That way, you can spend your time testing rather than answering questions about poorly written documents.
You also establish yourself as a reliable source of information, which will be good for your career. If, however, your writing is sloppy or incomplete, chances are you'll spend more time clarifying what you "meant to say" than you did writing in the first place. You will be perceived as disorganized or as a muddled thinker, which will not be good for your career.
At times, testers prepare documents in order to actively solicit questions and comments. Another benefit of a well-written document is that it can be distributed long before other people's responses are needed. That way, your audience has sufficient time to review your work, come up with their own list of items for clarification, and present their questions to you in a helpful fashion. Without a written document to distribute in advance, the responses from your audience will be "on the spot" and may not be as comprehensive as you would prefer.
The writings of one test team member can also serve as models or guides for others. Chances are that not every member on the test team will have the same level of skill or comfort with writing. In those cases, the well-written works of some members make good examples for the rest of the group to study when developing their own writing skills. While templates carry potential problems of their own (see the Pitfalls section below), when used appropriately as a guide they are an excellent way to help others improve skills by example.
Your writing can also benefit the entire test team by providing a single, professional "look and feel" for the group. By using the same well-prepared document outlines or "shells," each member of the test team can write in his or her own personal style while maintaining the written "image" of the group. Of course, the quality of the writing that "fills in" the outline must be high, or else the image is quickly undermined. Just because different team members' writing looks the same doesn't necessarily mean that it's written well.
Many testers I have met share the feeling that they are seen as less-than-equals by the development teams they work with. Quality writing is a trait that all professionals seem to appreciate, particularly when the document must stand on its own without the author present to back it up. An author must be confident in and knowledgeable of a topic to write well about it. Quality documentation tells developers and management that the author is a professional, which elevates their perception of the author and of the whole test team.
______________________________________
While the process of writing can be helpful to your testing efforts, the results of those efforts provide unique benefits of their own. Again, not all test groups produce the same types of documents, and the terms "test plan" and "test case" mean vastly different things to different people. In any case, any written documents you produce as part of your test efforts will provide some, if not all, of the following benefits.
Documents serve as useful artifacts that can be shared with other departments within your company, with regulatory agencies, with test partners, and with any other interested parties. If written well, your documents will provide these third parties with the information they need. That way, you can spend your time testing rather than answering questions about poorly written documents.
You also establish yourself as a reliable source of information, which will be good for your career. If, however, your writing is sloppy or incomplete, chances are you'll spend more time clarifying what you "meant to say" than you did writing in the first place. You will be perceived as disorganized or as a muddled thinker, which will not be good for your career.
At times, testers prepare documents in order to actively solicit questions and comments. Another benefit of a well-written document is that it can be distributed long before other people's responses are needed. That way, your audience has sufficient time to review your work, come up with their own list of items for clarification, and present their questions to you in a helpful fashion. Without a written document to distribute in advance, the responses from your audience will be "on the spot" and may not be as comprehensive as you would prefer.
The writings of one test team member can also serve as models or guides for others. Chances are that not every member on the test team will have the same level of skill or comfort with writing. In those cases, the well-written works of some members make good examples for the rest of the group to study when developing their own writing skills. While templates carry potential problems of their own (see the Pitfalls section below), when used appropriately as a guide they are an excellent way to help others improve skills by example.
Your writing can also benefit the entire test team by providing a single, professional "look and feel" for the group. By using the same well-prepared document outlines or "shells," each member of the test team can write in his or her own personal style while maintaining the written "image" of the group. Of course, the quality of the writing that "fills in" the outline must be high, or else the image is quickly undermined. Just because different team members' writing looks the same doesn't necessarily mean that it's written well.
Many testers I have met share the feeling that they are seen as less-than-equals by the development teams they work with. Quality writing is a trait that all professionals seem to appreciate, particularly when the document must stand on its own without the author present to back it up. An author must be confident in and knowledgeable of a topic to write well about it. Quality documentation tells developers and management that the author is a professional, which elevates their perception of the author and of the whole test team.
Sunday, June 11, 2006
Getting a new look-TWIN-LAUNCH Portal!
Last Saturday (June 10, 2006) was a special day for Technical Writers of India especially for the people behind the portal Twin-India. It was a befitting occasion to be celebrated since TWIN has had worked selflessly for this. I was fortunate enough to be a part of this historical occasion and tried my level best to look as calm and composed I could be in front of a gathering that had stalwarts like Gururaj BS, Vasudha Rangarajan, Suman Kumar, Pradeep Vasudevan and whole set of more.
I reached exactly at 4:30 sharp at the venue Nahar Cottage that is on St.Marks Road. Gururaj,who welcomed all the dignitaries and was looking stunning in his dark green shirts. The host for the show was Anthony Francis,a versatile technical writer who after welcoming the audience asked Mr.John Thomas, the Vice Dean at the Indian Institute of Journalism and New Media, to launch the the TWIN portal at Hotel Nahar Heritage, Bangalore.
Mr.Thomas shared his inputs on Technical Writing and reminded the gathering of the launching of his India's first Online Newspaper, Deccan Herald. He saw technical writing a boon for the next generation and said that it should be a part of the curriculm.
Next was the launch of http://twin-india.org that is developed using the content management tool -Drupal. Pradeep Vasudevan gave a brief on how the work on the revamping of portal was started and handed it over to Suman Kumar. Suman presented an overview of how the revamping of portal was done and why they chose to use Drupal instead of other CMS tools like Mambo etc.
A few of the objects while selecting the CMS tool were :
Open-source
Price
User-friendly
Capability of handling features
Search Capabilty
After Suman had completed the presentation few questions were asked as if it would be possible to attach a file these days while sending posts in TWIN. Gururaj responded that by saying that it would depend on the 'theme of the file' and the moderator needs to approve the file first to be posted. A break was taken after that!
After relishing the delicacies of Jamoon, sandwich and samosas, Francis asked senior technical writers to share their TWIN experience. Miss. Vasudha spoke first and than Akash Dubey in his comical note delivered a speech. I was honored to read out a speech of ex-STC India President Mr.Makrand Pandit. A few points that Makrand etched out in his note were to reduce the flame wars that takes place in TWIN these days and to find out some good technical writers from the forum.
The meeting ended with the TWIN List Admin, Sandeep giving the vote of thanks. We all than dispersed.
It was a very eventful occasion perhaps a few more technical writers would have done great.
So enjoy the new portal, and in case you haven't browse through take a look at it http://twin-india.org.
These are my personal comments and in way are related to any groups. In case you wish to respond, please send me your comments at holypriest@gmail.com
I reached exactly at 4:30 sharp at the venue Nahar Cottage that is on St.Marks Road. Gururaj,who welcomed all the dignitaries and was looking stunning in his dark green shirts. The host for the show was Anthony Francis,a versatile technical writer who after welcoming the audience asked Mr.John Thomas, the Vice Dean at the Indian Institute of Journalism and New Media, to launch the the TWIN portal at Hotel Nahar Heritage, Bangalore.
Mr.Thomas shared his inputs on Technical Writing and reminded the gathering of the launching of his India's first Online Newspaper, Deccan Herald. He saw technical writing a boon for the next generation and said that it should be a part of the curriculm.
Next was the launch of http://twin-india.org that is developed using the content management tool -Drupal. Pradeep Vasudevan gave a brief on how the work on the revamping of portal was started and handed it over to Suman Kumar. Suman presented an overview of how the revamping of portal was done and why they chose to use Drupal instead of other CMS tools like Mambo etc.
A few of the objects while selecting the CMS tool were :
Open-source
Price
User-friendly
Capability of handling features
Search Capabilty
After Suman had completed the presentation few questions were asked as if it would be possible to attach a file these days while sending posts in TWIN. Gururaj responded that by saying that it would depend on the 'theme of the file' and the moderator needs to approve the file first to be posted. A break was taken after that!
After relishing the delicacies of Jamoon, sandwich and samosas, Francis asked senior technical writers to share their TWIN experience. Miss. Vasudha spoke first and than Akash Dubey in his comical note delivered a speech. I was honored to read out a speech of ex-STC India President Mr.Makrand Pandit. A few points that Makrand etched out in his note were to reduce the flame wars that takes place in TWIN these days and to find out some good technical writers from the forum.
The meeting ended with the TWIN List Admin, Sandeep giving the vote of thanks. We all than dispersed.
It was a very eventful occasion perhaps a few more technical writers would have done great.
So enjoy the new portal, and in case you haven't browse through take a look at it http://twin-india.org.
These are my personal comments and in way are related to any groups. In case you wish to respond, please send me your comments at holypriest@gmail.com
Monday, June 05, 2006
A speech worth reading for IT programmers
Hi All,
Get Back to ur Basics!!!
I really enjoyed reading the speech given by Principal Scientist, Adobe Systems. Also got the list of the books we have to get back to…
Advice to young programmers (This is the summary of speech Given by Alex Stepenov (Principal Scientist, Adobe Systems) at Adobe India on 30 Nov 2004. )
1. Study , Study and Study - Never ever think that you have acquired all or most of the knowledge which exists in the world. Almost everybody in US at age of 14 and everybody in India at age of 24 starts thinking that he has acquired all the wisdom and knowledge that he needs. This should be strictly avoided. - You should be habituated to studies...exactly in the same way as you are habituated to brushing
teeth and taking bath every morning.
The habit of study must become a 'part of your blood'. And the study should be from both the areas: CS,since it is your profession, and something from non-CS...Something which doesnot relate to your work. This would expand your knowledge in other field too. A regular study, everyday, is extremely essential. It doesnot matter whether you study of 20 minutes of 2 hours, but consistency is a must. - You should always study basics and fundamentals.
There is no point in going for advanced topics. When I was at the age of 24, I
wanted to do PhD in program verification, though I was not able to understand anything from that. The basic reason was that my fundamental concepts were not clear. Studying 'Algebraic Geometry' is useless if you donot understand basics in Algebra and Geometry. Also, you should always go back and re-read and re-iterate over the fundamental concepts. What is the exact definition of 'fundamental'? The stuff which is around for a while and which forms basic part of the concepts can be regarded as
more fundamental. Of course, everybody understands what a fundamental means. - Here are few books which I would strongly recommend that every CS professional should read and understand.
i."Structure and Interpretation of Computer Programs" by Albenson and Sussman I
personally donot like the material present in this book and I do have some objections about it but this is the best book I have ever seen which explains all the concepts in programming in a clear and excellent way.
ii.Introduction to Computer Architecture: by Hennessy and Patterson.
How many of you have shipped the programs by writing them in assembly? A very good understanding of basics of how a computer operates is what every CS professional must have. H&P Wrote two books on CA. I am talking about their first book, the introductory text for understanding basic aspects of how a computer works. Even if you feel that you know whatever is written in that book, donot stop reading. It's good to revise basics again and again.
iii."Fundamentals of Programming" by Donald Knuth. The core of CS is algorithms and Data structures. Every CS professional must have the 3 volumes of Knuth's Book on programming. It really does not matter if you take 30 years of your life to understand what Knuth has written, what is more important is that you read atleast some part of that book everyday without fail.
iv. Introduction to Algorithms by Cormen, Leiserson and Rivest This book should be read daily to keep your concepts fresh. This is the best book for fundamental concepts in algorithms.
2. Learn Professional Ethics - As a CS Professional, you are morally obliged to do a good job. What this means is that you are supposed to do your job not for your manager but for yourself. This is already told in Bhagwatgeeta : Doing duties of your life. - The direct implication of this is: never ever write a bad code. You don't need to be fastest and run after shipping dates; rather you need to write quality code. Never write junk code. Rewrite it till it is good. Thoroughly test every piece of code that you write. Donot write codes which are "sort of allright". You might not achieve perfection, but atleast your code should be of good quality. - Let me quote my own example in this context.
You might have heard about STL, The Standard Template Library that ships in with C++ compilers. I wrote it 10 years ago, in 1994. While implementing one of the routines in the STL, namely the "search routine", I was a bit lazy and instead of writing a good linear order implementation of KMP which was difficult to code, I wrote a best quadratic implementation. I knew that I could make the search faster by writing a linear-order implementation, but I was lazy and I did not do that. And, after 10 years of my writing STL, exactly the same implementation is still used inside STL and STL ships with an inefficient quadratic implementation of search routine
even today!! You might ask me: why can't you rewrite that?
Well...I cannot, because that code is no more my property!! Further, nobody today
will be interested in a standalone efficient STL ...people would prefer one which automatically ships out with the compiler itself. - Moral is, you should have aesthetic beauty built inside you. You should "feel" uneasy on writing bad code and should be eager to rewrite the code till it becomes upto the quality. And to the judge the quality, you need to develop sense regarding which algorithms to use under what circumstances.
3. Figure out your Goals - Always aspire doing bigger things in life - "Viewing promotion path as your career" is a completely wrong goal. If you are really interested in studying and learning new things, never ever aspire for being a manager. Managers cannot learn and study...they have no time. "Company ladder aspiration" is not what should be important for you. - You might feel that you want to do certain things which you cannot do till you become a manager.
When you become a manager, you will soon realize that now you just cannot do anything! - You will have a great experience as programmers. But if you care for people and love people, you will never enjoy being a manager...most good managers are reluctant managers. If you see people as people, you cannot survive at management level. - Always aspire for professional greatness. Our profession is very beautiful because we create abstract models and implement them in reality.
There is a big fun in doing that. We have a profession which allows us to do creative
things and even gives nice salary for that. - The three biggest mistakes that people usually make are aiming for money, aiming for promotion and aiming for fame. The moment you get some of these, you aspire for some more...and then there is no end. I donot mean that you shouldnot earn money, but you should understand how much money would satisfy your needs. Bill Clinton might be the richest person in the world; he is certainly not the happiest. Our lives are far better than his. - Find your goal, and do best in the job that you have. Understand that what is in your pocket doesnot matter...what is in your brain finally matters. Money and fame donot matter. Knowledge matters.
4. Follow your culture I have seen the tradition that whatever junk is created in US, it rapidly spreads up in the rest of the world, and India is not an exception for this. This cultural change creates a very strong impact on everybody's life. Habits of watching spicy Bollywood or Hollywood movies and listening to pop songs and all such stupid stuff gets very easily cultivated in people of your age...but believe me,
there is nothing great in that. This all just makes you run away from your culture. And there is no wisdom in running away from your culture.
Indian culture, which has great Vedas and stories like Mahabharata and Bhagwatgeeta is really great and even Donald Knuth enjoys reading that. You should understand that fundamental things in Indian culture teach you a lot and you should never forget them. Finally, I would like to conclude by saying that it's your life...donot waste it on stupid things...develop your tests, and start the fight.
Get Back to ur Basics!!!
I really enjoyed reading the speech given by Principal Scientist, Adobe Systems. Also got the list of the books we have to get back to…
Advice to young programmers (This is the summary of speech Given by Alex Stepenov (Principal Scientist, Adobe Systems) at Adobe India on 30 Nov 2004. )
1. Study , Study and Study - Never ever think that you have acquired all or most of the knowledge which exists in the world. Almost everybody in US at age of 14 and everybody in India at age of 24 starts thinking that he has acquired all the wisdom and knowledge that he needs. This should be strictly avoided. - You should be habituated to studies...exactly in the same way as you are habituated to brushing
teeth and taking bath every morning.
The habit of study must become a 'part of your blood'. And the study should be from both the areas: CS,since it is your profession, and something from non-CS...Something which doesnot relate to your work. This would expand your knowledge in other field too. A regular study, everyday, is extremely essential. It doesnot matter whether you study of 20 minutes of 2 hours, but consistency is a must. - You should always study basics and fundamentals.
There is no point in going for advanced topics. When I was at the age of 24, I
wanted to do PhD in program verification, though I was not able to understand anything from that. The basic reason was that my fundamental concepts were not clear. Studying 'Algebraic Geometry' is useless if you donot understand basics in Algebra and Geometry. Also, you should always go back and re-read and re-iterate over the fundamental concepts. What is the exact definition of 'fundamental'? The stuff which is around for a while and which forms basic part of the concepts can be regarded as
more fundamental. Of course, everybody understands what a fundamental means. - Here are few books which I would strongly recommend that every CS professional should read and understand.
i."Structure and Interpretation of Computer Programs" by Albenson and Sussman I
personally donot like the material present in this book and I do have some objections about it but this is the best book I have ever seen which explains all the concepts in programming in a clear and excellent way.
ii.Introduction to Computer Architecture: by Hennessy and Patterson.
How many of you have shipped the programs by writing them in assembly? A very good understanding of basics of how a computer operates is what every CS professional must have. H&P Wrote two books on CA. I am talking about their first book, the introductory text for understanding basic aspects of how a computer works. Even if you feel that you know whatever is written in that book, donot stop reading. It's good to revise basics again and again.
iii."Fundamentals of Programming" by Donald Knuth. The core of CS is algorithms and Data structures. Every CS professional must have the 3 volumes of Knuth's Book on programming. It really does not matter if you take 30 years of your life to understand what Knuth has written, what is more important is that you read atleast some part of that book everyday without fail.
iv. Introduction to Algorithms by Cormen, Leiserson and Rivest This book should be read daily to keep your concepts fresh. This is the best book for fundamental concepts in algorithms.
2. Learn Professional Ethics - As a CS Professional, you are morally obliged to do a good job. What this means is that you are supposed to do your job not for your manager but for yourself. This is already told in Bhagwatgeeta : Doing duties of your life. - The direct implication of this is: never ever write a bad code. You don't need to be fastest and run after shipping dates; rather you need to write quality code. Never write junk code. Rewrite it till it is good. Thoroughly test every piece of code that you write. Donot write codes which are "sort of allright". You might not achieve perfection, but atleast your code should be of good quality. - Let me quote my own example in this context.
You might have heard about STL, The Standard Template Library that ships in with C++ compilers. I wrote it 10 years ago, in 1994. While implementing one of the routines in the STL, namely the "search routine", I was a bit lazy and instead of writing a good linear order implementation of KMP which was difficult to code, I wrote a best quadratic implementation. I knew that I could make the search faster by writing a linear-order implementation, but I was lazy and I did not do that. And, after 10 years of my writing STL, exactly the same implementation is still used inside STL and STL ships with an inefficient quadratic implementation of search routine
even today!! You might ask me: why can't you rewrite that?
Well...I cannot, because that code is no more my property!! Further, nobody today
will be interested in a standalone efficient STL ...people would prefer one which automatically ships out with the compiler itself. - Moral is, you should have aesthetic beauty built inside you. You should "feel" uneasy on writing bad code and should be eager to rewrite the code till it becomes upto the quality. And to the judge the quality, you need to develop sense regarding which algorithms to use under what circumstances.
3. Figure out your Goals - Always aspire doing bigger things in life - "Viewing promotion path as your career" is a completely wrong goal. If you are really interested in studying and learning new things, never ever aspire for being a manager. Managers cannot learn and study...they have no time. "Company ladder aspiration" is not what should be important for you. - You might feel that you want to do certain things which you cannot do till you become a manager.
When you become a manager, you will soon realize that now you just cannot do anything! - You will have a great experience as programmers. But if you care for people and love people, you will never enjoy being a manager...most good managers are reluctant managers. If you see people as people, you cannot survive at management level. - Always aspire for professional greatness. Our profession is very beautiful because we create abstract models and implement them in reality.
There is a big fun in doing that. We have a profession which allows us to do creative
things and even gives nice salary for that. - The three biggest mistakes that people usually make are aiming for money, aiming for promotion and aiming for fame. The moment you get some of these, you aspire for some more...and then there is no end. I donot mean that you shouldnot earn money, but you should understand how much money would satisfy your needs. Bill Clinton might be the richest person in the world; he is certainly not the happiest. Our lives are far better than his. - Find your goal, and do best in the job that you have. Understand that what is in your pocket doesnot matter...what is in your brain finally matters. Money and fame donot matter. Knowledge matters.
4. Follow your culture I have seen the tradition that whatever junk is created in US, it rapidly spreads up in the rest of the world, and India is not an exception for this. This cultural change creates a very strong impact on everybody's life. Habits of watching spicy Bollywood or Hollywood movies and listening to pop songs and all such stupid stuff gets very easily cultivated in people of your age...but believe me,
there is nothing great in that. This all just makes you run away from your culture. And there is no wisdom in running away from your culture.
Indian culture, which has great Vedas and stories like Mahabharata and Bhagwatgeeta is really great and even Donald Knuth enjoys reading that. You should understand that fundamental things in Indian culture teach you a lot and you should never forget them. Finally, I would like to conclude by saying that it's your life...donot waste it on stupid things...develop your tests, and start the fight.
Wednesday, May 31, 2006
Project Getting Lifecycled!!!
For those of you caught unaware of the dreaded 'Project Life Cycle' during the Interview phase, here's a sneek peek-a-boo of what a Project Life Cycle.
Project Life Cycle!!!
Project Life Cycle!!!
Wednesday, May 24, 2006
To B or not to be an OBC!!!!
This is a premonition concept that Government is for the people, of the people and by the people. Atleast, Mr. Abraham Lincoln would be visualized crying in the grave at the pangs of human morality and lo at the sign of India..I am not going to delve much into the OBCs funda, I'll just narrate certain experiences why I feel it's inadequate to point out certain instances here. Let me see if I can analyze it in a better tone.
It has been 50 years and more now, since Jawahar Lal Nehru gave that famous speech in Parliament, "At the stroke of midnight, when the whole world sleeps, India will rise to freedom." I am not sure, the freedom that Mr. Nehru than spoke off smelt of agony and disdain of lower castes the so called SC/sets. I am not against an OBC fight here, but I guess a lot of work has had done off-late for the OBCs. And there have been less dividends out of it. The OBCs or other backward classes have not been come upto the standard, and I don't find the reason to be a social stigma rather than consequences.
My question is though why does the Government' have the impulsive nature of correcting it by forcing reservation? In this case, can the government not look into the reasons as to what are the OBCs drawback? I'm sure,there have been multiple committees formed to justify and come out the cases-but you and I know the best--the diary is full and all the reports are dumped into the garbage can. So, now the government has decided to come up with another solution--that is enforcing OBC reservation as if it's giant to deliver this time?
Politics plays a whole set of cards in India. Knowingly or unknowingly, you'll be engulfed in a storm of politicians who are braving their wits for a game of votes. The much respected and beloved minister for human resource and development, who at an age of 82 has decided to call an act has brought nothing but inhumane reaction from the different sections of society. Why did ARJUN play this gamble? Well, 1) he was upset that the veto power was vested in Manmohan Singh's cabinet for sometimes now, thought for a change 2) getting popular 3) Vote banks of Congress and 4) what else he could do?
The OBCs reservation policy has perhaps made the country witness the most volatile and inspired upheaval (if I may call it). I do see Rakesh Mehra's Rang De Basanthi doing some tricks out there, but it was a phenomenon nonetheless to see people scathing high and beat to stop this agitation. I was wondering how beautiful and strong are we when we get united. Doctors from all lore beated their hearts to join the agitated. IITs and IIMs took their prestigious lore into action as they activitely raised their voices, ongoing hunger strikes and lots more going on as I write this piece on May 23rd 2006 at Bangalore.
Questions were poured on Arjun Singh by the extreme Karan Thapar and mind you! Karan is not an easy joke. It was his interview that her Excellency Aama Jayalalithaa walked off as she felt that she was dragged off into an unnecessary controversy. Arjun Singh however, chose to remain tight-lipped during the interview and one point of time admitted the fact that the ordinance will be passed in the parliament irrespective of the fact that people like it or not. I don't see any reasons to talk to him on any matter!
The inhuman nature of the government could be understood more vividly as the government was busy in celebrating its 2nd anniversary, while atrocities were carried on large section of students point here is that not many people are affected by this. Would it culminate into an action, that
It has been 50 years and more now, since Jawahar Lal Nehru gave that famous speech in Parliament, "At the stroke of midnight, when the whole world sleeps, India will rise to freedom." I am not sure, the freedom that Mr. Nehru than spoke off smelt of agony and disdain of lower castes the so called SC/sets. I am not against an OBC fight here, but I guess a lot of work has had done off-late for the OBCs. And there have been less dividends out of it. The OBCs or other backward classes have not been come upto the standard, and I don't find the reason to be a social stigma rather than consequences.
My question is though why does the Government' have the impulsive nature of correcting it by forcing reservation? In this case, can the government not look into the reasons as to what are the OBCs drawback? I'm sure,there have been multiple committees formed to justify and come out the cases-but you and I know the best--the diary is full and all the reports are dumped into the garbage can. So, now the government has decided to come up with another solution--that is enforcing OBC reservation as if it's giant to deliver this time?
Politics plays a whole set of cards in India. Knowingly or unknowingly, you'll be engulfed in a storm of politicians who are braving their wits for a game of votes. The much respected and beloved minister for human resource and development, who at an age of 82 has decided to call an act has brought nothing but inhumane reaction from the different sections of society. Why did ARJUN play this gamble? Well, 1) he was upset that the veto power was vested in Manmohan Singh's cabinet for sometimes now, thought for a change 2) getting popular 3) Vote banks of Congress and 4) what else he could do?
The OBCs reservation policy has perhaps made the country witness the most volatile and inspired upheaval (if I may call it). I do see Rakesh Mehra's Rang De Basanthi doing some tricks out there, but it was a phenomenon nonetheless to see people scathing high and beat to stop this agitation. I was wondering how beautiful and strong are we when we get united. Doctors from all lore beated their hearts to join the agitated. IITs and IIMs took their prestigious lore into action as they activitely raised their voices, ongoing hunger strikes and lots more going on as I write this piece on May 23rd 2006 at Bangalore.
Questions were poured on Arjun Singh by the extreme Karan Thapar and mind you! Karan is not an easy joke. It was his interview that her Excellency Aama Jayalalithaa walked off as she felt that she was dragged off into an unnecessary controversy. Arjun Singh however, chose to remain tight-lipped during the interview and one point of time admitted the fact that the ordinance will be passed in the parliament irrespective of the fact that people like it or not. I don't see any reasons to talk to him on any matter!
The inhuman nature of the government could be understood more vividly as the government was busy in celebrating its 2nd anniversary, while atrocities were carried on large section of students point here is that not many people are affected by this. Would it culminate into an action, that
Sunday, May 14, 2006
The feel good factor!
Hi Rajdeep,
Thanks for that elaborate reply. It really helped a lot! Actually my company is of a medium size and I am the only TW here.At times, it gets difficult for me to learn new things. Even to begin with them. I feel that weird thing called Writer's block, which actually is a *technical* writer's block. I know what is to be written and how, but I
don't know how to present it and in which format! TWIN and seniors like you are making life easier for me.
I took a lot of keywords from your mail and googled them for more info. Got quite a lot. Thanks again for being so supportive. I hope I didn't annoy you with such basic questions.
Thanks and Warm Regards,
Mugdha
-----Original Message-----
From: Rajdeep Gupta [mailto:holypriest1@lycos.com]
Sent: Friday, May 12, 2006 10:27 AM
To: Mugdha Kulkarni
Subject: Re: [twin] Process for creating Application Help
Mugdha,
I hope you have gone through the links that Guruji has send across to it.Anyway, I'ld like to share a little insight on Help Application, primarily due to the reason that I actively started my Technical Writing career developing online help application and than scaled up doing other things.Please see my responses in-line.
Is there any standard process for generating Application Help?
Rajdeep:yes, there is. Based on the requirement set fort, an Online help is developed to cater the online audience. So, in general, you'll have the following things in your help--welcome note, about the help, audience of the help, logging into the application/system (since it's an online help,), features and task centric wise, Index and a question tag. Note that the help will have more screenshots than a PDF document has.
What are the steps that you guys generally follow?
Rajdeep: I'll tell you how I develop an Online Help. Primarily using Robohelp HTML, I import the Word document into the Robohelp application and the generate the Help. You can use Robohtml tutorials to get more insight on it.
What all comes as an input and in what format you are supposed to deliver the output?
Rajdeep: If you are using Robohelp, you can have multiple help outputs aka Webhelp, javahelp, flash help,webhelp pro, Oracle Help, WinHelp 2000,WinHelp 4 and WinHelp 3.
Who are the other professionals involved in this process?
Rajdeep: So far I have come across, I have worked with the developers for generating Online Help. The developers take all the map ids that each html file and corresponds it to the application for context-sensitive help. The quality assurance team will come later for testing the documentation.
What are the available tools and when do you choose each one of them?
Rajdeep: Using htmlhelp workshop(free tool), Roohelp, Madcap and etc you can generated online help. If you want to purchase a tool, I suggest Madcap or Robohelp.
Hope this helps!
Rajdeep
Thanks for that elaborate reply. It really helped a lot! Actually my company is of a medium size and I am the only TW here.At times, it gets difficult for me to learn new things. Even to begin with them. I feel that weird thing called Writer's block, which actually is a *technical* writer's block. I know what is to be written and how, but I
don't know how to present it and in which format! TWIN and seniors like you are making life easier for me.
I took a lot of keywords from your mail and googled them for more info. Got quite a lot. Thanks again for being so supportive. I hope I didn't annoy you with such basic questions.
Thanks and Warm Regards,
Mugdha
-----Original Message-----
From: Rajdeep Gupta [mailto:holypriest1@lycos.com]
Sent: Friday, May 12, 2006 10:27 AM
To: Mugdha Kulkarni
Subject: Re: [twin] Process for creating Application Help
Mugdha,
I hope you have gone through the links that Guruji has send across to it.Anyway, I'ld like to share a little insight on Help Application, primarily due to the reason that I actively started my Technical Writing career developing online help application and than scaled up doing other things.Please see my responses in-line.
Is there any standard process for generating Application Help?
Rajdeep:yes, there is. Based on the requirement set fort, an Online help is developed to cater the online audience. So, in general, you'll have the following things in your help--welcome note, about the help, audience of the help, logging into the application/system (since it's an online help,), features and task centric wise, Index and a question tag. Note that the help will have more screenshots than a PDF document has.
What are the steps that you guys generally follow?
Rajdeep: I'll tell you how I develop an Online Help. Primarily using Robohelp HTML, I import the Word document into the Robohelp application and the generate the Help. You can use Robohtml tutorials to get more insight on it.
What all comes as an input and in what format you are supposed to deliver the output?
Rajdeep: If you are using Robohelp, you can have multiple help outputs aka Webhelp, javahelp, flash help,webhelp pro, Oracle Help, WinHelp 2000,WinHelp 4 and WinHelp 3.
Who are the other professionals involved in this process?
Rajdeep: So far I have come across, I have worked with the developers for generating Online Help. The developers take all the map ids that each html file and corresponds it to the application for context-sensitive help. The quality assurance team will come later for testing the documentation.
What are the available tools and when do you choose each one of them?
Rajdeep: Using htmlhelp workshop(free tool), Roohelp, Madcap and etc you can generated online help. If you want to purchase a tool, I suggest Madcap or Robohelp.
Hope this helps!
Rajdeep
Tuesday, May 09, 2006
Documentation and QA-Two sides of a coin
Summary: This article written by Kumar Raman is all about wearing your documentation cap with pride as you do your other technical and quality caps. Documentation is as important as any other aspect of a project, like analysis, design, coding, testing, etc. The problem is that we do not realize its importance. Once we do, we can deliver products with a higher level of perfection. This has to be understood, appreciated, and infused into our system.
About the Author- Kumar Raman was a business journalist with a leading national economic daily in India. He has varied newspaper experience, picking up knowledge in domains such as finance, banking, insurance, stock markets, etc. In information technology, he has worked on both Microsoft and Java platforms, playing a variety of roles from analyst programmer to quality facilitator to project leader.
_________________________________________________
Before joining my current organization, I had never heard people talking about documentation as a separate area worthy of much attention. The general opinion was that anybody who was free could do it—whether creating plans (e.g., the QA plan, test plan, or SCM plan), templates for reviews, status reports, time sheets, or the user manual. Having special technical writers was considered a good idea, but a luxury.
An Eye-Opener
During the interview for my current job, I talked at length about everything from software process to management and metrics collection. I did not stress documentation, even though it is my core area. I felt that talking about documentation would sound like I had no other skills, because I considered it the least marketable skill. Even when my interviewer asked about my documentation work and experience, and then started to tell me why he thought that documentation can make or break a project, I did not think he took it seriously. Nevertheless, I joined the company to head the documentation area.
The day I joined, our managing director sent a message to everybody saying that no documents—internal or external—would leave the company without my review. He gave an example of how a well-written, thirty-page document fetched us a million-dollar project. “We knew we could deliver if we got the project, and the bridge between us and the project was our proposal. We understood this and worked hard on this. We took extra efforts to express ourselves fully with a professional and holistic appeal and that paid off. We got the project,” he told me later. This was a first for me: I saw someone at the top who felt documentation was an important part of quality assurance!
Documentation? What’s That?
We have all read a lot about technology, quality, certification, testing, automation tools, and processes. But how many of us have seen articles on documentation? There are few, not because documentation is not important, but because we have not yet realized its potential. There is still a perception in some that documentation is less significant than analysis, design, or coding.
But we should appreciate that fact that documentation projects have levels of maturity, just like the software process. The book Managing Your Documentation Projects by Joann T. Hackos is one of the best books on how project documentation can be standardized and how standardized project documentation improves a project’s quality. When compared to those levels, many software companies would not qualify as low-level documentation organizations, having only ad hoc documentation practices and no documentation experts. Most companies do not give a fraction of the importance to the documentation process that they give to their software development processes.
The fact is, careful documentation can save an organization time and money. Unless you are able to produce a document that makes the user comfortable and agreeable, no matter how superior your product might be, people will refuse to accept it. In my opinion, Microsoft’s MSDN is one of the finest product guides ever produced. Given the scale of products they offer, they would be lost without an established documentation standard. Today, even with their massive size, Microsoft launches products with professional documentation. Some may dismiss this by saying they have the resources that others lack. But did they always have the resources? At some point they placed a priority on documentation. That is one of the reasons that all their products are self-contained and successful. That saves millions of dollars, not only for Microsoft, but also for all kinds of businesses today.
Small companies also can gain by developing good documentation staff and practices. Often, a proposal fails to convert to a project because the proposal documentation lacks concise and expressive language, professional organization and polish. It may not be their inability to deliver, but their inability to express their capability.
For many, documentation is only about creating user manuals and online help, and even that documentation lacks an established process. When a project nears completion, a writer is called upon to document it. Someone sits with the technical writer and quickly runs through the application, telling the technical writer to prepare a user manual and to “please call on me if you have any questions…” The technical writer does their best to prepare a manual for the application. Then come the calls for more training or help over the phone, and half of the support staff will be answering queries on the user manual itself. Think how much time would have been saved if the documentation had been considered an important part of the process from the beginning.
Doing it is important!
It’s not that we don’t know how to do the documentation right. We just don’t think it’s important. The simplest thing one can do is to involve documentation people from project initiation and let them understand the project dynamics, technology, domain, and objective. We need to make sure the person who does the documentation—whether internal or external—understands the document audience well, and the purpose and objectives of creating the document. Once this is done, the documentation will be organized and articulated in a way that makes sense to the readers. The idea behind this is to take a proactive approach toward documentation. We will surely be better off planning our project documentation and executing it when the writers know the purpose and stay involved throughout the lifecycle.
To set our documentation standards in place, we need to integrate our software processes with our project documentation requirements; specifically, the various documents and records we create for our quality conformance purposes should adhere to set document standards. There might be the understanding that “we already have templates that we follow.” But I am not talking about the process we follow for certification’s sake (e.g., ISO or CMM). I am talking about synchronizing our real quality assurance with our documentation standards and other processes. Hence, it is very important that both our QA and documentation processes go hand-in-hand and that both departments work in synchrony. It actually has to be a synchrony triad—the processes defined by QA, followed by the technical people, and documented as per the standards.
Remember that change happens slowly. This morning, I spoke to our team of project owners and told them it is important to follow whatever standard templates and styles we publish. As I was enjoying my cup of coffee with a sense of satisfaction thinking about the morning session, I received a call from one of the project owners. He congratulated me on all my endeavours to bring order to the chaotic environment, and then he came to the point: “Kumar, I have a document to be reviewed. I wish I had time to format it in line with the dot template you sent me the other day; but I think you will appreciate that I have an important design review to attend. Can I send you the document and ask that one of your technical writers format it according to our style before it is reviewed?” I hung up the phone with a very hesitant “Yes.” Old habits die hard, but if we are persistent and patient, our efforts will pay off, and others will appreciate the importance of documentation to quality assurance.
About the Author- Kumar Raman was a business journalist with a leading national economic daily in India. He has varied newspaper experience, picking up knowledge in domains such as finance, banking, insurance, stock markets, etc. In information technology, he has worked on both Microsoft and Java platforms, playing a variety of roles from analyst programmer to quality facilitator to project leader.
_________________________________________________
Before joining my current organization, I had never heard people talking about documentation as a separate area worthy of much attention. The general opinion was that anybody who was free could do it—whether creating plans (e.g., the QA plan, test plan, or SCM plan), templates for reviews, status reports, time sheets, or the user manual. Having special technical writers was considered a good idea, but a luxury.
An Eye-Opener
During the interview for my current job, I talked at length about everything from software process to management and metrics collection. I did not stress documentation, even though it is my core area. I felt that talking about documentation would sound like I had no other skills, because I considered it the least marketable skill. Even when my interviewer asked about my documentation work and experience, and then started to tell me why he thought that documentation can make or break a project, I did not think he took it seriously. Nevertheless, I joined the company to head the documentation area.
The day I joined, our managing director sent a message to everybody saying that no documents—internal or external—would leave the company without my review. He gave an example of how a well-written, thirty-page document fetched us a million-dollar project. “We knew we could deliver if we got the project, and the bridge between us and the project was our proposal. We understood this and worked hard on this. We took extra efforts to express ourselves fully with a professional and holistic appeal and that paid off. We got the project,” he told me later. This was a first for me: I saw someone at the top who felt documentation was an important part of quality assurance!
Documentation? What’s That?
We have all read a lot about technology, quality, certification, testing, automation tools, and processes. But how many of us have seen articles on documentation? There are few, not because documentation is not important, but because we have not yet realized its potential. There is still a perception in some that documentation is less significant than analysis, design, or coding.
But we should appreciate that fact that documentation projects have levels of maturity, just like the software process. The book Managing Your Documentation Projects by Joann T. Hackos is one of the best books on how project documentation can be standardized and how standardized project documentation improves a project’s quality. When compared to those levels, many software companies would not qualify as low-level documentation organizations, having only ad hoc documentation practices and no documentation experts. Most companies do not give a fraction of the importance to the documentation process that they give to their software development processes.
The fact is, careful documentation can save an organization time and money. Unless you are able to produce a document that makes the user comfortable and agreeable, no matter how superior your product might be, people will refuse to accept it. In my opinion, Microsoft’s MSDN is one of the finest product guides ever produced. Given the scale of products they offer, they would be lost without an established documentation standard. Today, even with their massive size, Microsoft launches products with professional documentation. Some may dismiss this by saying they have the resources that others lack. But did they always have the resources? At some point they placed a priority on documentation. That is one of the reasons that all their products are self-contained and successful. That saves millions of dollars, not only for Microsoft, but also for all kinds of businesses today.
Small companies also can gain by developing good documentation staff and practices. Often, a proposal fails to convert to a project because the proposal documentation lacks concise and expressive language, professional organization and polish. It may not be their inability to deliver, but their inability to express their capability.
For many, documentation is only about creating user manuals and online help, and even that documentation lacks an established process. When a project nears completion, a writer is called upon to document it. Someone sits with the technical writer and quickly runs through the application, telling the technical writer to prepare a user manual and to “please call on me if you have any questions…” The technical writer does their best to prepare a manual for the application. Then come the calls for more training or help over the phone, and half of the support staff will be answering queries on the user manual itself. Think how much time would have been saved if the documentation had been considered an important part of the process from the beginning.
Doing it is important!
It’s not that we don’t know how to do the documentation right. We just don’t think it’s important. The simplest thing one can do is to involve documentation people from project initiation and let them understand the project dynamics, technology, domain, and objective. We need to make sure the person who does the documentation—whether internal or external—understands the document audience well, and the purpose and objectives of creating the document. Once this is done, the documentation will be organized and articulated in a way that makes sense to the readers. The idea behind this is to take a proactive approach toward documentation. We will surely be better off planning our project documentation and executing it when the writers know the purpose and stay involved throughout the lifecycle.
To set our documentation standards in place, we need to integrate our software processes with our project documentation requirements; specifically, the various documents and records we create for our quality conformance purposes should adhere to set document standards. There might be the understanding that “we already have templates that we follow.” But I am not talking about the process we follow for certification’s sake (e.g., ISO or CMM). I am talking about synchronizing our real quality assurance with our documentation standards and other processes. Hence, it is very important that both our QA and documentation processes go hand-in-hand and that both departments work in synchrony. It actually has to be a synchrony triad—the processes defined by QA, followed by the technical people, and documented as per the standards.
Remember that change happens slowly. This morning, I spoke to our team of project owners and told them it is important to follow whatever standard templates and styles we publish. As I was enjoying my cup of coffee with a sense of satisfaction thinking about the morning session, I received a call from one of the project owners. He congratulated me on all my endeavours to bring order to the chaotic environment, and then he came to the point: “Kumar, I have a document to be reviewed. I wish I had time to format it in line with the dot template you sent me the other day; but I think you will appreciate that I have an important design review to attend. Can I send you the document and ask that one of your technical writers format it according to our style before it is reviewed?” I hung up the phone with a very hesitant “Yes.” Old habits die hard, but if we are persistent and patient, our efforts will pay off, and others will appreciate the importance of documentation to quality assurance.
Monday, May 08, 2006
Open source does not make better code!
Open Source Does Not Make Better Code. Better Programmers Make Better Code.
Every now and then, I will see a "dispelling the myths of open source" type of article, blog, discussion, or whatever come my way, and it always seems to come around to the "more eyeballs means less defects" idea. For whatever reason, many open source proponents seem to believe that there is this rear guard of closed source folks spreading FUD about open source (even Microsoft has toned down their rhetoric lately). I think that less than 10% of the knowledgeable people out there actually claim that closed source is inherently more secure than open source. It definitely seems that most people (at least amongst those that voice an opinion) believe that open source software is inherently more secure than close source software.
In reality, what matters much more than "open" or "closed" source, is who is writing and reviewing the code, why they are doing it, and how long they are doing it. If I compare OSS project "Project A" to closed source project "Project B", and "Project A" is being written by five 15 year olds who just wrote "Hello World" last week for the first time, and "Project B" is being written by twenty crusty old timers, and "Project A" has a three person "community" and "Project B" has zero community inspecting the source, I still guarantee that "Project B" will blow "Project A" out of the water. Open source, closed source, it really does not matter.
Another thing that I find fallacious about this argument is the continual assumption that "open source" means "free." The two are not mutual ideas, not by a long shot. Nor are they mutually exclusive. Historically speaking, UNIX is "open source," but hardly "free." Indeed, the original BSD386 project was due to the desire for there to be a free UNIX. One of the reasons why so much System V source code has ended up in various UNIXs over the years is precisely because Sytem V was open source, and SCO’s lawsuits exist because System V was not free! On the other hand, there is plenty of free software that is not open source. Just got to any shareware repository and find a piece of freeware that is pre-compiled and that does not include source code.
What really matters is who is writing and reviewing the code, and money tends to attract the continued writing and review of code much better than whatever it is that actually motivates FOSS coders. Sure, some FOSS projects (Apache, Linux, BSD, MySQL, etc.) attract top talent, but just taking a look at Source Forge shows that the vast majority of Open Source projects go nowhere. To decide that FOSS is the best possible method of development and quality control based on Windows vs. Linux or Oracle vs. MySQL or IIS vs. Apache or PHP vs. Java, or whatever is silly. That is like saying that "a Dodge will always be faster than a Chevy" based upon a comparison between the Viper and the Corvette.
One of the reasons why these projects are able to attract such a large pool of developers and testers has less to do with the fact that they are "open source," but the fact that they are free. Only a minute percentage of Linux users ever touch their source code, let alone look at it (or even care about it). They are attracted by its phenomenal price/performance ratio. The same can be said for any FOSS project. Thanks to the widespread usage of various package managers, it is fairly uncommon for most mainstream Linux users to even compile from source, let alone modify compiler flags or make changes to source code. If these packages were closed source but still free, most of their users would still use them and be testing them.
The vast majority of lines of code are written under the radar of most people and do not get any attention. Try comparing a small sample of each type of software. Take a few dozen random items from Source Forge that are in at least a "release quality" state and compare them to a few dozen freeware applications. Then evaluate the difference between closed source and open source. I really cannot tell you what the results will be, but I do know that many of the open source pieces of code that I have used, outside of the "big stuff" (various UNIXs, Apache, MySQL, PostgreSQL) are not so great. For a project that lacks glamour, it is hard to attract someone to spend a large amount of time seriously working on it. It is that simple.
Mind you, I am not against open source or free software whatsoever! I use it all of the time in my day-to-day life, especially FreeBSD, Apache, MySQL, and Perl. But I also use a lot of paid and/or closed source software as well, like Windows, IIS, Oracle, Microsoft Office and so on. Some of my favorite pieces of software are simple shareware applications: Notetab Pro and ThumbsPlus immediately come to mind. It is very rare that I have ever wanted or needed to "look under the hood" of a piece of software. Tomcat/Jakarta required me to do so to find out why it was not behaving as documented. Indeed, most of the time that I have had to look at source code, it was to compensate for poor documentation, not to actually make any change or satisfy a curious itch. I was grateful to be able to inspect the source code, but I would have preferred better documentation instead.
Many of the arguments that I hear in favor of open source compare Windows to Linux, or Internet Explorer to Firefox. Windows vs. Linux just shows that the Linux coders are better, smarter, and more well organized than Microsoft's Windows coders. Microsoft has had something like ten years to get Internet Explorer right, and they still have not managed to get it nailed down. This is not news. The fact is, closed source shops consistently crank out many products better than Microsoft’s too. One can just as easily compare OS/2 Warp or BeOS or MacOSX to the version of Windows from the relevant timeframe, and Windows still falls short on many (if not most) benchmarks like security, stability, usability, and so on. I note that it is rare for someone to compare MySQL or PostgreSQL to Oracle or Microsoft SQL Server in an "open source versus closed source" debate. Why do we never hear ".Net versus Mono?" Even comparing Apache to IIS is difficult, because IIS is a significantly more ambitious piece of software than Apache.
Open source, in and of itself does not produce better code. Better coders and better testing produce better code. It is that simple. When a closed source shop has the better coders and better testing, they write the better software. When an open source project has better coders and better testing, they write better software. To think that just because a piece of code can be modified or inspected by anyone and everyone means that the best coders and testers will be modifying and testing that code is just not correct
--Article Written by J.JA
Every now and then, I will see a "dispelling the myths of open source" type of article, blog, discussion, or whatever come my way, and it always seems to come around to the "more eyeballs means less defects" idea. For whatever reason, many open source proponents seem to believe that there is this rear guard of closed source folks spreading FUD about open source (even Microsoft has toned down their rhetoric lately). I think that less than 10% of the knowledgeable people out there actually claim that closed source is inherently more secure than open source. It definitely seems that most people (at least amongst those that voice an opinion) believe that open source software is inherently more secure than close source software.
In reality, what matters much more than "open" or "closed" source, is who is writing and reviewing the code, why they are doing it, and how long they are doing it. If I compare OSS project "Project A" to closed source project "Project B", and "Project A" is being written by five 15 year olds who just wrote "Hello World" last week for the first time, and "Project B" is being written by twenty crusty old timers, and "Project A" has a three person "community" and "Project B" has zero community inspecting the source, I still guarantee that "Project B" will blow "Project A" out of the water. Open source, closed source, it really does not matter.
Another thing that I find fallacious about this argument is the continual assumption that "open source" means "free." The two are not mutual ideas, not by a long shot. Nor are they mutually exclusive. Historically speaking, UNIX is "open source," but hardly "free." Indeed, the original BSD386 project was due to the desire for there to be a free UNIX. One of the reasons why so much System V source code has ended up in various UNIXs over the years is precisely because Sytem V was open source, and SCO’s lawsuits exist because System V was not free! On the other hand, there is plenty of free software that is not open source. Just got to any shareware repository and find a piece of freeware that is pre-compiled and that does not include source code.
What really matters is who is writing and reviewing the code, and money tends to attract the continued writing and review of code much better than whatever it is that actually motivates FOSS coders. Sure, some FOSS projects (Apache, Linux, BSD, MySQL, etc.) attract top talent, but just taking a look at Source Forge shows that the vast majority of Open Source projects go nowhere. To decide that FOSS is the best possible method of development and quality control based on Windows vs. Linux or Oracle vs. MySQL or IIS vs. Apache or PHP vs. Java, or whatever is silly. That is like saying that "a Dodge will always be faster than a Chevy" based upon a comparison between the Viper and the Corvette.
One of the reasons why these projects are able to attract such a large pool of developers and testers has less to do with the fact that they are "open source," but the fact that they are free. Only a minute percentage of Linux users ever touch their source code, let alone look at it (or even care about it). They are attracted by its phenomenal price/performance ratio. The same can be said for any FOSS project. Thanks to the widespread usage of various package managers, it is fairly uncommon for most mainstream Linux users to even compile from source, let alone modify compiler flags or make changes to source code. If these packages were closed source but still free, most of their users would still use them and be testing them.
The vast majority of lines of code are written under the radar of most people and do not get any attention. Try comparing a small sample of each type of software. Take a few dozen random items from Source Forge that are in at least a "release quality" state and compare them to a few dozen freeware applications. Then evaluate the difference between closed source and open source. I really cannot tell you what the results will be, but I do know that many of the open source pieces of code that I have used, outside of the "big stuff" (various UNIXs, Apache, MySQL, PostgreSQL) are not so great. For a project that lacks glamour, it is hard to attract someone to spend a large amount of time seriously working on it. It is that simple.
Mind you, I am not against open source or free software whatsoever! I use it all of the time in my day-to-day life, especially FreeBSD, Apache, MySQL, and Perl. But I also use a lot of paid and/or closed source software as well, like Windows, IIS, Oracle, Microsoft Office and so on. Some of my favorite pieces of software are simple shareware applications: Notetab Pro and ThumbsPlus immediately come to mind. It is very rare that I have ever wanted or needed to "look under the hood" of a piece of software. Tomcat/Jakarta required me to do so to find out why it was not behaving as documented. Indeed, most of the time that I have had to look at source code, it was to compensate for poor documentation, not to actually make any change or satisfy a curious itch. I was grateful to be able to inspect the source code, but I would have preferred better documentation instead.
Many of the arguments that I hear in favor of open source compare Windows to Linux, or Internet Explorer to Firefox. Windows vs. Linux just shows that the Linux coders are better, smarter, and more well organized than Microsoft's Windows coders. Microsoft has had something like ten years to get Internet Explorer right, and they still have not managed to get it nailed down. This is not news. The fact is, closed source shops consistently crank out many products better than Microsoft’s too. One can just as easily compare OS/2 Warp or BeOS or MacOSX to the version of Windows from the relevant timeframe, and Windows still falls short on many (if not most) benchmarks like security, stability, usability, and so on. I note that it is rare for someone to compare MySQL or PostgreSQL to Oracle or Microsoft SQL Server in an "open source versus closed source" debate. Why do we never hear ".Net versus Mono?" Even comparing Apache to IIS is difficult, because IIS is a significantly more ambitious piece of software than Apache.
Open source, in and of itself does not produce better code. Better coders and better testing produce better code. It is that simple. When a closed source shop has the better coders and better testing, they write the better software. When an open source project has better coders and better testing, they write better software. To think that just because a piece of code can be modified or inspected by anyone and everyone means that the best coders and testers will be modifying and testing that code is just not correct
--Article Written by J.JA
Friday, May 05, 2006
Blogger's Introduction
An Indian by birth and a Bengali by choice, I believe diversity can be a source of strength rather than division, which is why I chose this profession- technical writing. As a technical writer I not only get a chance to write and work on diverse products and services but get a chance to mingle with various like minded folks from various communities. Knowledge shared is knowledge gained, and to a large extent my blog’s objectives is to share and learn technical writing knowledge amongst various quarters.
To speak a bit about myself: I am currently pursuing an Executive degree in Management from Alliance Business school, Bangalore and have a degree in Communications from Bangalore University. I started my career as a content writer for a portal called Indiainfo.com; my job responsibilities included planning, creating and managing portal news, editing articles and writing features for the portals’ Movies and Eves. I graduated myself from content writing to technical writing mainly due to my interest in technology related services. The first manual that I worked on was on a pocket calculator; it brought me a job and the company who took me on their hold was Xora Software Systems. I was with Xora for a year and a half wherein I learnt the intricacies of technical writing mainly the processes. During my stint in Xora, I developed user manuals, administrative guides, release notes, online help, marketing papers, build docs etc.
Success brings a lot of responsibilities, and my proactive nature was noticed by folks to entrust me to lead Bangalore Technical Writers Meetup. I took the onus and have been leading the group for a year and half now. It involves me in scheduling the meeting venues, topics, speakers, emailing the mailing list servs, managing the meetup website etc. Refer the meetup website for further details http://techwriter.meetup.com/2/; we are a group of more than 550+.
With two and half year of work experience, I find myself with Infosys Technologies as a Technical Communicator doing documentation alongside with Usability Testing. Also, I have done some work on Usability Testing of Documentation too. Apart from all this, I am a quizmaster and run the quizzing shows in Infosys, compose poems etc. Various articles of mine have been published online. In case, you are interested to have a brief look into my portfolio, please tinkle me sometimes. You can find me at holypriest@gmail.com
Happy Blogging!
To speak a bit about myself: I am currently pursuing an Executive degree in Management from Alliance Business school, Bangalore and have a degree in Communications from Bangalore University. I started my career as a content writer for a portal called Indiainfo.com; my job responsibilities included planning, creating and managing portal news, editing articles and writing features for the portals’ Movies and Eves. I graduated myself from content writing to technical writing mainly due to my interest in technology related services. The first manual that I worked on was on a pocket calculator; it brought me a job and the company who took me on their hold was Xora Software Systems. I was with Xora for a year and a half wherein I learnt the intricacies of technical writing mainly the processes. During my stint in Xora, I developed user manuals, administrative guides, release notes, online help, marketing papers, build docs etc.
Success brings a lot of responsibilities, and my proactive nature was noticed by folks to entrust me to lead Bangalore Technical Writers Meetup. I took the onus and have been leading the group for a year and half now. It involves me in scheduling the meeting venues, topics, speakers, emailing the mailing list servs, managing the meetup website etc. Refer the meetup website for further details http://techwriter.meetup.com/2/; we are a group of more than 550+.
With two and half year of work experience, I find myself with Infosys Technologies as a Technical Communicator doing documentation alongside with Usability Testing. Also, I have done some work on Usability Testing of Documentation too. Apart from all this, I am a quizmaster and run the quizzing shows in Infosys, compose poems etc. Various articles of mine have been published online. In case, you are interested to have a brief look into my portfolio, please tinkle me sometimes. You can find me at holypriest@gmail.com
Happy Blogging!
Subscribe to:
Posts (Atom)