January 9, 2018

Technical writing to Blogging

How to write a blog?


How to write a blog? How to become a blogger? This is the first question that comes to mind while starting a blog. Here I am sharing my blogging experience and journey.


I was never a blogger until I met Devarshi Dubey, UI designer, my colleague while working in Cognilytics, Gurgaon.

He was an enthusiast, a creative person ready to dive into the different arena, positively absorbing suggestions to experiment with new things. He was a blogger and used to write about motorcycles on Moto Rivista. We were a small team and so our interaction had crossed the boundaries of being just formal colleagues, we were more like friends. At that time he was creating a website wherein one can play movies online or can download it. I also used to give inputs in his idea and my suggestions were well apprehended by the team.

Later I also participated in the brainstorming of what a website should look like, what right elements should be there. Everything was going smoothly when one day he asked me, "why don't you write blogs?".

I was already a technical writer but writing blogs never came into my mind. I wondered who would read me but, everyone encouraged me and I started to write. My blog on Adobe RoboHelp got an overwhelming response. I was enthralled and the writing instinct triggered within me. Traffic of my blog was increasing, and so was my enthusiasm.I was not aware I can earn from the blog or how to monetize the blog?

Simultaneously, I was learning to make a website and experimenting with it. I learnt Google analytics, google ad world, SEO, social media marketing etc.

My blog was on Alltop list. I was growing day by day with my experiences by now I was aware of Google Adsense and I implemented it. It was a blunder I realized when one day I got a mail from google that my blog was blacklisted because of some unauthorized clicks on Adsense links.

It was a big breaker on my success path but, I held myself, and continued to write on the same blog irrespective of this blow. I was not interested in making money through the blog, by that time I started to enjoy writing so I decided not to stop neither to change the domain although when "dollars earned" reflecting on the blog gave an added motivation.

My intention was to educate out of college students who wanted to learn technical writing but was unaware of the correct direction and most of their questions remain unanswered. And after all, doing this was giving me lot of self-satisfaction.

So, I accepted this incidence as a part of learning and continued to add more skills to my skill set. I converted my setback into breakthrough when in order to remove the blacklist tag I researched a lot and gradually I learnt digital marketing, made my own website and wrote contents,

I became a content writer, content strategist, content marketer, web developer, digital marketer and web designer.

It was in September 2012 when I got a call from  Neha Srivastava. She called me up and asked If I can give her training on technical writing. My blog had rewarded me from my first student, and from the first day of Dussehra, I started as a trainer. I never stopped after that and was well known as a blogger and trainer in the technical writing community. My blog was the first step towards the creation of Information Developers Foundation.

Today also I cannot run google ad on this blog but still whenever I get time I do not forget to scribble for you. Never know I can help someone somewhere.

This was my journey as a blogger, soon I will come up with my experiences as a mentor.

"Blog, but with responsibility, you will be content may be with no extra dollar"- Rahul Karn

How did you experience the evolution of blogs in your personal life? Share your comments below…

January 6, 2018

Importing track change in PDF output

Authoring in MadCap Flare and Importing track change in PDF/Word output 

In my new organization, we were writing in the MadCap Flare v10 and generating PDF output and sending it for review, for testing, development, product management, customer support and security team.

Challange was to convey them the exact changes and places where the changes needed to be done.

It was simple for me, just to keep track change  ON. I did it but unfortunately, when I generated the PDF, track changes were not visible.

I checked all the possible options available but no luck. After research on google, I was able to make the similar feature that was introduced in the MadCap Flare v12.

I contacted my fellow technical writer who was using Flarev12. Then we were able to do it.

This is simple to do and very powerful feature of the review process.

How to preserve track change in Flare v12.


In the Project Organizer, open the Target for PDF or Word.
Select the Advanced tab.
In the Output Options section, select Preserve tracked changes.



To read more about this visit MadCap Flare

If you want to learn MadCap Flare join Information Developers Foundation training program. Click to read the details of training

December 24, 2017

Agilism: Following Tenets of Agile on path of Documentation



Agilism can be described as a concept, a doctrine, a philosophy, based on tenets of Agile manifesto and Agile principles, as applied to Software Product Development. It is interesting to share that Agile principles when applied to any product development process, enhance the rate of product delivery in general, with simple, working prototypes produced early in the project lifecycle. Early prototypes ensure customer satisfaction and encourage them to actively participate in shaping the product according to need and required functionality. It provides with opportunity to give directions, create changes according to need and ultimately, help the team to develop a product with value and maximum Return on Investment (ROI). Customer feedback helps the team to iterate, re-iterate the product in a continuous manner and help in fast, simple, and better product delivery. Cross-functional and self-organizing teams work best in this environment. Agile principles can be applied similarly to documentation product delivery, as well.

Effective agile documentation is a balancing act, for an Agile document developer. The goal is to write just enough documentation, just in time and just for right audience.
Application of Agile, to product documentation in general, while working on an Agile project enabled me, to align my documentation, with the developing software product. I worked with a truly Agile team, who were fast enough in product delivery, after each iteration. My journey from a Technical Writer to an Agile Technical Writer was really hard and exciting. To catch-up with such a team and simultaneously document the features of working financial product, it was necessary to know their working styles. Application of Shu Ha Ri model - the Japanese Martial art concept of training and learning, came handy to me in Agile documentation journey. Therefore, I began to learn from the basics. Enrolled myself in Agile awareness and training program in organisation and thus started my Agile journey.

This model, describes stages of learning from beginner to level of mastery, this concept helped me, in learning Agile principles and gaining the skills, required to create, agile documentation and later apply the same principles to my documentation style. According to this age old Japanese Martial Art concept:

Shu- Learn and then perform actions to become the showstopper and role model, for others to follow.
Ha- Innovate new styles of product deliveries, improvise, and apply Agile rules.
Ri- Transcend finally with your unique style to a different level and establish your own niche.

Agility is part of my daily routine now. I find myself somewhere between Shu - Ha stages where I have learned the principles of agility, and strictly and honestly following them in my style of agile documentation, with spikes, as and when required. This enabled me to gain customer confidence and produce faster, simpler, and better documentation with maximum Return on Investment (ROI) value!
Following Shu Ha Ri model may also help and envision the newcomers and future aspirants of technical writing field, in gradually setting up the stage for, creating an agile mindset and equally agile working environment. Technical communication community, practitioners, as well as the young aspirants, may gear up, learn and apply the Agile methodologies in their Technical Communication during project and product documentation. They can be encouraged to learn the need of continuous iteration, through feedback and fast document delivery, according to customer requirements. Produce incremental quality documents, with minimum or no defects. This will enable them to write just enough and just required, precise documents, which are light, simple, and easy to refactor.
Technical Writers and aspiring writers will get to know the nuances of writing in Agile which they would like to remember, innovate on their own, improvise, and apply to their styles of writing. They can learn to be on edge all the time, catch-up fast with changing environment, reap the benefits of learning new tools and technologies fast, to mold themselves with emerging technologies, and adjust to the changing requirements frequently. All this could be achieved by being agile enough to pick up new techniques and methodologies and leverage them to enjoy maximum benefit.

Shu Ha Ri model can enhance the quest for learning Agile methodologies, create a mindset for faster and simpler documentation and improvising further for advantage of technical writing community. This model urges the followers, to take a plunge in lake of agility, hone the skill and gradually apply it to their document deliveries, while adding a dash of technology and creativity, increase expertise to an extent where they become the trailblazers, on the path of documentation.  

Such an environment and mindset can be created by self-motivated individuals, who really want to make difference in smoother, faster product delivery and contribute in agile transformation. They should follow Agilism, follow tenets of Agile methodologies while learning through Shu- Ha- Ri model and walk through the path of Agile learning and gaining mastery in Agile documentation!


Author Biography
Shikha Saxena
Shikha Saxena is a Senior Technical Writer in HSBC Technology, Pune, India. She is actively involved in learning and applying Agile methodologies in product and business architectural documentation in financial domain. She is an active blogger on organizational intranet. Managed web content writing, editing, and publication of the same. She was a speaker and participant, in national (STC, Pune, India, July 2016) and International conferences (tekom/tcWorld February 2016, Bengaluru, India). She was one of the speakers in STC SUMMIT 2017  on ‘Art of Writing in Agile’. She was a lecturer, teacher, researcher, and mentor to Science (Biochemistry) and Engineering (Biotechnology) Graduates and Post Graduates of Uttar Pradesh Technical University (UPTU), in NCR, New Delhi, India, before her global career as a Software Engineer/Technical Writer (2009). She is certified COBOL (ICS, Scranton, PA, 1995) and VisionPlus programmer in Mainframe and has product development and testing experience in Cards and Collections domain. She holds Bachelor in Chemistry and Master in Biochemistry and Biochemical Engineering degrees. She earned Gold Medal and JN National Award during her Masters in Biochemical Engineering, in IIT, BHU, Varanasi, India (1993). She is certified CRA and Oncology Terminologist and published blogs, about her struggle, research, and cure, for her ailment, in global well-being sites of current organization. She is an avid reader of Hindi, Urdu verses/poetry. Loves cooking Indian cuisine and is an oil-on-canvas painter. She envisions community in multiple ways and contribute towards making society, vibrating and lively place!

Website: Digital Monk: The Storyteller




December 8, 2017

Technical writing trends for 2018

                         

Technical writers in 2018_

IT and technical communication industry is an ever-changing industry and there is no stagnancy when it's up to the technical aspects. Every now and then new updates and new technologies are reserving their place in the software industry. To sustain in this environment a technical writer needs to be armoured with the skills to become an asset to the industry. In this blog post, I have tried to mention few points that are necessary for a future technical writer. 

1. Will be Agile and Adaptive                                                                                                                A future technical writer should be agile and adaptive.  He should have an iterative approach to software delivery, in short agile that is to build software incrementally from the start of the project. He should be adaptive to new technology and updates to do the work in time box and effectively with negligible errors. Being adaptive helps to equip with new technologies in no time, reducing the time and effort given to a project.

2. Will love line of Code
A new age information developer should be well versed with the line of codes equally as the line of words. He should have a love for codes to understand and deliver the best documentation. He should not be necessarily a programmer but being in love of code will let him be the first choice for any company that needs documentation.

3. Will not follow traditional DDLC
The use of traditional Document Development Life Cycle will lose its frequency in future because it will have to make way for new methodologies of documentation. It is necessary for a future technical writer to be ready to absorb the new advancements for a better document development.

4. Will Ready to Automate 
Information Developers in the coming future will have to gear up themselves to automate the things for better performances. Automation reduces the efforts, errors and the delivery time in creating a document. A love for automating things will let a technical writer stand apart from the others.

5.  Will Content Curator to Content Marketer
Unlike a traditional technical writer, a future information developer should not only write a content but also will have to market it. He should promote, reach out on social media, connect with influencers, engage with the community, to market the content.

6.  Will be more Customer focused
A technical writer should be aware of the customer interaction with the document. The document should be customer friendly and should have the clarity to have a better understanding.  User manuals, online help etc are the things that are used by common people who are not technocrats so, it should be documented in such a way that even a non-tech background people can use it effectively.

7. Will not know the pain of unstructured authoring
Rinni Mahajan- TechComm Rising Star-2017
Structured authoring reduces the error percentage and consumes less time. In the coming years' industry will move more towards the use of structured authoring leaving the old unstructured authoring tool. 

8. Will be more open to explore and innovate
A  future technical writer should be open to experiments not only with the with tools and technologies but with his writing skills also. Creativity and experiments help in new discoveries that ease the documentation process.

9. Will Unlearn and Learn Continuously
To learn new things we have to unlearn old technologies. A technical writer deals with tools that are regularly updated so he should be ready to unlearn and learn to get the best out of every new update.

10. Will be a Generalised specialist
An updated and new-gen technical writer should not be just a technical writer but an information developer. The documentation will not be just a written document but preceded by some research and experiments too. An information developer should know all form of communication such as content writing, UX designing, business writing, digital marketing etc.

11. Will come more from engineering college than Art or Mass Communication.

12. Will have more Fun

Join Information Developers Foundation for Continous Learning.

December 1, 2017

Steps for Creating the Freelance Technical Writer CV

A CV can be the best tool to explain your expertise to a would-be client. Not all freelancers use a CV/resume to market their services or to convey their experience to their clients. It's a great way to convey complex things to the potential clients. A freelance CV is very different from the one used to apply for a job, and it’s a good idea to learn how to approach CV development for freelance work even if you decide it’s an approach that isn’t right for your business. If you’re starting a new design agency with only you or a partner, you should also consider including a resume on your “about page”.
According to many freelancers, the easiest way to convey their expertise and experience to a client is in a CV/Curriculum Vitae/resume format. Many freelancers use a very different style of CV once they have a few projects under their belts though, it can be produced in the conventional format occasionally.

Short and Crisp like your Doc
The best CVs are short and to the point. There are some exceptions to this rule (for example, IT contractors who may change projects every few months) but, in general—the shorter the better.
If you’re going to be competing against a bunch of other freelancers for a project, keeping things short will make you unique and make it easier for a client to push you further into the selection process.
An ideal freelance CV covers a single page and no more than two pages.
“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
– Steve Jobs

This is one of the best rule for everything in life—not just freelance CVs—Keep It Simple Stupid. The less wordy you are, the easier it will be for a client to get involved with what you do. But you have to work hard to get your thinking clean to make it simple, as simple is often harder than complex.

What goes into a Freelance CV?
 Depending on their profession, their industry vertical, and their target audience a freelance CV inputs will vary from freelancer to freelancer. However, most freelance CVs will include:

1. Your Personal Profile
This is a brief statement of who you are and what you do. It’s where you make it clear what you offer to the client. If you are dealing with a specific client, you will want to tailor this profile to their needs. You will be more general if you make this available for download on your website or from a freelance job board. In general, you should not focus on describing yourself but describing what you can do for your client. Please remember—the client is not interested in you but in how you can help them.

2. Your List of Skills
Break this down into a manageable list (again—if a client is looking for certain skills—make sure they’re on this list). Ideally, unless you’re looking at a ridiculously complex project, you will want to keep this to a list of no more than 5–10 skill sets. Pick only those skills that are saleable to clients (pretty much everyone can use MS Word today, for example – so unless you’re an administrator with seriously advanced skills, there’s probably no need to mention it).

3. A List of Projects Completed and Your Achievements
This is really important. Clients aren’t as much interested in what you’ve done as what you can do for them.
“Developed a logo for XYZ Company” is fine as far as it goes but… so what? How did that add value to XYZ Company? However, “Developed a logo for XYZ Company as part of a major rebranding exercise that resulted in a 35% increase in sales.” tells a much clearer story.
This is the difference between selling logos for INR 5–INR 50 and selling them from INR 500–INR 50,000. Your work should add value to your clients’ bottom line in some way or another. Don’t be afraid to ask clients what they’re doing with your work and what they expect to achieve with it. And don’t be afraid to go back and ask whether they got those results, too.
Whatever field of freelancing you are in, it’s important to understand the value you create.
This section can change. If you’re targeting a specific job, including projects and achievements relevant to that job. If you’re using the CV for general marketing, pick your biggest wins.
You can, in this section, refer to projects that you completed as an employee (as long as you don’t infringe any contracts with a previous employer regarding confidentiality) until such a time as you have sufficient freelance work under your belt.


Don’t be afraid to use graphics to highlight what you’ve done and what you can do. This can make it much easier for a client to understand your strengths.

4. A Potted Career History
You’ve already told clients what you do and what the benefits are of your work; you don’t need to deliver a ten-page history of every job you’ve done and every achievement you’ve ever scored. You should, however, show any relevant experience gained.
In most cases, a job title, a company name, and dates will be enough to show this. You can always provide a link to your LinkedIn profile if the client needs more information.

5. Your Contact Details
Do yourself a favour—keep these minimal and at the end of the page, not at the top. Clients are buying services, not your home address. It’s vital you offer a client a way to contact you, but it’s not vital that they see this first. If your CV gets shortlisted, they’ll make it through to the contact details; don’t worry about that. In many cases, an e-mail address and a phone number will be enough for this and if you have a website. Consider including the office address if you want to show off a fancy office address. If your business address is also your home address, there is no need to include this.

What about Design?
There’s a certain truism that if you’re looking for employment, you should minimize the design of your CV and just go with a nice font in black ink on a white page. That’s because many organizations scan CVs into HR systems which will ignore that stuff and it may make your CV hard to scan (which may get it binned rather than looked at—at all).
This is not the case for freelance CVs. Your CV is marketing material and it’s not going to end up in an HR database. That means you can include design elements if you feel they’re relevant.
Charts to show off skills, a photograph to connect your audience with your name, interesting layouts, company logos, etc. are all fine in freelance CVs—as long as they don’t distract from the information you’re presenting. Readability is the most important part of any written documentation, but, other than that, there are no limits to your marketing material.
A graphical approach is just fine when it comes to a freelance CV. It’s eye-catching and really shows what Michael Anderson is good at.

Use a Proofreader and Get Feedback

Before you send a freelance CV out to a client, be sure to get it proofread (badly written CVs full of mistakes won’t win your business) and that you seek feedback (from appropriately qualified people – unless your mum works in your industry or has similar experience, she’s not the person for the job) to ensure that you’ve included all the right information.
You don’t have to act on feedback. If you think it’s rubbish, you can ignore it. However, please remember not to be defensive about feedback; if you ask for someone’s opinion, it’s polite to accept that opinion. Thank the person for his/her input, and then decide what you will do with that feedback at a later date.
If you are sending a portfolio with your CV, then always make sure that they tell a consistent story. A typo that says “this project made the client $500,000” in your CV when it says, “this project made the client $50,000” in your portfolio can genuinely damage your chances of success.

Proofreading is not optional. You must make sure that materials you send to your would-be clients represent you and your business in the best way possible.

The Take-Away
Remember you are explaining yourself to the would-be client through your CV. You want to keep things short and sweet while conveying the skills, experience, and value you can add to your client’s projects. It may take time and efforts to write a short CV; be ruthless when editing all your information down.
It is OK to use more than one version of your CV to target different styles of a project (though the information used should always be true and accurate, whatever version you use).
You should always proofread your CV and optimize it to convey the best possible value and to multiply your chances of being selected for project work.
Don’t forget that your CV is not a static document. As American producer Bob Weinstein says, “I’d update my resume so you’re ready for any outcome.” Updating your resume is very important as you progress as a freelancer.

References & Where to Learn More

November 30, 2017

Immersive user experiences with Adobe RoboHelp 2017


Delivering immersive user experiences with Adobe RoboHelp 2017!- Manminder Singh, Adobe


In this workshop, Manminder Singh, Adobe's Product Solution Consultant, will take you on a tour of topic-based authoring with Adobe RoboHelp 2017 release. The workshop will focus on how you can author, enrich, publish and deliver immersive Help content experiences to all the user. Manminder will showcase how to deliver Google-like search experience, bookmark favorite topics, and find relevant content faster using Dynamic Content Filters.

Authors can now increase their productivity by using the modern ribbon-based UI, build frameless HTML5 layouts and deliver next-generation navigation experience to the end users.



Manminder Singh Brief Bio: 


Manminder Singh is the Product Solutions Consultant for Adobe Technical Communication and E-Learning line of products. He has been working with Adobe for more than 4 years and specializes in Adobe RoboHelp, RoboHelp Server, and Adobe Captivate.  Manminder is an expert in providing solutions to the clients and also guides them through the best practices to create and deliver content using the right tools.

                       Manminder Singh

November 29, 2017

Future of technical communication

Future of technical writing- Finding from Adobe TechComm Survey






Future of technical writing was discussed at Information Developers Conclave 2017 organized by Information Developers Foundation by Mr. Amitoj Singh as a keynote speaker.

This world is of ever-changing nature and also the things and technologies. Technological innovations bring a lot of changes and among the professionals who are in the middle of these changes are the technical communicators who document how the product works, how to use them and how to fix them if something goes wrong. They are the one who helps people to maximize the experience they get from a product. So, it is necessary to discuss the future of technical communication.

In the recent conclave organized by Information Developers Foundation, Mr. Amitoj Singh, the product manager working with Adobe gave a deep insight into the future of technical communication.

Adobe does a tech-com-survey every year wherein they take inputs from various partners, customers, and their global team. The findings have been categorized into three sections to define the roadmap of future technical communication. 
These three parts are, 
structured authoring, 
published output 
collaboration & engagement,
 in which the future movement of technical communication would be observed. 

Unstructured authoring comes with few challenges that motivate tech-professionals to move towards structural authoring in future. Structural authoring reduces content errors, time-to-market, content development and translation cost, etc. structural authoring adoption has increased from 20 percent to 46 percent since 2012 and is expected to increase in future to curb the documentation flaws.



The top organization is moving towards structured authoring more as compared to small ones.
Talking about the published output the survey says that pdf file format is still in the first position. HTML5 has recently picked the maximum growth and this trend is expected to grow in future. 

Mobile apps and Web help are also gradually garnering their position in publishing output.


The current trend adoption of the content management system is also increasing mostly as a shared responsibility and version control. Need for collaboration and managing content in pushing CMS adoption. Content consumption is also evolving rapidly. 

Mr. Amitoj concluded his presentation and showed the future roadmap of technical communication. For detailed information go through the presentation,  Subscribe to get upcoming updates.

November 17, 2017

Art of Effective Listening


Effective Listening


We face numerous challenges in our day to day life on the work, family and social arena, and if we summarize the cause behind it, the conclusion will be the lack of proper communication. In a communication somebody says and the other listens to it, but what goes wrong is the discrepancy in presentation and perceivance between the communicators.  Listening effectively can reduce the ninety percent problems on every front we are dealing with. It can save money, time, conflict, and marriages. The problem arises when we are not able to understand what one is saying in its undiluted form, because of our preoccupied brain, lack of attention, a parallel thought running in mind, being judgemental etc. To develop the skill of listening we need to take care of few things, and once we learn to listen we get through the whole thought one wants to convey.
·         Maintaining eye contact
When we listen to someone its necessary to face the speaker and maintain eye contact. Speaking to someone who is scanning the surrounding, looking at the gadgets, is just like hitting a moving target. He is not getting even the tenth part of what is conveyed to him.  As a listener, you must be present there and an eye contact helps in better communication even if the speaker is not looking at you because it may be influenced by his background, circumstances, and hesitance to face an audience etc. It doesn’t mean that it is always necessary to be physically present to listen effectively.  A good communication encourages and increases cohesion between the communicators otherwise one would leave it when the length of communication increases.
                                                                                                                       
·         Be attentive
We should be present mentally while listening, discarding out the distractions like background activities or noise. It is also important not to focus on the speaker’s accent or mannerism because it can distract us from our focus. Side-lining your own thoughts, beliefs, and prejudice while listening will make you a good listener. Be relaxed and focus on what is being said without adulterating it with your own thoughts.

·         Keep an open mind
Don’t criticize mentally or judge the speaker for what he is saying. If you are alarmed, feel alarmed but don’t say in mind that it was an absurd thing, because as soon as you start judging, your effectiveness of listening is compromised. Don’t try to jump to conclusions because the speaker is speaking to represent his thoughts and feelings inside his brain which you are unaware of. The only way to understand his thought and feeling is to listen. Don’t try to interrupt and catch the sentence to complete it because you are following your own set of thoughts and the speaker's thoughts are headed somewhere else. This will put you way off base and you will be unable to have a good understanding.

·         Wait before asking
It’s not good to interrupt abruptly, wait for the speaker to pause and then ask for any clarification.  Don’t impose your ideas or solutions. When someone is talking about his problem don’t start giving solutions right away. Most people don’t need your advice. They figure out their own solutions, listen to them and help to execute the solution. If you really have any chartbuster idea seek the speaker’s permission before delivering it. Interrupting conveys negative messages such as ‘I am more intelligent’, ‘I don’t care what you think’, ‘this isn’t a conversation, it is a contest and I am going to win’.

·         Ask relevant questions
In a conversation don’t deviate from the topic asking irrelevant questions. This can deviate the direction of what was being talked about.  Sometimes we get back to the topic but in most of the cases, this doesn’t happen.  For example, someone is talking about the recent adventure he went through and the name of a mutual friend comes in the context and you deviate from the topic asking about him and his whereabouts, further leading to a different topic and the original conversation is left behind. In case this happens it is your responsibility to remind him to get back to the topic he was talking about.

·         Be empathetic
Try to feel the feeling of a speaker.  To experience empathy put yourself in other man’s shoes and feel what it would feel if you were at his place at that moment. If you feel sad when the speaker expresses sadness, joyful when he expresses joy and fearful when he expresses fear, you are indeed an effective listener. It is a generous and helpful thing to do as it facilitates communication and increases the bond. It is not an easy thing to do as it consumes energy and concentration.

·         Give regular feedback
While in a conversation give regular feedback to the speaker to make the communication engaging. It may be through facial expressions or relevant sentences that reflect speaker’s feeling. This feedback gives a proof to the speaker that you are listening to what he is saying.  While on a phone try to restate the message if you have to convey someone, to ensure you heard it correctly.

·         Understand between the lines
Majority of our conversation is non-verbal while talking face to face. We understand most of the things through the facial expression, body language, the way we talk etc. even talking on the phone we understand what is not said through the tone and voice modulations of the person on the other side. An energetic and happy tone conveys us that the person we are talking to is all well. We can understand the humor, sarcasm, pain, happiness just by listening to the voice irrespective of what is being talked about.

·         Summarize
It’s very important to summarize what you listen if the conversation is informative and about some crucial topic. Summarizing would help you recollect all the necessary information what you heard. You can thus use the information for your own purpose as you can have a better understanding of it.



If we practice these things our listening will be effective and will result in building relationship, friendship, avoiding conflicts and a better understanding of everything.Having an art of effective listening helps us to excel on professional front as we are clear about what is expected from us. We can be able to understand the point of view of others. Our personal and social life also becomes smooth as we have clarity of thoughts not only ours but others too.

October 8, 2017

Adobe at IDC Annual Conference-2017


Adobe Workshop at Information Developers Conclave-2017


adobe


Information Developers Foundation is excited to announce first of its kind workshop at the Information Developers Conclave 2017 and also a keynote.



In this workshop conducted by Adobe Solution Consultant Bharat Prakash, the session will touch on ideas that every writer, template developer, and user of FrameMaker should be aware of. Tips for accelerating the creation of content, templates, using paragraph and character designer functions, and the things that "just should work" are addressed and explored. This session will also showcase how FrameMaker 2017 can be used to create DITA or any XML content swiftly and do multichannel publishing.

Video of Presentation is available now.



Bharat Prakash Brief  Bio: 


Bharat Praksh
Bharat Prakash is the Solutions Consultant for the Technical Communication unit at Adobe and has more than a decade’s experience in software development, testing and consulting. Bharat is an expert in Structured Authoring and various industry standards like DITA and MathML.


Do you want to know about: 


The future of Technical Communications – Findings from Adobe Tech Comm. Survey-Amitoj Singh, Product Manager – Adobe 

Wait for our next blog.

Attendees of the workshop will get participation certification from adobe.

September 22, 2017

Brief review of internal developer documentation style guide

                                  

Developer documentation Style Guide

In this blog post is for technical writers involved in writing internal developer documentations. In this, you will learn brief comparison of different style guides (Google, Atlassian, and SalesForce).

Style guide for technical writing It’s the first thing a newcomer needs to study to understand and track the changes in a project. A bad documentation is worse than no documentation at all. 

Many companies have their own internal developer documentation style guide to write documentation error-free and absolutely clear to prevent any kind of ambiguity but, when they come across external contributors it becomes tough to understand and change the style guide into its own format.

Google is releasing its internal developer documentation style guide. This can quite literally guide your documentation, giving you a great starting point and keeping things consistent.

If you want to follow Google's style guide for your project, you can simply access it here.

In order to better support external contributors to open source projects such as Kubernets, Amp, or Dart, recently Google has released its own internal documentation style guide.

The documentation style guide of Google can be useful for general issues like reminders to use second person, present tense, active voice, and the serial comma. They have also listed a few things to avoid while documentation.

  •        Being too cutesy
  • .      Placeholder phrases like ‘please note’
  • .      Choppy or long-winded sentences
  • .      Starting all sentences with the same phrase
  • .      Current pop-culture references
  • .      Jokes at the expense of customers, competitors or anyone else.
  • .  

Few more such as Atlassian, WordPress, and Salesforce also released their internal style guide to optimize consistency across developer documentation. 

A glimpse of highlights of these style guides is given here to make documentation an easy and accessible task for the newcomers and external contributors. 

Style guide for Atlassian developer documentation

·        Ensure a DOCS: maximum image width of 700 pixels.
·        Use the DOCS: theme colors for sophisticated effects.
·        Include the DOCS: product version to which your update is relevant. Use 'Available', 'Changed' and 'Deprecated'.
·        Use plenty of DOCS: code samples.
·        Make use of our DOCS: templates.
·        Mark all drafts clearly as DOCS: work in progress.
·        Do not DOCS: delete, move or rename any page that you did not create yourself.
·        Use DOCS: internal link format rather than the full [http://xxxx] external link format.
·        Be aware that the content of some pages is DOCS: reused in other pages. Make sure you put your content in the right place. This applies in particular to the Atlassian Plugin Framework documentation.

·        Maintain a DOCS: consistent style, layout, grammar and format with the rest of the page or space.
·        Use Australian DOCS: spelling. For example, use 'organisation' not organization. Use 'customising' not customizing.
·        Use title case for DOCS: headings, not sentence case. For example, 'This is a Heading'.
For complete guide visit https://developer.atlassian.com/about/style-guide-for-the-atlassian-developer-documentation

Few points from WordPress documentation style guide:

1.      Include screenshots
2.      Theme name and menu items are italicized
3.      Use title case for section titles
4.      Spell out numbers nine and under
5.      Use US spelling and punctuation conventions
6.      Refer to the dashboard, not the admin area
7.      Don’t number your section  heading
8.      For complete guide visit https://developer.wordpress.com/themes/documentation-style-guide/

Salesforce’s guide has the following sections:
·        Styles A-Z–Alphabetical reference of basic guidelines for grammar and usage for documentation and user interface text.
·        Glossary–Definitions and usage of Salesforce terms and other key user interface terms.
  • For complete guide visit https://developer.salesforce.com/docs/atlas.en-us.salesforce_pubs_style_guide.meta/salesforce_pubs_style_guide/overview.htm






Featured Post

Adobe at IDC Annual Conference-2017

Adobe Workshop at Information Developers Conclave-2017 Information Developers Foundation is excited to announce first of its kind ...