GTD, Emacs, and the age of remote collaboration

Starting a new role is always a litmus test for any GTD system you have. What may have worked in old roles may not work in new roles (though the holy grail is a system that is adaptable anywhere). While my emacs org-mode system has served me very well from a task (and life) management perspective, it has its shortcomings.

With my new role, my workplace is even more Google docs driven than my last workplace, and vastly more collaborative and global (with the added challenge of everything being remote in these covid times). One of the shortcomings with emacs for me previously was sharing work, and I have to admit the idea of a more web-integrated, cloud syncing, browser-based workflow (as long as it will also work offline) is attractive. Since it’s getting close to that time of year when I review what’s working and what’s not (and my new boss nearly fainted when I sent him a plain text formatted table from emacs org-mode of my onboarding plan), I decided to look at the good and bad in my workflow and start some GTD experimenting over the last weekend.

The Problem(s)

Emacs power as an organizational system, and its issues, come largely from the fact it is so long in the tooth. 35 years old, built for an era before styled text and that whole world wide web “thing”. Here’s what I view as the main problems in my particular context (YMMV).

  1. Plain text only
  2. EiE disease (Everything in Emacs)
  3. Lack of collaboration features

1. Plain text only

In some cases this seems like a feature, not a bug, since you can use markdown (though you will move to org-mode) to write things and plain text is portable, versionable, and has obvious longevity as a format. The lack of native support for styled text and interaction with a world where you want to do something like drag a diagram on a web page into your notes (which Notion just allowed me to do effortlessly) makes emacs sometimes feel like you are belabouring a point (though emacs has many workarounds to text-based representations of html, though it rejects html in things as obviously useful as email to enable the use of it as a viable, modern email client.).

2. EiE (Everything in Emacs)

An excellent operating system with a poor editor, you can do a frankly astounding number of things with emacs, its lisp-based REPL, and the ecosystem of packages that have been extending its functionality for decades. But emacs is an island. It controls the nature of all that enters it and bends it to its will. It’s at once compelling, since you have a single tool to do everything, but at the same time you can end up rabbit holing into such things as moving your email into emacs despite lack of html support or starting to consider ir for web brossing, or even… I am not joking as your windows manager. At some point, you’re breaking or compromising other things merely to use your favourite text editor. It gets solipsistic.

Currently I use its astounding org-mode for note taking, and my task management system, a lightweight CRM, my journal (handily encrypted via gpg), and an interface to the ledger-CLI plain-text accounting system which tracks my finances. IRC as well. And I feel I use it only for the things it should be used for in this context.

3. Collaboration

Island life can get lonely. In an age where web-based apps and APIs hold the basis of collaboration, and key information exists in other systems, so when needing to combine them, an application that exists in isolation needs the overwhelming advantages described above to pay the collaborative cost. Particularly when collaboration begins to take the form of documents or URIs, which people prefer to share as an internet point source, rather than mailing files around. Collaborating and coordinating are now the dominant modes of working for most knowledge workers. And this is kind of where I’m finding emacs a bit painful these days despite the sparkling advantages of org-mode. It’s fundamental, file-on-a-machine metaphor and pre-internet nature almost means it lives in an isolated bubble.

GTD Mark III

So, what would a more web- and collaborative-friendly flow look like, ideally? Getting collaboration and styled text would be the main advantages, as well as nicer user experience but not at the cost of emacs’ amazing task management (via org-mode). I think for me there are aa handful of factors I would be scoring a new app and flow on.

  1. Collaboration
  2. Ubiquitous
  3. Just One app
  4. Contextual Todos
  5. App Meta

1. Collaboration

I need to be able to share written materials, tasks, and docs for collaboration and reviewability more easily. OK, a dream would be a function to somehow reflect google docs directly in an app and then push and pull changes seamlessly to those docs, but ultimately, writing something in org-mode, exporting it into a format others can collaborate on, and then switching to that system is just too much friction at the scale and remotely. Anything that removes an extra step from needing to collaborate is a bonus. Integrations would sweeten the pot.

2. Ubiquitous

While it never really affected me too much in the past, emacs org-mode not having a viable mobile app (Beorg has had a consistent dropbox error for several months now which checkmates me using the app) does mean I use other apps to deal with that shortfall (primarily Bear) which then involves copying and pasting on-the-move stuff or, for example, notes on books I’m reading and then pasting them into emacs at a later time. Blergh. Having something with a viable mobile app and usable on a lower profile machine (or even iPad or beefed-up chromebook) is compelling. (I have to admit, entering reading notes on a book I was reading directly into Notion rather than Bear seemed seamless this past Sunday.).

3. Just One App

Ironically, I do want whatever I use next to preferably combine notetaking and robust task management. I depend on my GTD system to get things out of my head and handle them. My immediate take on the state of play in the current ecosystem is that apps seem to emphasize one or the other, not both, and that I may be forced to make a choice or crawl back to emacs (though in my mind, an app for writing and collaboration and one for task management that is at least linked, may work. As a fallback, Notion or Roam plus Taskpaper might work.).

4. In-Context Todos

One of the best features of emacs org-mode is the ability to throw a hotkeyed TODO inline or quick cpature into something I’m working on and then have it picked up by the agenda functionality. It provides context on where and when that happened (generally, because I use dated log files for consistency) and if I’ve tagged it right, allows me to know the person or project it’s applicable to. That almost assures making sure tasks get into my system and don’t get dropped.

App Meta

Kind of a combo thing here, but the meta around the app is important. Nicer UX, easier customization, and a solid ecosystem for modification and support are really important. It needs to also save me from myself (something emacs org-mode has done a number of times now). though in emacs this required significant effort on my part, and substantial fiddling in lisp and configuration files to get it to look decent, a configuring packages, or writing glue lisp to get the system to where it is now. Being able to bend it to my will easier would be most very welcome

The Experiment

Admittedly, if I could find a way to have org-mode or markdown documents sync natively and seamlessly with the google docs’ APIs so that I could simply push and pull changes and comments to a bank of google docs, I’d probably rethink things. But needing better collaboration and sharing features has made me think a tools and workflow survey is defintely overdue.

So far, focusing on the writing portion of the equation I’ve been looking at Notion and Roam Research which are both interesting for various reasons. Notion’s strong writing and its interesting inline database feature as well as fact its web interface extends seamlessly to an electron app and a mobile app is impressive. It’s a very clean experience writing in it so far, though very concerned about how task management and capture will work (as well as things like recurring tasks and speed). Roam Research is also very interesting and have to admit I really like the bi-directional linking between tagged items (if not the way the app represents those links in-line contextually but the handling of Todos, despite the fact they are in-context feels slightly emacs-like, but so much less robust and configurable. Also, so far from here in Asia it is a bit pokey in the browser and the app only allows adding in items into a quick capture on mobile. Need to spend more time with it. It could also be prettier quite frankly.

So, I’ll be putting some time in over the next couple of weeks to see if it’s time for a change and reporting back on the pros and cons of each. Interestingly enough, as starting test, I’ve drafted this blog post in Notion as part of a small database to help me manage the content creation for the blog and have to admit it’s been a smooth, nice experience writing it. I also had the same database have a kanban view of the data so I can see where multiple blog posts are in the content creation process (and then am exporting it out to markdown for inclusion in the hugo-based blog.).

Let’s see how the experiment goes. I’ll report back on grading the apps I look at well as well as possible combos. At the moment, a bit terrified of dropping something in one of the new systems, so currently doing double-entry in emacs and the new systems in case I need to slink back to emacs and revert if the experiment fails.

Let me know what you think about the post @awws or hola@wakatara.com .


The trouble with emacs in the age of web-based collaboration and sharing.

Daryl Manning

gtdemacs

1713 Words

2020-10-29 12:05 +0800