For writers based outside of the UK, we’re also considering offering this course in a “live and online” format over the Web. Using Google+ Hangouts, the course would be spread over a number of days, rather than delivered as a full day’s worth of training. The price of the course would be the same. The first course would be limited to just 5 or 6 delegates. Do let us know if you’d be interested in attending this course.
About the course
In this course, you’ll find out how Technical Authors in leading companies are now applying techniques from other disciplines (such as psychology, copywriting, usability and elearning) into the information they create.
Using examples of Help pages from a number of applications (including from vendors such as Apple, Facebook, Google, HTC and Mozilla), you’ll learn how to spot where these techniques have been used, and you’ll have the opportunity to practise these in the workshop.
Atlassian’s Sarah Maddox has posted her slides from her STC Summit 13 presentation “Doc sprints: The ultimate in collaborative document development”. It’s a useful description of a documentation sprint and its benefits:
Research conducted by two Oxford academics (Why Your IT Project May Be RiskierThan You Think) has suggested that the private sector has almost as much difficulty managing big software projects as the public sector. It also indicated that some types of projects have put companies’ survival at risk.
Whereas government departments can experience almost permanent revolution, private sector processes, in general, remain fairly stable. So it’s depressing to learn one in six of the projects they studied was a “black swan” – with a cost overruns of 200%.
The causes include: technology that doesn’t work, the difficulty in accommodating the exception cases, managing large teams, changes to the scope of the project, dealing with legacy systems, changes in legislation, and failing to build a system that meets the users’ requirements.
The researchers recommend breaking projects into smaller, more manageable units and using the best possible forecasting techniques.
There’s an additional problem: systems that work technically can still fail. If the user does not understand how to use the system, or if they don’t understand the benefits of using it, your “successful” system can end up under-used. User Assistance (online Help, Getting Started guides, screencasts and so on) mustn’t be forgotten. It’s one of those final steps in a truly successful project.
You’re welcome to join us on our upcoming free webinar, “The changing nature of content”, which will be held at 7pm (GMT+1) on 24th April 2013.
In recent years, technical communicators have focused on improving User Assistance through new technologies and systems, with the assumption that the nature of the content the tone of voice, the writing style should remain the same. In this free webinar, sponsored and hosted by Adobe, we’ll investigate whether the tried and tested writing methods from past decades still make sense today. We’ll look at the reasons why some organisations are “breaking the rules” with the User Assistance they provide.
We’ve been working on a white paper that looks at how User Assistance can be more effective and developed more effectively when you’re working in an Agile environment. The white paper should be published in the next few weeks, but here’s a sneak peek at one of the issues we discuss: the lack of time available for creating User Assistance.
Agile’s iterative release of products, and sometimes frequent changes to the functionality and the User Interface, can make it difficult to create the user documentation. The Technical Author can end up having to rework content they’ve written, delete sections on functionality that’s no longer part of the product, and add information on features that have been introduced towards the end of the project. If the Technical Author waits until the product has been completed, they can find they have very little time available for writing the user documentation.
Danielle M. Villegas has just pointed us towards a five minute lightning talk by Rick Lippencott on the future of technical communication, and its value. Rick covers in five minutes a great deal of the content I covered in my 45 minute presentation at the same conference – it’s worth watching.
He summarises the value of Technical Authors in three simple words :”We explain things”.
Rick added some notes to the description on YouTube:
The clay tablet “first example of tech documentation” is about ten thousand years old, not two thousand.
The odd photo at about the 4:50 mark (where I say any of us could have explained it better) was a hotel room layout map posted at the elevators. It gave room locations based on compass points, but there was no way for the reader to know which way was actually north. It was completely useless.
“All of this has happened before, and it will happen again” was originally from Peter Pan.
The reason why Science and the dark art of persuasion interested me, was because we’re noticing the techniques of persuasion appearing in some Web-based Help. Indeed, we cover some of these techniques in our advanced technical writing course. So, although the debate was on what scientists should know about persuasion, and whether they should ever use these techniques, it seemed likely that the information would also be relevant to technical writers.
HCC Embedded is a high tech software corporation that develops specialist software for deeply embedded systems, such as file systems, USB and networking software.
Dave Hughes, CEO of HCC, realised that with over 100 different modules to be documented, often with inter-dependent content and frequent updates, managing the documents in Microsoft Word had become unmanageable and untraceable.
HCC’s documentation assists users developing with the products, and it plays an important role in the marketing of HCC’s products to developers. This means keeping a consistent format and brand across all this material is critical to the organization.