Let’s Design a Next Generation Desktop E-mail App, Part I

| Analysis

On Wednesday, I wrote a Hidden Dimensions Column about how desktop e-mail is frakked. I mentioned the need for a next generation personal e-mail program, but didn't go into specifics. In this article, I'll get into some additional detail of what a next generation e-mail program ought to do.

I'm going to start with the assumption that the developer is agenda-free and doesn't feel a need to entice the user into the Internet data cloud. E-mails sitting on a server in another state, accessed with a Web interface and browser, may be okay for the enterprise, but generally not for individuals who want instant access, privacy and control. So the discussion here is constrained to a Macintosh application that uses POP or IMAP, in either a personal, work group or small business environment.

Understanding How People Use E-mail

Before one can design a solution, with a vision, one has to understand the basic problems with modern e-mail. Nemo, in his comments on Wednesday to my HD column, pointed out the "Conventionality Trap," which is a great observation. Reader Bosco also correctly pointed to the "Hierarchical Filing Trap." I'll add another. The "Overload Trap." The original design of e-mail programs, back in dial-up days, with an inbox and named mail folders was never envisioned to handle the volume of e-mail we encounter today.

The first thing everyone complains about, driven by the factors above and more, is the overloaded inbox. The inbox is used as a dumping ground because there are valid reasons for retaining an e-mail, but mechanisms to handle the retention are missing. For example, people will typically keep an e-mail in the inbox because it:

  • has an interesting or valuable attachment.
  • has a tidbit of technical knowledge
  • contains valuable contact information
  • schedules a meeting
  • creates a task assigned by someone else
  • asks a question that must be researched
  • is too difficult or time consuming to file it in a named mailbox. By difficult, I mean UI nuances such as dragging accurately, remembering keyboard shortcuts, etc.

 

Then they hope they'll be able to find it with a search. There are probably more reasons likes the ones above, but these are a good starting point. Once we understand why people retain an e-mail, we can start to deal with the problem. However, before I lay that out, I need to back up. Forgive the digression.

E-mail App Structure and Modules

Most e-mail programs provide a Filtering service, but filters automatically exclude or file a message. If filed, it can be forgotten. Two more modules are needed:

A Handler. An e-mail Handler is designed to allow user-level interaction instead of an automated action. It assists the user with handling a message due to the retention reasons listed above. Filters can never provide this kind of user interaction, so the end result is a message that gets through the filter, but is left in the inbox lacking any further assistance.

A Smart Viewer. Most if not all e-mail programs display every message the same way based on global preferences. But different kinds of e-mails need different viewing options. For example, if a distant friend sends a joke to 23 recipients, it's okay for the viewer's To: field to say: Tom, Larry, Jane and 20 more.... But if the sender is a manager or team leader, you probably want to see all the recipients without further ado. Another example is headers. If the message is suspected of being a phishing scam, you probably want to see the full e-mail header. If it's from your mom, you don't. A smart Viewer should handle all that.

Because all senders, if they get through the Filter, have the same status in modern e-mail programs, problems arise. There needs to be additional metadata for key senders such as boss, wife, kids, colleagues, etc.

A Logical Sequence of Modules

Now we can go back and look at a typical message. It wasn't spam. That got blocked in the filter with, say, Spam Sieve. It was addressed to you personally, so it's a candidate for the inbox. Next, the Handler comes up -- something to be envisioned and designed -- and interactively helps the user deal with the message. Here is where the user can assign keywords, redirect the message to storage, use data detectors to create an address book entry, create a task in a complementary ToDo manager like Things, or interact with a superior calendar program like BusyCal.

Handlers should be friendly and patient. If the user doesn't want to handle the message, it can be marked as unhandled. Later, the e-mail program, learning from the user's habits, can generate a popup and ask again if the message can be handled. User preferences can dictate when these reminders are allowed to pop up. The inbox remains sparse, if not empty.

The Handler and the Viewer should work hand in hand to provide the user with all the information needed to make a decision about the message and how to file it. For example, if the Viewer finds the sender in the Address Book, a section of the Address Book with all known information can be put in a corner of the viewer. (In case you want to call them.) Not everyone's signature is complete. Also, the recipient should be able to drag-select over a region of the e-mail and store that information in a scrapbook. Many of the features of modern scrapbook programs are missing from e-mail apps.

In the end, the goal is to deal with the reasons why people default to leaving an e-mail in the inbox and create good handling procedures so that information, tasks, meetings, and so on are integrated into corresponding apps like calendars, ToDos, information archives, iPhoto, scrapbooks, and so on. Apple's mail.app has some but not all of this, and it's clunky to use.

I should also point out that Apple's mail.app has a great contextual menu (right click) for selected text. It will even read portions of the e-mail out loud or do a Spotlight or Google search on the selected text. It's a great start.

Summary

In this first part, I've defined what I believe would be a valuable feature for a next generation e-mail app. I have others in mind. In the meantime, please add your comments and suggestions in the comments below. As a group, perhaps we can make a diference.

Sign Up for the Newsletter

Join the TMO Express Daily Newsletter to get the latest Mac headlines in your e-mail every weekday.

Comments

John Martellaro

As screens get bigger, like the 24-in LED Cinema Display and the 27-inch iMac, there’s an opportunity to have really great viewers. For example, a pane that has a listing of all the recent e-mails from someone whose metadata defines a manager. Also, I haven’t gotten to the issue of group access to archived data.  More on that later—one thing at a time!

JonGl

You ought to search the webs for Zoe, the local email client/server/searcher. It seems to be a dead project, but reading on how it works might give you ideas on those “handlers” and how, to some extent, it can be automated. Gmail has picked up on some of those, but Zoe was much more extensive. And it predated Gmail—completely outside the box, as they say…

-Jon

Bosco (Brad Hutchings)

So let’s go full screen and divide the screen like this:

—————  ———-
|          |  |        |
|          |  |        |
|          |  |        |
|          |  ———-
|          |  ———-
|          |  |        |
|          |  |        |
|          |  |        |
—————  ———-

The left half is the message area. Let’s do any kind of message. Perhaps it’s email, tweets, Facebook postings, AOL IM, RSS, anything there is an API that we can use to suck down data meant for us. There would be some way to group those incoming messages for processing. For example, unprocessed mail to product support I might want to handle all in one shot.

The top right corner is our context area. Messages are from one source and typically to one or more people. Up here, we figure out who this is from and pull up all the information we have about them. We also can page through to who known recipients are.

The bottom right is our data archiving service. Drag a tweet, a message, a text clipping, or whatever there, and it would know how to save it for searching later. This area could be customized for different activities. Say I’m answering product support questions. The left area just has my list of those to go through. The right area might have folders for “completed”, “in progress”, “fwd to someone else”, etc.

So now the fun part. Tell me what’s missing.

John Martellaro

Bosco,
I was thinking along the same lines for a Smart Viewer! Although I envision the handler to generally intervene before one has to start thinking about dragging anything to a named folder.

John Dingler

Jim and Bosco,
I think the new email app should have the shape of a pant leg and shoe; It’s humanistic.

1. The upper part of the pant leg would be the default container; It’s where all messages first wind up.
2. If after a week they are not sorted/categorized, they automatically trickle down into the lower part of the pant leg.
3. The pocket would contain the important mails, with the top register, the PRIORITY mail (Contr-P), and the lower register, the LESS imporant (Contr-L)
3. The shoe body, SPAMS and SCAMS. (Contr-S)
4. And the thick sole of the shoe, messages from your GIRL/BOYFRIENDS you want to keep super secret. (Contr-G [or B])

? ? ? ? ? ? ? ? ? ? ? ? ? ?
  ?    ?              ?      ?
  ?    ?              ?      ?
    ?    ? ? ? ? ? ? ? ? ?      ?
      ?    ?              ?      ?
      ?    ?              ?      ?
        ?  ? ? ? ? ? ? ? ? ?      ?
          ?                          ?
            ?                          ?
            ?                          ?
              ?                          ?
                ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
              ?                          ?
              ?                          ?
              ?                          ?
            ?                          ?
            ?                          ?
            ?                          ?
          ?                          ?
          ?                          ?
          ?                          ?
        ?                          ?
        ?                          ?
        ?                          ?
      ? ? ? ? ? ? ? ? ? ? ? ? ? ?
        ?            ?
        ?            ?
      ?            ?
      ?              ?           
      ?                ? ? ? ? ? ? ? ?
      ?                                    ?
      ?                                    ?
      ?                                    ?
      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
      ?                                      ?
      ? ? ? ? ? ? ? ? ? ?  ? ? ? ? ? ? ? ? ? ?

    [ illustration ]

JonGl

2. If after a week they are not sorted/categorized, they automatically trickle down into the lower part of the pant leg.

I most sincerely like this part. The auto-trickle-down.

It sort of reminds me of the old days of Claris Emailer and Cyberdog. You could have the inbox only display unread mail. Once the email was read, it would disappear from the inbox. Also, in Claris, at least (been a long time), I think you could automatically have mail older than a week go automatically to your Read mail folder.

However, it would be interesting to see how this could be expanded upon.

Here’s a question. Are you looking for ideas more for the look/interface, or for how it would operate/organize? For instance, tags and labels vs. folders?

If the latter, there is also the DevonThink way. It automagically categorizes items based on their vocabulary/semantics. I haven’t tried throwing my email at it yet, but I wonder how well it would do at organizing it?

One thing that needs to be done, IMO, is to enable super-quick and super-easy tagging of emails, and cross-categorization. MailTags is nice, but at least the older version was a bit clumsy. I guess that is why I thought of the Devon way.

-Jon

John Dingler

JohnGl,
Never used Claris and I heard that Cyberdog had a loyal following, but they were before I got into computers. l just got Apple Mail up and running for the first time. I will be migrating gradually from Yahoomail and Gmail, maintaining the latter until I get used to Mail. I wonder if Apple Mail has a mass mailing number limit like Gmail. I am dropping Yahoo altogether, not that it made its pact with MS.

JonGl

I wonder if Apple Mail has a mass mailing number limit like Gmail.

Actually, I fear that even if you use Mail.app with Gmail, you will have that same limit. It’s in the SMTP server, not the app. If you have a non-Gmail account, I can bet you will be fine, but not through Gmail. I send weekly emails to much more than 50 people at a time, and have no problems through usa.net server.

And it’s a shame you never got to use those earlier apps. They were awesome in their day. wink

-Jon

xmattingly

I think the new email app should have the shape of a pant leg and shoe; It?s humanistic.

Toilet paper hanging out the back end can be your junk mail. smile

Zarko

It’s not the most robust or user friendly capability, but the Mail app does have an iota of the functionality that you’re looking for.  If you go to preferences, the furthest tab on the right is “Rules.”  That pane allows you to set some rather cool filtering behaviors, such as coloring the text or the background of incoming mail messages.  (this is the same functionality that, when Mail is in default, shows all messages from apple with a blue highlight—you now know how to turn that off!)
It will also trigger the running of an apple script.

I use these rules extensively and have a rainbow inbox.  It is a really handy feature for visually sorting information.  It’s not as easy to set up as it should be, and it doesn’t do as much as your article suggests.  But while you’re waiting for the day, it might serve as a handy intermediary.

BTW, I’m personally holding my hopes up for wave.

JonGl

I just rediscovered a new mail app, called PostBox: PostBox Features

I last looked at it way back in alpha stage, and it was nothing like this! It seems to do a fair amount of what is being discussed (with the exception of the automatic filing/filters). Maybe worth a quickie review, John?

-Jon

Log-in to comment