Adobe released the latest version of RoboHelp last week, and we’ve taken it for a quick spin around the block. It’s called RoboHelp (2015 Release), but we’ll call simply call it RoboHelp 2015.
Adobe 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.
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!
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?
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.
The book is aimed at three audiences:
- 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
- Someone who has used Confluence or another similar application, but sees themselves as a beginner
- 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.
I was sent a review copy of Alan J. Porter’s latest book, The Content Pool: Leveraging your company’s largest hidden asset. It’s a well written book that’s ideal for anyone who is uncomfortable about the way their organisation creates and manages its written content, as well as anyone who simply wants to manage their content in better ways.
The book identifies and takes you through the key aspects of taking control of your content. I liked the book for what it left out, as much as what it covered. Content strategy and content management are huge topics, and it’s easy to feel overwhelmed by it all.
He could have covered topics such as the difference between short term and long term information, the provenance of information, and the attention economy (illustrated in the video below). However, he was right to leave those topics out and keep the focus on the main issues.
Alan raises key questions (such as why are you producing this content?), and helps steer you to the answers. The book also contains many anecdotes and case studies that keep you engaged throughout the book. He keeps reminding you to check any content system you implement meets your business goals.
However, being realistic, very few if any, companies are going to leap immediately from undervaluing their content assets to having them overseen and cared for by the highest levels of the organizations.
At the start of the book, he lists many examples of where poor content has had a major impact on an organization. Unfortunately, I don’t think these will persuade a CEO who thinks content is not that important to change their mind. I suspect they are more likely to change their mind if they felt their content was causing them to be left behind by their competitors.
The examples of Disney’s (which is mentioned in the book) and Coca Cola’s approaches to content strategy are likely to be a more convincing argument – big companies using content to gain a strategic advantage. We’ve also found other motivating factors to be directors who feel they don’t fully understand how the organisation is doing (numbers can only tell you so much, and meeting people is time-consuming) and CEOs who feel staff are not ‘getting’ the organisation’s goals and direction.
The final chapter provides great advice on how to sell yourself, and the idea of content strategy, to the organisation.
The worst aspect of the book is its cover drawing – it’s the wrong image for a professional book such as this. So, don’t judge this book by its cover – it’s worth adding to your bookshelf.
Overall, though, this book does what it promises to do. It provides an overview of trends in technical communication and sets out a vision for the future. If you are wondering what skills you are going to need tomorrow and where the future lies for our profession , this book is a good place to start.
Phil gave it 4 stars out of 5.