When I was in middle school, I was given my first messanger-style backpack. I hated traditional backpacks, and I fell in love with the thing, except for one problem: paper handling.
To this day, I have never been any good with paper, growing large piles of it in my varies phases of school like some strange paper farmer, hearding piles around and flipping frantically through them for my prize winning notes when the fair comes to town. This happened through all my years at school, including college. To be perfectly honest, my inability to organize the files led me to pulling my hair out and was probably a huge detriment to my education.
The thing is, I like taking notes, especially when I'm gaining knowledge.
While I've been at WCMC, I noticed that I was not alone in these habits and shortfalls. Nearly everyone has a pad of paper with them at meetings, or at least a sheet to jot notes on. I've seen cubicles with gigantic piles of papers, in no way organized outside of a few pointers in the owner's head.
It was not long after I started at WCMC that I realized I was going to go paperless. Not that I merely was, but I had to, for my own sanity - space is limited, I hate retaining physical things longer than necessary, et cetera. I gave myself these simple guidelines to help define the system I ended up using:
Dirt Simple - minimal effort needed to take/keep/distribute notes. Notetaking should not be a time suck.
Flexible End Results - we have a document management system, and I need to be able to author into that, preferably with full metadata. I also occasionally need to publish notes to the web, and an easy transition to HTML is necessary.
Flexible Structure - people who have watched me blog for a long time know that I don't have one style. Sometimes I do bulletted lists, sometimes I do free form paragraphs, sometimes I do very formal structure. I need to be able to do all of this, and simply. It needs a strong sense of markup so that I can make these structures work.
Natural - I don't want to have to learn a lot to get things done. Slight tweaking to existing behavior would be best.
Platform-independent - I need something binary-safe, authorable anywhere and preferably with multiple tools, and that I'm not going to get locked in with.
What I Went With
Text, formatted with Markdown
It took me almost a year of telling myself I needed to sit down and learn it, but when I finally installed Markdown and took the time to learn it, everything changed.
Markdown, for those who aren't familiar, is a very simple text format that is both human readable and, important, converts to XHTML cleanly using a Perl script. I quote the About page:
The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.
Like I said before, I have habits from years of note taking - lots of bulletted lists, lots of asterisks for emphasis, intended text when necessary. Markdown only required a few tweaks on my part (blockquoting needs a bracket, line breaks need two spaces at the end of a line, etc) to adapt it into my usual workflow.
Now I don't spend my time writing paragraph tags or Web 1.0-style line breaks. I don't have to write a bunch of bold tags or remember to wrap text in pre tags if I just intent it a line. I can just write, and write, and write - and this saves me enough time that I can write more. If I need a web version, I run it through the script; if I need to upload the raw text into our document repository, it's still human readable. It's really the best of both worlds.
There's added bonuses to Markdown: Both Movable Type and Blosxom can use it as a plugin. As such, all of my blog posts - both this blog and my workblog - convert my Markdown text to HTML instantly, saving me the drudgery of HTML tags in blog work. (More on this tomorrow.) The simplicity of Markdown also leads it to be writable on my Sidekick - I can start banging out notes on it if I need to, and transfer them into a regular text file whenever I get a chance. Quick notetaking with rich markup - you can't beat it.
SubEthaEdit
After having been a BBEdit man for years, I made the switch to SEE sometime around two years ago, though I never really got much out of it until I got to WCMC.
There are two major attributes of SEE that make it a better choice for me over BBEdit, or TextWrangler, or any of the other GUI-based text editors:
Collaborative editing via Bonjour is what SEE is known best for, and it's honestly been a huge boon when I need to do document editing with multiple people. I've saved countless hours through simultaneous editing instead of the save-send-wait-revise cycle.
But equally importantly, SEE is lightweight and simple. I don't need the long menus or fifty preference settings, I just need a text editor that has the functionality I need (find, replace, syntax highlight). SEE fits this niche perfectly.
pico
Okay, I'm officially coming out of the text editor closet: I don't use emacs, although I know how to. I don't use vi, although I can certainly get around with it. Nope, I have no regard for my geek credibility - I use pico, or in some instances nano. I'm not ashamed of it, because it does exactly what I want it to: not get in the way of my editing. I'm not fumbling with edit modes, not having to pull open new documents to read the help - I'm just getting my work done. pico certainly doesn't get in the way of writing in Markdown, and can act as a pastebucket for documents I'm writing elsewhere that I can't sftp up.
Spotlight and/or Quicksilver
I have made my Quicksilver usage well known, so I'll spare you a lot of the standard "what-is-Quicksilver" ramblings. In terms of these endevours, Quicksilver will give me quick access and the sort of quick actions that makes working with text a joy. Quick appends? Can do. Email the doc to someone else? Sure thing. You know the drill.
Adding 10.4 into the equation has only helped. Spotlight hasn't replaced Quicksilver at all - it's merely provided extra functionality. Full text searching allows me to pull back the documents ages after the fact without having to worry if they're buried in the wrong folder.
I want to go into a few use cases that illustrate why this all works for me.
Example 1: Vendor Ticketing
The Problem: We frequently have hardware breakages and software bugs crop up at bad times. Chasing down vendors is a time sink; keeping notes that everyone (team members, direct management, senior management) has easy access to is a heavy loud.
The Solution: Traditionally, we've been told to use HEAT, our ticketing system. I actually don't mind HEAT - except for the fact that it takes me at least a minute to pull up a case and be ready to enter text into it. I need quick and effective - and SubEthaEdit is always open on my machine.
So every time we have a need to open a case, I open it both in HEAT and I start a new document on my machine. Between Quicksilver and Spotlight, I can have it open within seconds of vendor contact - meaning the caller ID can help me grab the right document before I even touch the handset. I can type much faster than I write, and with Markdown, a rich document with links and markup takes no longer than regular writing.
All combined, by the time I'm off the phone, I've already saved the document back to my workblog (more on this tomorrow), and I can copy and paste the relevant bits into HEAT to keep our official system up to date.
Example 2: Project Groundwork
The Problem: A large amount of my project time is research and documentation. If we're looking to deploy new technology - or in some cases, figure out what product we need - there's lots of text that I will need to generate to get us on firm ground about which direction we should go in.
The Solution: The key here is that the documents need to be rich - lots of links to outside sources, properly documented quotes, and the like. Markdown, again, leaves me not worrying about my link tags and giving me more time to actually get the research done. If I'm in a conference call along with other co-workers and a vendor, I can go collaborative in SEE and they can add their thoughts inline, saving us the comparison of notes later. Quicker research leads to quicker turnaround times.
Example 3: WWDC 2005
Given that there's an actual event named here, you might've guessed that this is my really concrete example.
I spent a week at WWDC this year under the gun. We were, in comparison to the year before, dealing with a 50% reduction in staff from my department covering sessions. My direct counterpart was not at the conference and was in need of the knowledge as much as I was, as were a number of people staying in NYC for the week. My missives needed to be quickly transmittable - I was double SSH tunneled over a crappy wireless connection to get through our firewall. I had a full plate of sessions where I was often the only member of my office there, and note taking at conferences routinely leads to burnout and/or brain frying. (My dear friend Suw is currently at Supernova 2005 and despite promising she was not going to take her usual level of notes to preserve her strength, she's still trying to sate her transcription urge and having to apologize in her posts for the holes because it is damn tough to do.)
This is where all the groundwork paid off: I successfully churned out over 160k, or ~16,129 words, of notes without seriously burning myself out. (I will admit to being a bit beat on Friday night.) I had no major gaps in my coverage, and managed to even fully copy down the goodies for a very hands on tutorial in Subversion.
If you were to look at my workblog, you'd see a somewhat disgusting amount of consistency in the WWDC posts. The standard formatting of headers and subsections, proper distinction for commands you need to type - it was all effortless. If I had spent my time typing openbracket-a-space-h-r-e-f-equals (and so on) every time I had to create a link to something, I can't even imagine what a wreck I would have ended up being.
Transmission was a breeze - less markup meant less transmission time over the very poor wireless connection. As I'll illustrate more tomorrow, the second it was uploaded, it was instantly accessible by everyone else in my office. The keynote coverage even managed to spill over to a post here, since I'm using Markdown on both - again, no need to worry about formatting it differently for posting on two blog systems compared to keeping an easily searched local version.
All things considered, I would not have made it through WWDC without this setup.
I'm well aware that this post may seem like much ado about very little. I've blown over 2000 words out, talking essentially about writing things down in a text editor with some fancy characters here and there.
The thing I'm trying to stress is that this has really changed my life and the way I Get Things Done. (Uh oh, I'm invoking GTD strategies!) I cut myself from the paper chain, and now I'm living a lightweight, text-based existence. And it feels good.
Seriously, if you do any notetaking on a computer - check out Markdown. Integrate it into your routine. That way, you'll have rich text documents you can blast into HTML whenever you want. It really is a god send.
Reminder: Wednesday, I'll tie this up with a diatribe about my workblog; Thursday night, I'll dive into OS X Server and show you why Apple really does have their shit together when it come to Enterprise IT, and Friday night I'll jump back to the work blogs and show you how to get one running in 10 minutes.
