How to Build an Email Client
levinianconstant.tumblr.com
levinianconstant.tumblr.com
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.
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.
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.
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.
Stick with us...
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...
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.
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.
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).
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?
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.
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.
I do that. Saves hassle of accidentally sending half finished emails.
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.
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.
[Disclaimer: I'm a co-founder]
[Send to: John Blabb, Mary Jones]
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.
Anybody encounter this problem? It's very annoying.
And a good reminder why I don't let third party access my Gmail inbox :-(
https://chrome.google.com/webstore/detail/checker-plus-for-g...