For many, email is now the master communication channel. But it’s actually a pretty poor one in this age of mobile computing. Email needs to beaten down into just another channel of flowing information.

- MG Siegler via parislemon

Siegler is wising up to my desire for liquid email, although he doesn’t call it that. What do I mean by liquid email?

Liquid Email, Stowe Boyd

I am using the term liquid media to represent this new soupy, swirling, turbulent cascade of various media types being pulled into the streaming mess of today’s social media. We see images resolved in Twitter clients without leaving the Twitter stream, and Flipboard yanking articles free of their moorings on the NY Times or Wired, and previewing them for us in the article stream. Every sort of media will be pulled into the flow: soon, television will be repurposed as yet-another-media-type and played in the stream like audio is now.

This is all happening because we will naturally gravitate to the place with the fastest tempo, because the best stuff appears there first. Paradoxically, the places with the strongest flow will seem the most calm, because we won’t be jumping from the stream to the browser and back again a hundred times a day: we will stay in the stream: media content will be harvested, and pulled into context for us.

I think this is going to happen next with email.

Email has its own context: the inbox, the email apps, Outlook. The metaphor is now second nature to us: email comes in, from anyone having our email address, maybe is filtered and categorized, but mostly is shown as a chronological list of discrete messages. If we are lucky, our email tool ties together email threads, although that mechanism is semantically flawed, because a single email can deal with many topics. As a result, email is as messy as we are. But more structure won’t help email. The problem is the metaphor, and as a result, how the metaphor channels our thinking about communication.

Using a beta version of Nimble has caused me to think about a fusion of Twitter and email. That product manages to support both email and Twitter, but not in the way that I am envisioning, although the app is inventive and likely to be a good social CRM offering.

Imagine a liquid model of email, based on Twitter being my preferred context for communication:

  1. I receive email in Gmail. 
  2. A new Twitter client (or a new version of Twitter) — let’s call it Liquidate — captures all my incoming emails from Gmail, and drops a shortened link into my stream for each, with the subject line as the tweet, and associating the email address of the sender to their Twitter handle, if known.
  3. The fact that this is an email would be made obvious in the UI, and I could open the text of the mail — and bring it right into context — by clicking on a link.
  4. I could read the email text, and then respond to the sender either by a Twitter message, direct message, or another email, depending on the circumstance, and based on various criteria, like whether the sender has a Twitter account.
  5. If I opt to reply by email, the client would send that into Gmail, and I would always have Gmail as a repository, if I want to search there.

In essence, I would be treating email messages as just a long format tweet, and using Gmail as an appliance to carry that message from my streaming context out to a world that has not completely switched to Twitter or liquid media. But the activities associated with ‘email’ would be carried out in the streaming context, and the email would be just another sort of media pulled into and then pushed out of the stream. And again, I would always be able to go to Gmail directly, if needed.

I have other thoughts on this, based on using Sparrow recently, which I will have to spell out in the next few days or weeks.

Sparrow’s Dropbox Integration: A Security Nightmare

I have been using Sparrow as my email client instead of the web-based Gmail interface. It is a productive experience, and with a few caveats — I wish they had an undo button, and a way to access all my mail aside from search — I’ve been happy.

Since I use DSropbox extensively I was interested to see that Sparrow supports a Dropbox interface. However, after exploring it I have turned off the option, and I think others will want to as well.

The bottom line: Sparrow’s integration with Dropbox rellies on use of the Dropbox public folder, which means that any attachments that are shared via the Dropbox integration are accessible to anyone. And this is a dangerous option for most business users, who’d like more security than that.

The biggest problem is that Sparrow’s team aren’t very explicit about what’s going on. If you read the two short descriptions they provide online, no mention is made of the use of the public Dropbox folder (see https://www.dropbox.com/help/179, and https://sparrowmail.tenderapp.com/kb/starting-with-sparrow/dropbox-in-sparrow).

I only discovered this by seeing the URL of a test attachment go by, and then by asking their support about this:

The alternative approach would be complex but useful: creating a unique Dropbox for every sender-recipient pair, and automatically inviting the recipient’s to share those folders. That was my hope, but that’s not the way they pursued it.

How would it work? Say I sent mail with an attachment to my pal, Gerd Leonhard, who (hypothetically) uses both Sparrow and Dropbox. Sparrow would create a folder called stowe-boyd-and-gerd-leonhard in my Dropbox, and share it with Gerd. The attachment would be placed there. And when he opened the mail on his side, in Sparrow, clicking on the link would open the file from the corresponding folder on his hard drive.

[Note: this grow more complicated when multiple recipients are involved. Perhaps the Dropbox folder would be the name of the initial subject line, or the sender could provide the name of a Dropbox folder they wanted to use.]

The various problems in this pretty picture arise when the recipient of my email doesn’t use both Sparrow and Dropbox. Sparrow would have to deal with all the messy use cases by creating URLs that could be resolved by them, yielding attachments as needed, after confirming that the requesters have access rights, but this would require retaining active access to the Dropbox. The simplest way to do this is to direct recipients to claim a preconfigured Dropbox account, possibly.

So maybe the Sparrow team will take another pass at this, once they think about it.

There is a wonderful simplicity to the idea of a light weight email client relying solely on Dropbox for attachments, so long as Sparrow’s team steps up and builds something more secure.

I saw that Sparrow and Shortmail had integrated their offerings: Dave Troy, Bonjour to our Friends at Sparrow! Today, we announced a partnership with our friends at Paris-based Sparrow, the simple and beautifully-designed mail client for Mac OS X. Shortmail is all about simplicity, and so is Sparrow. So it seemed like a natural partnership to us. I don’t really buy that Shortmail is about simplicity, per se: it’s about minimalism, which is somewhat different. However much I liked the idea of shifting to the shortmail philosophy, I really didn’t like some of the design choices of Shortmail, like the chronological display of email threads, which seems backwards to me. I acquired the Sparrow email client for Mac OS X a few weeks ago, and used it briefly, but for a variety of reasons — mostly having to do with Gmail integration of other services — I slipped back to Gmail. But the newly announced integration with Shortmail has got me back, taking another look. I walked through the description of how to set up the integration at the Shortmail blog, which worked right out of the box. And the result is great, as shown at the top image. The implementation displays the mails in a thread in a reverse chronological order, which I find most intuitive. Best of all, Shortmail does away with the old timey convention of appending an the body of an email to the foot of a reply, which minimalizes the text floating by. Sparrow also includes a character counter when you are editing a shortmail. One hitch is that you have to move back and forth between different email accounts to write longer email. It might be nicer to have it all integrated, and you could simply decide to create an email as a shortmail. However, that might get confusing, so I am going to give this a try for a week or so, as is.
Zoom

I saw that Sparrow and Shortmail had integrated their offerings:

Dave Troy, Bonjour to our Friends at Sparrow!

Today, we announced a partnership with our friends at Paris-based Sparrow, the simple and beautifully-designed mail client for Mac OS X.

Shortmail is all about simplicity, and so is Sparrow. So it seemed like a natural partnership to us.

I don’t really buy that Shortmail is about simplicity, per se: it’s about minimalism, which is somewhat different.

However much I liked the idea of shifting to the shortmail philosophy, I really didn’t like some of the design choices of Shortmail, like the chronological display of email threads, which seems backwards to me.

I acquired the Sparrow email client for Mac OS X a few weeks ago, and used it briefly, but for a variety of reasons — mostly having to do with Gmail integration of other services — I slipped back to Gmail.

But the newly announced integration with Shortmail has got me back, taking another look.

I walked through the description of how to set up the integration at the Shortmail blog, which worked right out of the box. And the result is great, as shown at the top image.

The implementation displays the mails in a thread in a reverse chronological order, which I find most intuitive. Best of all, Shortmail does away with the old timey convention of appending an the body of an email to the foot of a reply, which minimalizes the text floating by.

Sparrow also includes a character counter when you are editing a shortmail.

One hitch is that you have to move back and forth between different email accounts to write longer email. It might be nicer to have it all integrated, and you could simply decide to create an email as a shortmail. However, that might get confusing, so I am going to give this a try for a week or so, as is.

Google Unveils Three Pane Gmail Interface

Typical.

I started using Sparrow this week — a Mac OS X lightweight email client — partly to get a three pane email view.

Then today, I read that Google announced a three pane display on Gmail, similar to what they did on the iPad.

So, I am out the $9.99 for Sparrow, I guess.

Sparrow is a reasonably good email client, but I was a bit misled by the positioning as a ‘social email client’. What’s the social part? It’s just email in a slightly more fluid UX.

There is a place for social email — as I wrote about in Liquid Email in July — but Sparrow isn’t it. And neither is Gmail.

So I’ll go back to Gmail. mostly because I can have a more-or-less similar experience on all platforms I use.