How to Make a Help File with Free Software August 25, 2008
Posted by Amal in Editing, Manuals, Tools and Softwares.Tags: Free Software, Help Authoring Tool, Help File, HelpMaker, HTML-Help, WinHelp
2 comments
While reviewing some software for the Information Developers, I was amazed to see Open Source initialized it’s presence in field of Technical Communication too. Some free software is also available to help you in technical documentation jobs.
Often there is a need for a Help file for some software you review. Let’s see if we can do this for free 
So on my search for a Help authoring file, what I found satisfied me completely because along with Help authoring I got a software combined with ImageMaker, ButtonMaker, IconMaker, Batch Image Conveter, PDF Merge, PDF Manual Designer and SHG editor, WOW!
Helpmaker from Vizacc (http://www.vizacc.com/) is a RTF-based, page-layout Help Authoring tool. It generates WinHelp, HTML_Help, Website-Help and PDF. It comes with a great price tag a Freeware for commercial and non-commercial usage with free support at no additional charge.
The User Interface of this software is easy to understand. The whole screen is divided into left document map area and right editing area. The editing area is divided into top-right Header editing area and bottom-right Main editing area.
Initial Screen allows opening an existing or creating a new document. Let us see how we can make a simple help file.
After Install, you will get the initial screen which will be like this:
- You can create a start a fresh HelpMaker project by clicking on the New… button
- Select Create a New HelpMaker Project from the popup screen that opens up
- Click on Next. This will open a popup where you should enter the details of your new project.
For this example I have created a Test Project
- Click Next for starting with the project. You will get the document editor for editing your document. I will prefer to have my notes / drafts ready for the Help file
You can edit / stylize / format your document, headlines and matter of the Help File.
Once done you are ready to compile the Help file.
- You can export the document to RTF, HTML or PDF format from the File Menu
- Select your project from the Document Map panel
- You can choose the Compilation format as you require (WinHelp, HTML Help, HTML-Website Help or Word / RTF based help file
- Compile the help file by selecting the Compile button or by pressing F9
Once compiled you get your Help file.
You can copy and paste this help file to integrate with the software developed by checking the Help Directory of HelpMaker.
In the age of Adobe Robohelp, HelpMaker is software which enables small and middle sized companies to provide value added service to developed software and websites.
Happy Helping Folks!
What Difference does English Make ? August 22, 2008
Posted by Amal in Did You Know, English Usage, english.Tags: american english, british english, English Usage
add a comment
So how does it matter, British English or American English…Is it really that important ?
It is for sure !
Did you know that a Britisher’s Billion is actually an American’s Trillion ??
Check out for yourself:
http://www.askoxford.com/asktheexperts/faq/aboutwords/billion
Well…Now you know !!
Transforming Ideas into Recurring Thought Process August 14, 2008
Posted by Amal in Editing, Technical Communication, Technical Writing Basics.Tags: Communication ideas, Technical Communication, Visualization
add a comment
Have you ever been shabby? Did you like to draw on your maths book? Did you ever try mnemonics? If yes, then you’d love transforming ideas through ideas of communicating…differently 
I asked whether you are shabby because that will be needed (pretty obvious not on the research documentation or
manuals you create). Try post-it notes, great invention to be shabby, note down, Capture ideas, and small diagrams understandable by you. Post it around you, on your laptop, over your desk, CPU, coffee mug, telephone. Let your whole office cubicle stand out with post it’s.
Did you love to draw? Did you create your maths book into a drawing canvas…..Wonderful!
Start an exercise, study about VOIP and ask a non technical friend by explaining him once, if he got it right.
No worries. Next day draw the whole thing as you visualized on a chart paper. Get it pasted in your cubicle.
Now call another non-technical person and ask him without any explanation – Can he understand what you meant?
That’s successful communication, technically.
Mnemonics is for you. I hated studies. Man! I hate to study the whole book on JBOSS too (because I know tomorrow I have to give my ideas on some new technology if the requirement is so, but mostly because I hate studies). To help me there is Mnemonics… I prefer to visualize over studying. Till the project is on, I use Mnemonics to memorize important points of the book. I also prepare short one liner in my diary.
Innovate, Think, Visualize and help yourself through ways that can transform knowledge faster. They said well – Ideas! Sure can make you the King of Creation. Till the next post, keep thinking.
“Effective” – The Must Behind Software Documentation August 6, 2008
Posted by Amal in Editing, Software Documentation, Technical Writing Basics.Tags: Design Documents, Software Documentation, Style, technical writing
1 comment so far
In most mediocre IT firms the key responsibility of software documentation remains in hand of developers. Technical Design Documents, User manuals, Help References are all involved as a part of the software development phase. In bigger houses however, the idea is changing. Technical Documentation and information development is a process throughout. So where do we start when we have the responsibility? Let us check out -
The main reasons for user documentation are as follows
* Helping users with the developed software
* Reducing support costs
* Powerful business and marketing tool
* Improving a software firms reputation and brand identity
* Helping with QA, Process and Management with technical stuffs explained.
Before documentation we should identify the reason behind that particular process. For example a document with marketing aspect would be different than that targeting the QA team who should test the software.
Analyze your audience
“It’s very good looking”, “It’s very attractive” are not what a Technical Communicator needs to listen. The only phrase that should matter for each document is “It’s helpful”. Yes, you should style it, publish it with enough details and attention, but never forget the target audience.
The easiest way is to analyze users by designation or job responsibilities. Whether the documentation is for:
1. Users of software
2. Quality Testing guys
3. Administrative professionals
4. System Professionals
You would know by the roles who is a novice and who is a techie. Who needs validations, database structures and who needs less than that.
By analyzing audiences you will provide:
1. Information as needed
2. Easy, helpful and Handy document
Analyze Tasks
How often should you write? Whenever. Make it your hobby.
How often then should you communicate? As much as you breathe, make it your need.
You should analyze tasks, tasks performed by members of QA team, System team, Project Managers, coordinators, and Data Entry Operators. By communicating you will know where they lack, what they expect, how can they be helped with information. Communication makes your job easier; in process you make their job easier. That is what the main responsibility of a Technical Communicator is.
Structure, Styles and Information
How a Technical Communicator use styles, structures and document the information depends on what each document should address to. All documents should answer particular questions. Here is an explanation, On a very macro level:
| Document drafted for | Should answer to the Question |
| Client (Business Documents) | Why should your service be better, how good is your understanding about the requirement, how capable are you to provide solutions for the requirement. |
| QA, Analysts (Design Documents) | Validations, How Should the interface works. What should be the ideal conditions for software to work? |
| Developers (Logical / Technical Documents) | What should we keep in mind while developing? What was planned? How was it planned? Why was it planned? |
| Users (End user documents and help manuals) | How does the system work? How should a particular thing happen through software? |
| Novice Users (documents for primary end users and internal novice users who use the software for example, data entry operators) | How should the software help? How is it easier to use? How should a particular task be achieved in the simplest manner? |
Software Documentation is as fun as you can make it, but never make your documentation funny. Make them effective.
