Tag: Email

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.