Using MadCap Flare 2017 for company procedures – Quick review

We’ve been setting our staff the challenge of using some of the popular Help Authoring tools to create online company documents.

We asked them to make some notes on the applications they used. Here are some of the notes relating to MadCap Flare 2017:

“You soon become aware it’s a really powerful tool. Is this actually a CMS?

It’s a breeze to import content. The authoring environment is nice and easy to use. It’s easy to jump into the HTML if you want to. Easy to make global changes. 🙂 You can carry on working in Flare while it’s building the output files.

It complex, though. To make a change to the look and feel, I’d ask myself do I change the skin, the master page, or the stylesheet? When you know where the setting is, you can make lots of tweaks and changes.

The web pages it creates seem to load really quickly. The only downside of publishing is it creates a lot of subfolders. I had to manually create the folders on the website. That took a while to do.”

Using RoboHelp 2017 for company procedures – Quick review

We’ve been setting our staff the challenge of using some of the popular Help Authoring tools to create online company documents.

We asked them to make some notes on the applications they used. Here are some of the notes relating to RoboHelp 2017:

“Straightforward to use. Easy to import the content.

The responsive web templates supplied with it are nice looking and easy to customise. The layout editor has images that help you identify easily which stylesheet elements to change.

The search and replace didn’t change everything I wanted. I don’t know if I was using it incorrectly.

When you press the build/generate button, you have to wait until that process has finished before you can do anything else.

The output it creates produces folders that are all in lowercase, apart from one. If you need to manually create the folders on your website, this can catch you out. It did me.

The ability for users to filter content is really useful. You can filter content so it only relates to a country, a job role, pre and post brexit, etc. Obviously, you need to markup the document, and know where these conditions should apply.”

Review: Modern Technical Writing by Andrew Etter

Andrew Etter has written a short, Kindle ebook called “Modern Technical Writing: An Introduction to Software Documentation“. The book is Andrew’s personal view of technical communication, based on his experience of being a technical communicator in Silicon Valley.

It neatly describes the “Docs-like-code” approach to technical writing, and it challenges the impulse to write about everything. It describes Andrew’s experience of creating documentation in lightweight markup languages, such as ReStructured Text and Markdown, and using GitHub and static site generators to manage and publish the content.

Overall, I enjoyed reading the book. Andrew describes the benefits from following his approach. Ideally, I’d like to have seen more information and evidence to justify his opinions against other authoring tools. Microsoft Word might be a better choice than Markdown if you need to include complex images, tables or numbered lists. A Content Management System might be a better choice than a static website generator, if you want to provide intelligent content that modifies content to suit different users. The need to manage localised content (in multiple languages) might be easier to accomplish in DITA or MadCap Flare than by using GitHub and Markdown files.

Having said that, the book provides a useful insight into a increasingly common approach to documenting software applications.

RoboHelp 11 review (finally)

robohelp logoAdobe released its latest version of RoboHelp Version 11 (and Technical Communications Suite 5), a while back and asked if we could write a review. There have been a number of excellent reviews, so we’ve been wondering what extra we can say. We’ve decided to address some of the questions we’re often asked by organisations when they’re deciding which Help Authoring Tool to choose.

Continue reading “RoboHelp 11 review (finally)”

Delegate review of Cherryleaf’s DITA elearning course

Craig Wright emailed us to let us know he has posted a review of our DITA elearning course (see Review – Cherryleaf DITA e-Learning Course).

His conclusion was:

The Cherryleaf DITA course ticked a lot of the boxes for me:good content, good value, and available without having to travel to the South East. The introduction to the key DITA areas was presented very well – I have read similar information in books and online, but I was able to absorb it much better through the e-learning course.

Thank you Craig!

How do you measure the effectiveness of operations manuals and other procedures documents?

When reviewing an organisation’s procedures documents, there are a number of key factors we look at. These relate to the value of the document itself, how it is structured and the clarity of the content (i.e. the words and sentences).

One way to rate these factors is by a simple red, amber, green traffic light system. Using this approach means the key areas of concern can be highlighted to everyone involved in the project. Red indicates an area of high concern, amber indicates medium concern and green indicates no change is needed. Here is an example below:

How do you assess organisational operations and procedures documents?

Book review: Confluence, Tech Comm, Chocolate

I was sent a review copy of Confluence, Tech Comm, Chocolate: A wiki as platform extraordinaire for technical communication, by  Sarah Maddox. It’s about using wiki technology for developing and publishing technical documentation, using the Confluence platform, the emerging trends in the creation of User Assistance and, in places, chocolate.

Confluence, Tech Comm, Chocolate

The book is aimed at three audiences:

  1. The person who isn’t sure what collaboration tools and wikis are, and is not yet fully convinced these are platforms they should use for producing and publishing technical documentation
  2. Someone who has used Confluence or another similar application, but sees themselves as a beginner
  3. Advanced users of Confluence.

The author manages to pull it off  – all three groups will find the book interesting and useful.

For the skeptics, Sarah raises and answers a great question:

Isn’t a wiki just a puddle of chaos?

The problem with the word “wiki” is everyone thinks of Wikipedia, with its complicated authoring environment and occasional errors. Sarah explains not all wikis are like Wikipedia, and how Atlassian, the makers of Confluence, struggles to describe the software (it currently says it “provides collaboration and wiki tools”). In fact, Confluence is a tool that can publish EPUB ebooks, PDFs, Word documents, HTML, DocBook files and, probably quite soon, DITA files. It has a rich text editor that looks like Word. It’s a wiki that doesn’t look like a wiki.

The book itself was written in Confluence. Comprising 477 pages, there’s a lot of “meat” in this book. We’d consider ourselves as knowing a lot about Confluence, having used it to build solutions for a number of clients, but there were many useful nuggets of new information.

Enthusiasm oozes through almost every page. That’s partly because Confluence is one of those tools that causes clients to get excited. They very quickly realise the potential outside of the original project. It’s also partly because the author is passionate about the subject.

Examples are built around a hero (heroine, actually) called Ganache, and this approach works well.

The book also looks at new trends in User Assistance – where technical documentation is going and how it will be created. A Cherryleaf article is mentioned in passing. It looks at working in an Agile software development environment, and how a collaborative authoring environment can help reduce the authoring bottleneck Agile can produce.

Sarah also highlights the weaknesses of authoring in this environment. There are issues around round tripping (and whether it’s needed or not), in particular.

Technical Writers will also have questions about translation and localisation of content, which is touched on only briefly. Publishing to .CHM files isn’t covered. However, there is a wiki that complements the book, so readers have the opportunity to raise these questions with the author (and discuss them with other readers) there.

If you’re interested in collaborative authoring, wikis, Confluence, chocolate, working in an Agile environment or where technical documentation is going, then it’s worth getting this book.