In terms of managing IMAP connections, async is definitely the way to go. For our product, lightermail.com, I ported Python's imaplib to run on Tornado's ioloop (adding a few features like IDLE support and command pipelining). Not only can you manage a lot of connections with little memory, but you can do some really cool things (like the pipelining of commands mentioned above) that are unavailable to regular synchronous IMAP clients. Plan to open source the implementation when I have a bit more time.
This is awesome! Please do open source it! I looked into doing this once before for ioloop, but ended up implementing IDLE with Twisted's twisted.mail.imap4.IMAP4Client instead. The results were fairly good, but I don't think it was worth the trouble finding the right timeouts, etc.
Also, not sure if it makes sense for your use case, but I considered moving to Postmark's Inbound API (http://postmarkapp.com/inbound). May work well for some people.
Sounds awesome. Just yesterday I was trying to hack pipelining support into imaplib, ultimately for use with Tornado. I'd be very interested in your implementation.
Thanks! I'll be sure to make a show HN or something when I do. I still need to add in support for compression, but it's not high on my todo list and I'm sure the community could help.
Very recently I built a little desktop email client. It was...interesting. And hoary. And fraught. Very interesting though, I think everyone should have a crack at writing a basic SMTP library at some stage just so they appreciate the benevolence of anyone happy enough to sit and go through RFC guidelines.
Node seems like a far better choice for the project than Rails, no hate for RoR from me but Node is pretty much designed for the way email needs to operate.
Depends on what you are comparing it to. LDAP stands for Lightweight Directory Access Protocol. I don't think that anyone would consider LDAP lightweight, but compared to X.509...
Definitely agree with you that the benevolent few who produce FOSS deserve admiration especially when wrestling with the esoteric aspects of POP, IMAP and SMTP.
No doubt, I was thankfully using mostly FOSS components but I rolled my own SMTP solution a while back and it was hard to get right, especially dealing with how the format deals with multipart etc.
Just installed the plugin, but it was a bit of a disappointment and I just uninstalled it again. The plugin was able to recognize exactly two brands: Google and Google+. Wut?
I'm sure it takes a lot of time and dedication to developing the plugin, and I enjoyed reading the article, but this is not what I was expecting to see.
What would be useful to me though is a list of the top X e-mail contacts I received e-mail from and sent e-mail to the last Y days. I regularly have contact with several people from the same company/brand, and I always are using the search bar on top like: "John Doe something I remembered from the specific e-mail I'm looking for".
So basically I'm not that interested in mails I received from a brand, but I'm more interested in e-mails I received from a specific person.
Gamification would be awesome candy: statistics and graphs on how fast I'm responding to e-mails I receive, etc.
I actually tried these guys out earlier this year when the main product was a full email-client, but just couldn't make myself move away from gmail. But so far, I am finding myself really liking the new gmail plugin/toolbar. It's recognized about maybe two dozen brands. Will definitely give it a whirl for a few more days.
But I do agree that it would be great if it also worked for personal email contacts + some form of analytics/gamification. And I also wish it allowed me to group brands together (e.g., so that I can read the various sales newsletters I get once a week in a fire-and-forget kind of way as opposed to having them crowd out my inbox).
I do think that there's a ton of room for innovation in the email client. It makes me sad how slow gmail has gotten over time, and I do think there's a ton of room for more automation, assistance, auto-categorization, etc.
jorgen - we identify brands for the past 30 days, so if you're an inbox zero person, then you won't have many brands to identify
our first product allowed you to create personal and brand icons - we're not there yet with this one. we hacked it together after going down the stand-alone client path for almost a year
I could write about that experience for days (for all you folks dead set on building a new client)
You can actually use Gmail's native features to hack our product to make it more powerful - i'll be posting about that next week...we also plan to gamify. So much to do, so little time.
Thanks for your response. I was just trying to explain why I didn't like it so far, and what I'd love to see. Good to hear you guys are moving forward and implementing new features.
I don't think people would like to create brand icons manually. If I get a lot of e-mails from john.doe@ah.nl, why not running a separate Node.js instance trying to locate the favicon (and using it to display the logo) by trying known locations, or parsing the HTML; http://ah.nl/favicon.ico
The name of the brand might be easy to fetch by doing a WHOIS lookup. Just a thought...
Building an email client is one of those fun projects you can play with and learn a lot about how the internet works at the same time. Like most cool projects, you can either stop with a little functionality or keep going into all kinds of other stuff.
Telnet clients are also fun. I haven't written an http client, but looking at the state of web programming, I imagine that is a whole nother can of worms. I think I'd rather go for a root canal.
Whatever you do when you build your client, do me one UI favor: Reverse the fields when composing. Body, then subject, then addressees, then the Send button. Think of all the headaches due to accidentally-sent mails the world over.
No, please don't, here is one voice against "let's do it totally different for idiots". Next you want to have 3 confirmation dialogs "do you really want to send" followed by "did you prove-read your mail again?" followed by "you clicked YES too fast, go back to start and prove-read again".
Also, worst thing you actually can do is to put the save/send/ok button on the bottom when all other UI elements are on the top of the UI (which is usually the case in mail clients).
I don't think slippery-slope is an appropriate argument to make here, or really anywhere.
To answer the UI elements on the bottom, I'm not sure I actually press the Send button at all, instead opting for a keystroke depending on the client. The physical analogue I base my request off is the order I fill out a letter or card--I write my message, then I sign it, and then I seal and address the envelope.
Beside that, what's to keep a hypothetical upside-down mail client from putting all of its control elements on the bottom of its interface?
First of all, i bet you that much more users click on a send button then press some arbitrary key combination.
Second i bet you that most people find the send button easier when it's somewhere they expect. Where the other buttons are.
Third, physical analog bla bla, really... Nobody thinks "hey i am writing an e-mail, that's just like real mail, EXCEPT i write on a keyboard, look on a screen and everything else i touch and see is not a physical letter or pen or paper at all!".
The real-world vs virtual-world comparison makes most sense for icons and such, in my oppinion. Not so much for workflows. You also don't ask people to walk to a virtual post box to send the letter. Or let them "stamp" it. Or as you said yourself, to sign it or to seal it.
Nothing keeps one from putting ALL controls to the bottom, a good interface may even accomplish that nicely. Except that it's only there to annoy people, restrain adoption and giving users a hard time figuring that out. You may be able to quickly learn that, i may be able to do that. My mother or grandmother? Not so much.
It'd be very interesting to see some A/B testing on this. Maybe i'm wrong, who knows.
It is weird to ask for the subject of an email before writing an email.
I'm sure I'm not the only person who has change (or left blank to begin with) the subject once I've written the email.
Also I've observed a lot of people who write the content first then fill out the top (To, CC, BCC) after. Often the content effects who should/can see the email.
The current UX is wrong given mis-sending, mis-addressing still occurs.
That's why i said A/B testing would be nice.
Because now i can tell you exactly the oposite of what you tell me.
I have 18000 mails in my work mail account (no spam amongst them, mostly "real" mail), 43000 emails in my gmail account (which is not even that old) and not a single mail with half-written content or whatever. This includes mails by extremely tech-unsavy people.
I also never did the mistake you mention myself, despite the UI so flawed.
And i've observed that most people start by adding the recipients first, then content, then subject and then maybe in the end they decide to add a CC.
So would a UI with To, then Content, then subject, then CC be better? Don't think so.
Also that interpretation of "the content effects who gets the mail" is REALLY flawed. It certainly effects if you add someone on CC, but not the person who you are talking to.
Atleast i know to whom i write a mail before i even open the mail editor. I also know to whom i want to write a letter before i write a letter. Maybe i am crazy or even psychic, knowing who i want to talk to beforehand :P
In the end i think your ideas try to solve a problem that does not really exist (not in my experience) or even if it exists that the disadvantage of confusing customers would outweight the minor percentage of people that would be helped by far.
I realise you've hit "someone is wrong on the internet" territory, and thus seem to be just ranting. But when you are telling me that peoples conceptual models of how to use email are flawed... you are losing credibility.
Computers should bend to people, not people to computers.
Quoting stats from your email accounts doesn't actually mean anything. You can't possibly make the claim you are making, only the sender knows if the email was 'finished' or not, not the receiver.
I didn't actually suggest any UI changes, only that existing UX (as in the experience) seems sub-optimal, because problems still occur.
1. Observe the continually evolving web standards of CSS and HTML.
2. Ignore them completely and build it based on Microsoft Office XML.
3. ???
4. ... probably not profit.
I installed the Chrome plug-in, played with it for a while and ended up uninstalling. The problem is that I now have extra labels called Brand and Personal that just won't go away. I deleted them, double checked that there were no filters left, and still, they come back.
Anybody encounter this problem? It's very annoying.
And a good reminder why I don't let third party access my Gmail inbox :-(
Chrome profiles are perfect for managing multiple accounts. I have one profile for each email account, and it works beautifully. The multiple sign in stuff never worked quite right for me.
