Organize bookmarks in folders by task

Make the most of bookmarks by sorting them by tasks.

That’s the lesson I learned after months of trudging along with a looong list of bookmarks. I would add links for later reading, then randomly pick pages to read or otherwise process, and it was not working.

Around New Year’s, I cleaned up the mess, threw out dead links and pages that seemed merely vaguely interesting. The remainder went into separate folders. This has been working really well for me so far: I remember and find bookmarks faster, and I process them faster (which means reading and filing or deleting).

Organize by task, not by content

The trick for me was to create bookmark folders by tasks, not by subject matter or contents! I now have the following bookmark folders:

  • Tech Writing with pages to read and archive useful ones.
  • Blog with pages to write about in this blog.
  • [Project] with pages to work on for articles or presentations, one per project.
  • Portable Freeware with pages of software to try out.
  • Travel with pages of hotels and restaurants to visit.
  • Inspire with pages to get me unstuck from writer’s block.
  • Lookup with pages to look up grammar rules, translations, prices, streets, etc.

Why does this work?

It works for two reasons:

  1. It’s basically following our own professional advice: Create documentation task-based, not based on the stuff you organize, whether it’s a user interface or random web pages.
  2. It’s inspired by GTD (Getting Things Done): Get productive by ensuring you can simply crank widgets as a tech writer.

Bonus tip

Sync your bookmarks across all your machines for even better order and productivity. I use xmarks for Firefox to ensure all my bookmarks are always up to date, regardless of which PC I use. When I’m on someone else’s machine, I can still look up my bookmarks online.

Your turn

How do you organize your tech comm bookmarks? Do folders work? Is there a better way? Please leave a comment.

Cranking widgets: “Getting Things Done” (GTD) as a tech writer

“Getting Things Done”, David Allen’s productivity method, works well for a technical writer who’s lined up tasks, so they’re ready to go and as easy as cranking widgets. Here’s how in my #2 GTD Principle for Tech Writers. (My #1 principle is about universal capture.)

Cranking widgets

Most of us technical writers face two different types of tasks: Deciding what to do – and actually doing it. It’s the second part that David Allen calls “cranking widgets”. It sounds like a mindless activity, but I take it to mean to get down to our craft and actually write. (For a more GTD-like take, try zenhabits’ recipe…)

I believe, and have experienced, that it makes sense to distinguish and to separate those two types of tasks as soon as a task appears. That gives me a slim chance that I’ll even have the time to decide before I actually have to do it.

The benefit is that I get to group similar tasks together and do related work at once, so I don’t have to jump around in the documentation with every single task I get.

The challenge is to juggle the deciding and the doing. Often I don’t have the time to do all the deciding until my inbox is empty and all tasks are neatly laid out and ready to be done.

Deciding before doing

This kind of task often comes disguised as the second type:

  • I get a phone call that asks me to correct something in existing documentation.
  • I receive an email about something that hasn’t been documented yet.
  • I get a request to furnish screenshots for a localized manual.

All these things need to be done eventually. But for efficient and effective documentation, it makes sense to first decide what to do exactly:

  • Is the correction in existing documentation actually legitimate? And if so, when is the best time to do it?
  • Is the missing documentation actually missing, or overdue from the latest release, or really part of a future release? Again, when is the best time to write and provide it?
  • What’s the most efficient way to get the screenshots for localization? Do I have to do those, or can I ask an intern to do them? If I should do them, should I change my process and create them along with the ones in the source language?

How to decide

The reason to keep the deciding apart from the doing is that the first engages me in a very different way. Deciding what to do is mainly thinking, planning and organizing: Is a request legitimate and timely? What do I need to do that? When is the best time to do it? This part is mainly concerned with logistics.

My answer is usually one of those four decisions:

  1. Do it now. This is what I choose for tasks that simply cannot wait and for tasks which don’t take very long. In other words, tasks which get much bigger by looking and deciding a couple of times. The risk is that these tasks take up much of my daily time, but the reward is that they’re in and out fairly quickly.
  2. Defer it to a set deadline. This goes for all requests that come with a deadline, whether it’s explicit or implied, for example, because it’s connected to an upcoming version or release of the documentation. These tasks go onto my to-do-list. You can also put them into your calendar or project plan…
  3. Defer it to sometime later. This is for everything that’s currently out of scope or merely nice to have. It goes on to a wish list.
  4. Delegate it. This is frequently wishful thinking, because most of the time I don’t have anyone to delegate to… 🙂 But occasionally, I get lucky and can ask an intern to take those screenshots… After I delegate the task, I’ll have to make sure to follow up, especially when it’s got a deadline.

Doing after deciding

Once I have sorted out (hopefully most of) my tasks, I can set about doing them, starting with the most urgent ones, but taking all the related ones together. I’m cranking widgets and, if I’m lucky, I might get into the flow.

Your turn

Does arranging your tasks work for you? Or do you have your work arranged for you? Or do you simply not have the time to even bother? Feel free to leave a comment.

Capture everything, or: Are you “Getting Things Done”?

Of course you are getting things done – like most of us tech writers… But do you apply the David Allen’s GTD method from his book Getting Things Done: The Art of Stress-Free Productivity (GTD)? (Hence the quotes into the title…)

Over the years, I’ve found a few principles from Allen’s method especially valuable for tech writers, whether you are a manager or not. They can also be found in other productivity contexts. I’m describing them as parts of GTD, because it’s a well-known method that explains its principles well – even if the implementation can be cumbersome. But that’s what Zen to Done is for… 🙂

Today, I discuss my #1 GTD Principle for Tech Writers:

Universal capture

The idea of universal capture (aka ubiquitous capture), as I understand it, is this: You’re most productive when you concentrate on the task at hand. You don’t waste “brain cycles” remembering other task. To free your mind from all this remembering, you dump everything into a consistent, trusted system – your universal capture. I find this blatantly obvious – and difficult to do well and reliably.

The problem

As I update documentation, new features need to be described in release notes, one or several manuals and the online help. At the same time, the occasional gap or error needs to be fixed in manuals and/or online help. Due to time and system constraints, I cannot address each issue in all formats as soon as it pops up.

So I need a way to capture any and all issues reliably, so I can forget about them until it’s time to address them. At first, I tried to use my inbox by sorting issues into one sub-folder per format. This approach had several problems:

  • Some issues needed to be addressed in more than one format or more than one manual.
  • Some issues were thrown up in phone calls or when colleagues stopped by with a manual in their hand.

My solution

I’m now using a personal wiki in our intranet which is, for transparency reasons, open for everyone to see and edit. This page is quick and easy to access and edit. It makes few demands on structure and allows me to be as brief or as elabrate as I can be at the “capturing moment.”

Each deliverable has a section of its own, so I can have the same entry in several sections if necessary. When it’s time to update a deliverable, I know I’ll have all issues captured in my wiki list. As I work on it, I strike through each addressed issue. Around the publication date, I condense all issues into a summary of major updates.

More tips and tricks

Leo Babauta (creator of Zen to Done) shares a few general insights about how ubiquitous capture works and when it doesn’t.

Your turn

Do you use universal capture? Or another method of GTD? Do you find it useful? What tools do you use? Please feel free to comment!