Category Archives: RoboHelp
New RoboHelp Projects and Unwanted files
Awhile ago I knew someone who spent the best part of a day deleting all sort of what in his opinion were unwanted and unnecessary files from his Windows OS when he got a new PC. His logic was that the files would never be used, took up valuable disk space and their existence annoyed him so much that he was prepared to spend a large amount of time obliterating them. That was in the days of Windows 2.1 but could easily be applied to any subsequent Windows OS version.
The same could also be applied to any new RoboHelp project. This is because many moons ago, when RoboHelp was in an early incarnation, the decision was taken to make it an out of the box solution. Plug and play was the watchword and it was required that a help project could be produced with little or no former experience of the product. In those early days, the output types that could be produced was limited but as others became available, the creation of each new project had to cope with them. So each project came complete with a number of style sheets (one for each output type) skins for flash or web based output, and all manna of other stuff designed to make it easy to get a project up and running in no time at all.
A minor problem with this is that you inevitably end up with lots of unused files in your project. They don’t do ay harm but if you are a tidy person, you’ll want to remove them. The files are easily identified by using the Unused Files report and you can delete the files from Windows Explorer. However one folder is excluded from the report. Part of each newly created default project is a folder called !SSL!. This little beauty exists to provide a default location for all output generated from your RoboHelp project.
In the days when the choice of output was limited to WinHelp and CHMs, the !SSL! folder didn’t exist. It didn’t really need to. WinHelp produced two output files and CHMs produced one, therefore the default output location could be left in the project folder. The apple cart was upset when other output types came into being, many of which generated multiple files. It was no longer practical to place them in the root of the project. Suddenly RoboHelp HTML needed a separate repository for each output type. The !SSL! folder (which stands for Single Source Layout) is automatically created with each new project. What is more, each output type you create by default adds a sub-folder to it to contain the output. For example, compile a CHM and it is created in the !SSL!\Microsoft_HTML_Help folder. Generate Webhelp and it goes in the !SSL!\WebHelp folder.
If all these folder layers annoy you like they do me, just get rid of them. CHMs can easily be created in the project’s root folder. WebHelp or FlashHelp output can be generated to another folder outside the project. Of course if you have merged help projects you’ll probably want to output to a separate folder anyway. Remember to change the output folder and path for any single source layouts you use or else the !SSL! folder will reappear when you create your output.
Better still, create a dummy project which has exactly the files you require to get going. When you need to create a new project, copy it to a new location, open it in RoboHelp, rename it and you have a new project with no unwanted files. This has the advantage of having master pages, variables, snippets, skins, style sheets, etc. that you use across all your projects.
Q: When is a drop down not a drop down?
One of the more frustrating modes of working inside RoboHelp is within a DHML window. These little beasties open up with some default text that is never ever what you require. Additionally they open up with a default width and height that is about as much use as Julie Andrews was at all in wrestling.
To get around these issues, you inevitably have to click and drag the window to increase its size and remove the “Type your drop-down text here” text from the window. All slightly annoying, especially where the dropdown has an image or table that can take up a fair amount of space.
But hold on there. All is not lost. A little, but simple tip I learnt from Rick Stone many moons ago was not to use the DHTML window to edit at all. Add your content to the main topic body. When it is exactly the way you want, select it and copy it to the PC clipboard. You can even cut it if you are felling daring. Now add your dropdown, select the default text in the DHMTL window and paste in the clipboard contents. Viola!
Despite asking Adobe on at least two occasions for enhancements to enable me to define a default DHTML window size and text string, these have not yet arrived. OK I realise these are not show stoppers and that they have functionality that is a lot more sexy, but I live on in hope. This minor annoyance has an easy workaround, but the hope that one day I will have more control over my DHTML windows gets me through day 
P.S. This procedure can also work with DHTML expanding text.
Like a good whiskey, the Technical Communication Suite improves with age
It is fair to say I am not always at the front of the queue when it comes to PC or software upgrades. Even if I want to upgrade, there are often factors that prevent me from rushing to my supplier. Primary amongst these factors is the need to ensure that what I am about to buy meets all my needs. Whilst I am often excited by the arrival of a new toy, the cautious side of me needs to understand how it will affect me. In the corporate world, this is especially true as your reputation, and your job, can rely on it.
At work I run RoboHelp X5, RoboHelp Server 6, Captivate 2 and FrameMaker 7 on a Windows XP platform. Hardly cutting edge, but they do the job. Up until recently I also used MS Office 2003 until one of our applications implemented a feature only available to MS Office 2007 users. I had to have MS Office 2007 installed which created a dilemma as RoboHelp X5 only supported up to MS Office 2003. However a side by side install of MS Office 2003 and 2007 did the trick as we don’t use the features of RoboHelp that interface with MS Word.
With this in mind I’ve often wondered why it is that product users seem hell bound on buying a new release as soon as it is released. I’ve never felt compelled to queue overnight on the pavement outside a bookstore so I can be among the first to buy the latest Harry Potter novel. I didn’t even think of putting in a order for the 3G I-Phone before it was formally released. Similarly I’ve never felt the need to get up at 4am to catch a flight to go on vacation when there is another one at 10am. Perhaps it is just me, but I always want to wait and see before jumping.
This is partly because I have worked with software companies all my professional life. I know what is involved in producing a software application. I understand the commercial demands that set a product deadline in stone. Above all I appreciate the pressures that make a Product Manager evaluate whether a software bug is sufficient to prevent a product’s release. It is a fact of life, as sure as eggs are eggs, that software applications contain bugs. It is also certain that applications can be released in order to meet a deadline, yet with full knowledge of their faults. Then a month or so down the line a patch is released to solve the issues.
As if to illustrate this fact, Adobe recently released a patch for FrameMaker 9. As you would expect it fixes a long list of bugs. No doubt plans are also in place to release updates to RoboHelp 8 and Captivate 4 to correct bugs in the released versions that form part of the Technical Communication Suite.
I hope so. Just this week, my company put in an order for five Technical Communication Suite licenses. The cost of £6000 UK -which includes an upgrade to RoboHelp Server 8 – is substantial for a company our size and we need to get it right. We need to ensure that we are using all the features of RoboHelp that we can and let it be known, to those that matter, how our productivity has improved as a result. I have no doubt we can do this, especially with the:
- Ease with which screen captures and Captivate demos can be incorporated in our projects.
- Enhanced search results, including the ability to index PDF and MS Word files.
- Improved interface between FrameMaker and RoboHelp. This will become a big feature for us as we move towards producing out help and training materials (produced in Framemaker) from the same source.
- Ability to output a RoboHelp project to a PDF, send it for commenting and import those comments back into the source in a fashion similar to MS Word’s track changes. This is huge for us as we have to maintain an log of all changes for our ISO 9001 audit status.
- Scripting interface that allows us to produce and run out own scripts to fulfill a specific purpose.
- Ability to easily hide topics from the search without the added hassle of. XHTM files and adding them to baggage. A small change but one that will save us untold hassle.
I could go on, and I haven’t even started on the completely redesigned user interface. OK I know this was available in RoboHelp 7 but for a RoboHelp X5 user this is a big thing. This level of control that allows you to customise your workspace, when put together with the features I’ve highlighted above, makes the Technical Communication Suite 2 a must buy.
Of course I knew this even before it was released, as I was fortunate enough to be part of the beta test team. That said, even after the beta test I never intended to buy the suite straightaway. Just like a good whiskey, the Technical Communication Suite improves with age.
Seeing double
I’ve never really understood the need to have a dual monitor set-up. To me it doesn’t really provide anything that can’t be achieved by a little window management of use of the Alt + Tab key. That said, it is becoming increasingly popular. When it comes to working in RoboHelp a dual monitor set-up can cause problems.
A typical scenario goes something like, “When I take work home, I stop using the second monitor and use an old laptop. I am in the habit of spreading my RoboHelp windows over both screens. When I get home I am unable to view most of the things I wanted to use (e.g. my Table of Contents and the Single Source Layouts). I made a special trip back to the office over the weekend to gather my RH windows onto the small screen of my laptop just so I could continue working from home.”
A couple of workarounds are available to this problem. The first is covered in the blog post by Rhonda Bracey of CyberText Consulting. The second is dependant on the video card installed on your PC/laptop. PCs with a NVIDIA control panel have a Display > Set up multiple displays > Only use one display (Single) setting. With this selected, all your windows are collected to the laptop display. However if you don’t change it prior to disconnecting the second monitor, it doesn’t “collect”. PCs with a different video card may well have a similar setting.
Flare to RoboHelp Converter
Much has been written about the history of RoboHelp. Part of that must be the start up of Madcap Software and the addition of Flare to the help authoring tool pool. Following the release of Flare, there were some RoboHelp users who jumped ship. Whilst I held faith in RoboHelp, I can understand why some users wanted not to even if I didn’t agree with their reasoning.
One of the big selling points of early Flare releases was its ability to import RoboHelp projects and (according to the marketing hype) virtually seamlessly convert them to the XML required by Flare. This was backed up by an aggressive marketing campaign with reduced license rates for existing RoboHelp users. That’s all water under the bridge for most of us. We have made our bed and laid in it wherever that may have been.
For users that did migrate to Flare, the experience may not have been as fruitful as they had hoped. The early releases were limited in functionality and had bugs that rendered it unusable to some. Whilst Madcap played catch up to Macromedia and Adobe in the functionality provided by their product suite, there are undoubtedly users wishing to revert back to RoboHelp. The problem was that until fairly recently there was no easy means to convert a project from Flare to RoboHelp.
That all changed with the open source converter developed by Adobe Community Expert and certified RoboHelp / Captivate instructor, John Daigle. It converts most of your Flare content (e.g. topics, CSS, dropdowns, glossary, TOC, Index, snippets, etc.) with minimal intervention. It can be downloaded from his website, and because it is open source, can be amended to suit your specific requirements. All John asks is you drop him a line.
