News for hackers. Stuff that matters.
Re:Re-Designing the classic email client by rdl on Tuesday July 10, 2012 @11:36AM (#4224287)
I comfortably ignore any comments about email and what it should be from anyone who hasn't used a text email client (well configured) like mutt, mh, elm, or an emacs mode for at least 100 hours.

The only real complaints I have about email with a well-configured text client are: * HTML mail from idiots * Syncing on multiple machines, with offline mode (IMAP is ok, but you want to keep full repositories on laptops for use without network, and ideally to process email more quickly than network access) * Mobile clients -- Android has K9Mail, haven't found anything great on iOS yet. The keyboard-based mail workflow doesn't translate to the tablet/phone form factor, but triggers do even more so, so there should be something there * Handling attachments well * Global directory across organizations (FB/LinkedIn/etc. integration could help a lot) * Multi-user mailboxes; you need some kind of ticketing/tagging/CRM on top of it, and these are all standalone, sometimes web based, and fairly universally suck. There are ways to tie them into plain email though.

Re:Re-Designing the classic email client by dools on Tuesday July 10, 2012 @08:41PM (#4227113)
I comfortably ignore any comments about email and what it should be from anyone who hasn't used a text email client (well configured) like mutt, mh, elm, or an emacs mode for at least 100 hours.

I comfortably ignore anyone that says "email needs to be fixed" from clients to the underlying system - it's awesome and nothing about it needs to change. People just need to learn to use it better.

I run everything through gmail, but I use my own domain (via an external SMTP server), so if gmail goes down I can just route mail directly to another machine.

I use fetchmail to POP everything off from gmail and I read that in pine. It gets everything regardless of filters, except spam.

My android synchs with gmail (obviously) and using the gmail app I can send as my "real" email address (and this scales obviously so I can send as any of a number of addresses I need to). I make heavy use of filters so I only get relevant stuff on my phone.

My daily ritual is to sit down at pine and scan non-vital email (such as newsletters and mailing lists etc.) that I didn't get on my phone because I filter stuff so heavily, then for each email apply the "GTD" approach of doing anything that can be done immediately, or forwarding it to a Basecamp todo list (using mailmanagr.com) or a Highrise task (depending on whether it's sales related or actual work that I have to do).

This generally takes me less than 30 minutes and is a great triage exercise.

Instead of teaching kids how to code in schools, let's start by teaching them how to use email! We used to learn how to write letters, why aren't we doing advanced email training in schools?

Re:Re-Designing the classic email client by drivingmenuts on Tuesday July 10, 2012 @10:27PM (#4227411)
Which part of email requires advanced training? The writing - covered by grammar, etc. The thinking - covered by critical thinking.

The spectacularly complex system you have set up to filter your email? That would be worth a semester or so. It's worth it for you, I'm sure, but the average person probably would collapse trying to set that up.

Re:Re-Designing the classic email client by dools on Wednesday July 11, 2012 @02:57AM (#4228121)
Which part of email requires advanced training?

Primarily subject line usage and interleaved replies.

The spectacularly complex system you have set up to filter your email

It's basically just GTD on steroids. Basecamp and Highrise are used by millions of non-technical people. Reading email in a text based email client isn't rocket science and, I think, would be a skill on par with learning to communicate with letters. Also gmail filters aren't advanced, and Android is pretty mainstream (as is gmail). The only tricky bits there are using an external SMTP server (made simpler through things like Mailgun, Sendgrid and JangoSMTP) and configuring fetchmail to POP from gmail.

The rest of the components are all very simple and readily available. In my experience people are able to cope with seemingly overwhelming complexity as long as they were instrumental in it's creation and the bits that make up the complex whole are themselves quite simple.

Re:Re-Designing the classic email client by drivingmenuts on Wednesday July 11, 2012 @02:46PM (#4230710)
I would be interested (in an academic sense) of seeing documentation on the process you've set up and how you tied it together.

I use a far simpler method, akin to a pile.

Re:Re-Designing the classic email client by dredmorbius on Tuesday July 10, 2012 @03:00PM (#4225509)
If I can expand on your "HTML mail from idiots" -- HTML mail from non-idiots is pretty much a non-issue. A textual document with minimal markup renders well in a standard console email client. It's when an idiot sends you a highly-formatted email which is all-but-unreadable as straight text, that you've got issues.

I'll add: the same highly-formatted emails are very likely to break horribly on handheld devices as well, which are pretty much limited to presenting a small amount of information with minimal formatting -- normal, italic, bold, and possibly some colored text.

And dittos on K9Mail.

For IMAP: offlineimap seems to be a good solution (though not so much on mobile).

Directories: really should be a solved problem by now. I still find myself generally maintaining my own .mail-aliases list though.

Re:Re-Designing the classic email client by saurik on Tuesday July 10, 2012 @04:22PM (#4225941)
I also "love" when I receive "thank you for registering, click here to login", and after staring at the e-mail for a bit, seeing no links anywhere at all, I realize that the well-meaning-but-sadly-still-full-of-fail website operator that sent the message went to the trouble of providing a multipart/alternative with a text/plain body part, but implemented it as "strip the tags from the text/html part: that should be good enough".
Re:Re-Designing the classic email client by dredmorbius on Tuesday July 10, 2012 @04:33PM (#4226004)
I have NO idea of what you're talking about ;-)
Re:Re-Designing the classic email client by gcr on Tuesday July 10, 2012 @11:10PM (#4227544)
Let's pretend you're sending messages to your new users who have just clicked the "Sign Up" button on your fancy landing page.

The problem? They, along with a significant percentage of your other users, use text-based email clients.

This is the wrong way of sending text-only email:

    <!DOCTYPE html> <html> <head> <title>Thanks for signing up!</title> </head> <body><h1>Thanks for signing up!</h1>Click <a href="http://new-registrants.sneakystartup.net/>here</a> to finish your registration. </body> </html>
Stripping HTML tags is also wrong:

    Thanks for signing up!
    Click here to finish your registration.
This is the correct way of sending text-only email:

    Thanks for signing up!
    ======================
    Click here[1] to finish your registration.
    
    1: http://new-registrants.sneakystartup.net
Re:Re-Designing the classic email client by saurik on Wednesday July 11, 2012 @01:24AM (#4227856)
(FWIW, I took the emphasis and subsequent wonkier smily to mean he was joking, and in fact have accidentally sent such emails in the past from his own website.)
Re:Re-Designing the classic email client by dredmorbius on Wednesday July 11, 2012 @02:05AM (#4227987)
Indeed I was.
Re:Re-Designing the classic email client by mnutt on Wednesday July 11, 2012 @12:17AM (#4227703)
And most likely you only have a handful of these templates, so if you're nice you'll actually just put some effort into each one:

    Thanks for signing up!
    ======================
    Click here to finish your registration:

    http://new-registrants.sneakystartup.net
(it's much less egregious here than it is in some emails that have 7-8 footnotes)
Re:Re-Designing the classic email client by glodime on Tuesday July 10, 2012 @01:07PM (#4224863)
I just learned about imapsync, imapcopy, OfflineIMAP and Archivemail on linux. I haven't test them out yet. Have you tried any of these utilities? They seem to address the "Syncing on multiple machines" bit of your post.
Re:Re-Designing the classic email client by rdl on Tuesday July 10, 2012 @01:33PM (#4225022)
I use mbsync (http://isync.sourceforge.net/mbsync.html) and mutt. The thing I hate is that Mutt's native OfflineIMAP support is broken, forcing me to use an external maildir syncer, but other than that, it works great. I still haven't set up search.
Re:Re-Designing the classic email client by sliverstorm on Tuesday July 10, 2012 @09:28PM (#4227239)
Global directory across organizations

It sounds like a good idea- I used to think so, myself- but I've steadily been convinced otherwise by the (quite sharp) IT guys managing our directory.

Re:Re-Designing the classic email client by rdl on Tuesday July 10, 2012 @09:33PM (#4227252)
You don't want to give unlimited access, but once someone authorizes an individual as a contact, the contact should be kept up to date automatically if a phone number or email address changes.

(Also, partner organizations might want to share directories easily; I can see giving a full access to your directory to a contracting/temp agency you use, rather than giving them accounts. I'm sure there are better examples.)

Re:Re-Designing the classic email client by a3_nm on Tuesday July 10, 2012 @07:00PM (#4226716)
* Full text search and tagging. (Hence, http://notmuchmail.org/)