No matter what you do, odds are that a significant amount of your time doing it is spent answering emails. That is certainly true for me. Email is a unifying thread across my professional and creative life. It directs the course of my days at work and my nights playing music and making art. As a result, it is the first thing I check in the morning, the most important part of my workday during the week, and one of the last things I look at before I go to sleep at night. Everyone I know is in the same situation.
It’s too bad, then, that email is all wrong. Though email is such an important part of my day, none of the email tools I’ve tried offer any of the things that I need to respond thoughtfully and keep myself organized. Email web apps limit you to accounts provided by that host or require you to do a bunch of weird setup to look at other accounts. That’s before looking at any of the tools these providers offer. Thunderbird is stuck trying to emulate the way Outlook worked in 2007. Outlook—the default, required client for most users—offers notes, tasks, folders, reminders, rules, and integrations to other Office software, but at the end of the day every email that flows into the application looks and feels the same, and every important tool exists somewhere else on the reader’s machine. It’s up to the reader to categorize, prioritize, leverage the right tools, and follow-up on their messages. Most readers are OK with that responsibility, but the sheer volume of email we have to deal with everyday can make it difficult to faithfully execute this responsibility.
Here are the main problems as I see them:
- Every email in every client looks and feels the same by default
- “Reading” is the objective. For many users, when an email is “read,” it is filed away for further action in the same pile with things that don’t need action. Important items can fall through the cracks unless the user deploys some secondary processing method. These methods vary widely by user but may include flags, folders, tasks, changing the status back to unread, or (more likely, I suspect) some combination of everything the interface offers in a desperate bid to stay on top of it all.
- Every item must be read in order to be processed. See above.
- All of the most important tools—word processors, spreadsheets, web searches, IM clients, checklists, and so on—exist somewhere else. There is no connection between an email which triggered a process and the tools needed to complete it.
- This is also true in the archival sense. Often an email and its attachments are the only evidence of work done. These are only the most superficial products of deeper processes which are documented on both local and remote file systems.
Lately I’ve been thinking about a different kind of email tool. I’d like to have an app where I can build process templates and drag emails to “anchors” for those processes. Dragging an email to the app would create an action item, and the process anchor would follow rules to provide the specific tools needed to complete the item.
Let’s say you have a standard process you typically need to support from email. For example, for several years my job looked like this:
- Receive an email with an assignment
- Create a folder on a filesystem on the enterprise network
- Populate this folder with certain templates
- Collect information from the internet and other emails
- Use this information to complete the templates in the folder
- Submit a link to the folder to a reviewer
- Revise items based on the reviewer’s comments
- Send approved items to a customer
- Archive work products in an online repository
In my platonic email app, I would drag the assignment email to a process anchor in the app. This process anchor would increment an action item counter and then follow a rule to create the folder, populate it with templates, provide a list of links to the places where I need to gather information, give me the ability to open the template documents and work them right from the application, automatically send a message to the approver when I’m ready, automatically email the customer, and then pop a link to the repository upload (or, in an even more perfect world, use an API to upload the work products). After completing the process, the action item counter would decrement.
Each action item associated to the anchor would have its own workspace, which would include other tools like a notepad and calculator. Similar anchors would exist for other processes configured by the user, surfacing different tools and following different processes set in advance. These processes would be configured with natural language rules, like Monday.com automations.
Anyway, I doubt I’ll ever have the time to build this tool, but I’m always looking for it. In the meantime, maybe just writing out the ways that I think email is wrong will help me be more thoughtful about how to make it right with the tools I already have.
Computers should be bicycles for the mind, but with email we are trudging through confusion.
C.B. Crenshaw 
I am an inbox zero kind of dude. After I have completely addressed an email, I archive it, so my Inbox is a to-do list of sorts. For ongoing projects, like a play, I move all of those emails to a related folder when I have finished with it, instead of archiving.
At my work we use a ticketing system for tasks, and if someone emails or IMs me something related to a task, I politely ask them to re-ask the question within the ticketing system. This is not bullet-proof, as I have found getting my bosses to use the system to be a dead-end, and because we pay per-license, some people just don’t have access.
CardDav is an open-source protocol, like email, for task management, which works well as an email replacements, and is well-supported by applications like Thunderbird, but I don’t think it really meets the requirements in the workflow you outlined in your blog.
A very frustrating aspect about email is that it has not moved forward in a few decades. The supported HTML, and how it renders, varies wildly across email platforms, so plain emails just work better. Google has made some stabs at remedying this, but not in an open manner, so its efforts have never really caught on.
LikeLiked by 1 person
Thanks so much for the thoughtful response! I’ve thought about that approach to email before, but a couple things ways hold me back. First, I’ve noticed that email folders never consistently work as expected. I like to use multiple clients to manage mail—i use aggregating front-ends on every device I own—and folders are never properly synced between them, so I’ve never come to rely on them. Maybe this is much better in the years since I last tried it? In general, though, (second), I don’t really like folders as tools to manage information. Over the years, I’ve moved away from hierarchical storage and knowledge management everywhere I can toward a flatter ontology organized with tags, keywords, dates, and associations. In the email domain, this means that my inboxes are just big lakes of read emails into which I cast search nets. This fills some people with existential dread, which delights me to no end 😊
This flat practice drives my clean inbox friends absolutely crazy, but when we talk about email we all seem to have the same problems. That’s part of what inspired this post and also why I think you’re right to suggest that the problem might lie with the medium itself. One the one hand, email is technically limited, as you point out, but on the other hand it seems like all the tools we have to manage it are too opinionated. I believe these two problems are different sides of the same coin. Email is too basic and fundamental a service to be sufficiently “modernized” in a way that will support all necessary clients—hence the technical limitation—but also too dynamic to manage with a single tool. What it needs instead is a whole new management paradigm. I believe an extensible tool like I described would go some way toward shifting the paradigm, but at the end of the day it is basically just a way of creating a ticketing system for the individual. I’ve used a bunch of ticketing systems, and the best of them do exactly what I described in the post: receive an email, process it according to some logic, assign the processed task to a person, and provide them the tools to complete the task before closing the loop. What I’d like to see is something independent of a web subscription, and very extensible for the user. If you take that to its logical conclusion, however, I think that what I’m describing is just another operating system layered on top of the existing one. Maybe what we really need are new automation tools to bridge emails with installed applications.
LikeLike