Cool tools for Technical Authors – note taking

I thought I’d share some of the tools we use at Cherryleaf, starting with note taking. I’ve not covered audio recording tools, as we’ll probably look at those in another post.

Moleskine

Moleskine notebooksMoleskine notebooks are a great way of taking written notes. The 13cm x 21cm size provides a decent page size, whilst being small enough to fit into an external jacket pocket. The large rule notebook contains 240 pages, which means you’re likely to need only two or three per year.

The elastic closure stops the notebook from falling open, and the bookmark helps you find the next empty page. These can be handy also if you sometimes wake up with an idea in the middle of the night. They enable you to open and find a blank page in the dark, without having to turn on the light. Once the thought is recorded, your brain can settle down to returning to sleep.

Uniball eye pens

Uniball pensThe Uniball eye is a popular, everyday pen you can pick up from pretty much anywhere that sells pens. They are reasonably priced, so it doesn’t matter if you lose one, and they seem to last for ages. You can write with minimal pressure, as the ink flows smoothly. The pens are also comfortable in the hand.

CamScanner Pro

One tool we all use is a mobile phone app called CamScanner Pro. CamScanner enables you to scan a document using your smartphone’s or tablet’s camera. It means everyone has their own personal scanner wherever they go. The app converts the image into a PDF, and then enables you to upload the document to a cloud storage service (such as Dropbox) or email it to someone. The Pro, paid, version can also convert scanned images to editable documents.

Which tools do you use to take notes?

Let us know, using the comments box below.

Cherryleaf “green screen” videos

We’ve been putting together some short length videos that we can use on the Cherryleaf website. These are “quick and dirty”, three to four minute videos, shot behind in front of a green screen.

One explains why technical communication is changing:

Another looks at recruiting a Technical Author:

Each video takes a couple of hours to create, and we hope to add more over time.

Location of Technical Authors – new data added to the map

location of technical authors August 2014

The Institute of Technical Communicators has kindly provided us with additional data for our Location of Technical Authors map. They’ve supplied us with an anonymised list of the location of ISTC members. These are indicated by the peach coloured pins on the map.

It confirms the locations where there are shortages of Technical Authors, with the exception of two areas: Birmingham and Glasgow. It also suggests new clusters: one around Colchester and Ipswich, and another around Cardiff.

 

Writing troubleshooting topics

It’s a fair bet that the introduction of the new Troubleshooting information type into the DITA 1.3 technical authoring standard will affect how all Technical Authors write troubleshooting topics, regardless of whether they use DITA or not. That’s because the proposed elements for troubleshooting topics make good sense, and it offers a standardised approach to writing these types of topics.

According to the Oasis DITA standards committee,

Troubleshooting topics provide descriptions of and solutions or workarounds for problem situations that users might encounter. Users refer to troubleshooting information to understand what condition or event generated their problem situation and to find out what they need to do to recover from or work around a problem, or to prevent a recurrence of the problem.

The user would see a topic that looks roughly like this:
Continue reading

Creating a map showing the location of Technical Authors

Sarah Maddox’s post on how she has added “techcomm titbits” onto an interactive map, prompted me to look at whether we could create a map showing the location of Technical Authors around the UK. It’s something we’ve wanted to do for years, and Sarah’s post suggested it was much easier to do these days, thanks to Google’s applications.

The map needs data, so if you are a Technical Author, please add your details to the map:

We will not include your name or email address on the map. However we do need your name and email address in order to check the integrity of the data and to update you of any developments. You can use the postcode of a neighbouring street, if you wish.

We currently have an intermittent problem with our website. If you see an Error Establishing Database connection message, please refresh the page and it should appear.

The big questions in technical communication

David Farbey wrote a semi-existentialist post on the challenges for technical communicators yesterday. I’d like to look at the issue in a different way, by looking at the big questions in technical communication today. The answers to these questions (which may be decided by people outside of the profession) are likely to affect the future direction for technical communicators.

Continue reading

Changing times in technical communication 3 – The long form Help topic

New York Time snow fall article imageOne of the most recent developments in web page design has been the introduction of “long form” web pages. Will we also see the long form approach used in Help, or perhaps start to influence the way some Help pages are designed?

Continue reading

Writers shouldn’t code… or should they?

Editor’s Note: This post has been written by Dr. Tony Self of HyperWrite. Tony will delivering DITA training during October at Cherryleaf’s training centre in London. 

Code ninja tshirt flickr creative commons image by juhansoninIn the field of technical communication, an argument crops up from time to time saying that technical communicators shouldn’t have to know anything about XML, because writing is writing, and XML is coding, and never the twain should meet. Dissecting the argument, it appears that the underlying claim is “language first; technology and tools later”.

In many cases, it seems the logic gets a little lost. I have heard statements along the line of “if you can’t string a sentence together, knowing about XML elements and attributes won’t make you a technical writer”, as if those skills are mutually exclusive.

My first observation is that the debate is often poorly framed. XML is not precise enough a term; what does “knowing about XML” mean? XML is an enormous field, covering programming, writing, archeology, journalism, eLearning, spacecraft design, mathematics, chemistry, audio recording, banking, gambling, engine management, and pretty much every field of human endeavour. So in a discussion about the role of XML in technical communication, we need to define what we mean by XML. Bearing in mind that XML is principally a standard for creating XML languages, the XML languages (or applications, in XML terminology) of interest to technical communicators are probably DITA, DocBook, XHTML, SVG, MathML, and XLIFF.

Continue reading