Shorthand and Markup for Speedy Note-Taking

I review documents a lot, and I attend many meetings too. Creating meeting minutes or review comments ain’t fun; the same holds for processing them. Over the years, I have come up with a shorthand notation to speed up their production and consumption.

My notation has two main usage scenarios. Read on if:

• You want to improve your efficiency as meeting/workshop participant and notes taker (or start taking minutes in the first place).
• You have received document review comments from me and wonder what these cryptic markup [W], [A], [D], [?] (and so on) is supposed to tell you.

Note: Please Take Notes in Meetings!

Correct me if I am wrong, but my impression is that only very few notes (a.k.a. minutes) are taken in many meetings. This always surprises me. Notes can help you ask more meaningful and precise questions instantly. And you remember things better when you write them down — even if you never look at your scribble again, it pays off to create it.¹

I can only think of three reasons for not taking any notes in meetings. You either are:

1. extremely capable of remembering (all the relevant things that have been said),
2. lucky that official notes are taken (and you trust the scribe), or
3. a bit overloaded with information already and not very interested in the meeting topics.

I let you decide which group you are in. If you are in group 1, you do not have to read this post obviously (unless you want to improve your review capacities). If you are a member of group 2, ask yourself whether the official notes will contain the things that are particularly relevant for you, and wether they are detailed enough to serve you well. If you can admit to yourself that you are a member of group 3, how about not attending the meeting? 😉

The shorthand markup notation introduced in this articles eases my notes taking and processing. Hopefully it will serve you well too.

Make and Take Review Comments

As an reader of online material and printed documents, you want to be able to appreciate the content and enjoy the read. Technical writing is hard and benefits from a second opinion and intermediate feedback. As a reviewer, I see myself as a curious test reader, an empathic proxy representing parts or all of the full target audience. In this role, I try to make suggestions how to improve the reading experience; I don’t want to come across as the “editing police” but as an open-minded, yet critical early adopter of the reviewed material.

With this in mind, here are some examples of the comments I often give to students, clients, peers (and myself) when reviewing intermediate and near-final drafts of specifications, patterns, other design artifacts and thesis reports:²

• I need more information to be able to appreciate the content of this part. Can you elaborate please, for instance, by way of example?
• I had difficulties understanding this expression or sentence. It might use terms unfamiliar to parts of the audience. Consider rewording.
• The text does not seem to flow well yet here. How does this paragraph (or sentence, figure, etc.) relate to the previous one(s)?
• Have you looked at concept X, article Y and product Z? How does it compare to your solution?
• Can you please provide evidence for your claim (for instance, with a literature reference)?
• This is a complex subject, I have many thoughts, comments and/or questions about its coverage; should we discuss them in a meeting?
• Please contact NN, there might be an opportunity for collaboration.
• I’ll send you some pointers to related work and introductory material by mail.

Such notes take quite some time to write if you want them to be precise and actionable.³ Obviously, the specific message of each review comment (for instance, a review finding and related recommendation) cannot be be generalized much. But maybe there still are some common themes in the above examples that are worth carving out?

My Meeting Minutes and Review Markup Language

I’ll use a light pattern/recipe style to introduce my meeting and review markup language in three steps: context, problem and solution.

Contexts: A document has been sent out for review, the review goals have been stated. A meeting has been scheduled to reach certain some objectives and an agenda defined.⁴

Problems: As a meeting participant, I want to grasp the essence of the discussion so that I know and remember what to do about the meeting outcome. As a reviewer, I want to give tangible, concrete advice. In both roles, I want to be efficient and effective.⁵

Solution: Establish and apply a list of tags as a markup symbols to classify and categorize comments by type (and type of activity they lead to). Look for these markers when processing meeting minutes and review comments, and handle each type appropriately. Introduce the notation to the feedback recipients at first use and apply it consistently after that.

Let’s start with types of editorial comments:

Next up is markup for feedback (good and bad).

Some comments are more design- and activity-oriented:

The remaining comments helps with prioritization and clarification:

Usage of the Notation

Capture your notes, now annotated with review markup [M]s, as:

• Handwritten notes on printouts
• Sticky notes when reviewing PDF documents (do PDF readers support [M]arkup?)
• Microsoft Word or Latex comments (same for Google Docs and other “free” services)
• Markdown, self-contained text files or Wiki pages
• Any other call-out/comment feature in OneNote, miro, or your text tool of choice

One benefit of electronic capturing is that the comments are searchable, for instance in follow-up meetings in which [FB] or [ADs] are [D]ed.

Usage hints for reviews. The symbols point at a precise location in a reviewed document, such as a word or sentence or paragraph (using an arrow, underline, or yellow background color), and are accompanied by some more context-specific text most of the time (for instance, an example or a [W] suggestion, typically embedded in double quotes:

“[W] how about this rephrased version of your text: … ?”).

I sometimes label the markers during the first round of postprocessing, to make sure I remember what I meant, and to get a feel for effort required to follow up on them:

• Indices can order instances (chrono-)logically or by importance/urgency, for instance with a “suffix” in handwriting: [A₁], [A₂], etc. (when done with the action, I strike through the marker)
• High (H), Medium (M), Low (L) priorities can help organize the follow up (in terms of urgency and importance).
• Color coding may also work, I sometimes add it during the first pass of postprocessing. For instance, yellow can indicate the [A]s that I committed to and green can mark good things that happened. I save red for extremely urgent or important things and use it sparsely.

TLAs in Short

Here are some TLAs⁸ that I often use, which might be less common and obvious than others:

Conclusions

In Domain-Driven Design terms, the shorthand notation introduced in this post is my published language for the notes taking domain (with meetings and reviews being subdomains). It not only suited for meetings and reviews. I also use (some of) these markers and acronyms when capturing brainstorming results, when planning my work day, when attending presentations, when designing software etc.

Take Away Messages. If you made it down here, I hope that you agree on these summary [M]s and additional thoughts (w.r.t. meetings and reviews):

• Do take meeting notes (or have the courage to tell the organizer that you will not attend because something is wrong in the meeting setup).
• Do post-process your notes (or suggest to have less meetings).
• Make your notes easy to post-process by tagging them, for instance with symbols/markup such as [W], [O], [M], [A], [D], [!]. Use the same notation for review comments so that feedback recipients know what to do w.r.t. content without having to ask many clarification question about meaning, type and urgency of the comment.
• Be constructive and friendly in your reviews; point out both passages that worked for you and text elements that need attention. “I had little time, so I could only point out the bad things” might be an ok argument in some communities, but does not go down well as balanced feedback (at least for me).
• Use the markups/tags from this post to communicate your [FB] effectively and efficiently, but do not forget to schedule a [D] on the [!]s, [CSFs], etc. 🙂

Feel free to use my symbols/markup, or add your own to the collection. If you do so, please let me know!

– Olaf (a.k.a. ZIO, socadk)

The next post in my mini-series on technical writing is “Research Methods and Peer Review Advice”.

Notes