The Perfect Email Client?
An anonymous reader sends: "Can those who review also design? Trying to practice what it preaches, CNET published this article, a description of the perfect e-mail client. Next up, apparently: hardware and electronics designs."
for me the bat (www.ritlabs.com) comes close, now if oly they did a version for freebsd, even linux would do)
dave
Is one who doesn't call every few days because they "can't get their email" It doesn't give any error messages they say, they just can't get it. Have them open up OE, and low and behold, a box asking for a username and password. At this point they SWEAR they don't have a password. After you explain that you MUST have a password, then they start with the "I don't know it" routine. I swear, its not worth it.
Auto response when you're away? Great! One e-mail, and I know that I have five hours to clean out your home office...
Hank! White!
The other points here are a checklist for current open source email clients (Evolution, KMail, Mozilla Mail, etc) - many of the features are already integrated of course. It is just Outlook that is lacking, and it will remain lacking because Microsoft take ages to upgrade software, and then only add features they think the user needs, not what the user actually needs.
One thing I hear a lot about is the Amiga email program YAM as being extremely good. It is open source as well - a Unix port would be interesting.
This reminds me a ton of when Homer was hired by his brother to design the ultimate car, the "car of the common man". Ugh. :-)
Josh Woodward
I've been planning an email system that is based on searches rather than folders. The user interface might be "folders" but in reality, each "folder" is actually a search into an email database. This means a number of things. First of all, emails can exist in any number of folders (including no folder at all). Folders can have all kinds of "complex" rules such as "unread emails plus emails that have been read within the last 10 minutes". This would be a kind of "inbox", for example. Then there could be "Today's emails". "Yesterday's emails", "Emails from Firstname Lastname", "Work related email" and so on. Emails can be flagged using filters to help categorizing them. For example you could have a folder "work emails" that simply search for all emails that have a "work" flag set. The work flag would be set when the email arrives by checking if the email matches a set of rules (is from certain people, is to a certain email address, has a certain topic etc.).
The basic idea is to get powerful email management without having to actually manage "at runtime". Instead, the management happens by setting up folders and rules.
One implementation idea is to implement it as an IMAP server that one would run locally. That would allow people to use existing email clients with this system. I haven't decided about that yet though.
like asking for bloatware if you ask me. Like somebody once said, a tool should do one thing and do that one thing well.
I dunno, just my thought.
We are the music makers. We are the dreamers of the dreams.
I think they've done a pretty good job, actually. I particularly like the integrated encryption and spam-reporting tools. These are widely asked for by those in the business, and yet no mainstream e-mail client seems to provide them. I'm sure more people would use them if they were easily available, rather than something you have to fight for. For example, there is a helpful service for spam complaints, who amongst other things will forward the details to the relevant abuse address, but how many people know that, or where to find it?
That said, I'd settle for just having the colour-coded "new mail" icon with the ability to hover over it and see the sender/title. At the office, where we use Outlook/Exchange Server, one of our guys tried to write a tool that hooked into Outlook and did that a while back. Unfortunately, he found insurmountable problems with the way Outlook's automation and new mail reporting features work. Too bad, as the rest of us were looking forward to him finishing it! That alone, to me, would be a major improvement. Here's hoping some of the guys at MS read the article!
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Eudora would be a great email client, if it weren't for a few things. ..won't work." Ok, is it a bad password, bad server naming convention, or a dozen others. I've seen it do this when I know my net connection is down, so its like, WTF!
1. I don't believe it is out for Linux
2. Wierd ass server naming conventiongs. Your server name is usually like, mail.myrealbox.com in netscape, Yet in Eudora it ends up being, Username@imap.myrealbox.com, and sometimes that even doesn't work, its strange.
3. Buggy as crap, and doesn't like alot of servers from what I can figure
4. Ok, joke error messages are funny, if you know what they are supposed to mean. "I sent the password to the server, and said, shhhh, don't tell anyone, and the server said....shhhh....this
Good stuff
1. multiple email boxes/servers/usernames
2. Easy to set rules
3. easy interface
4. tech support is disant from the one time I used it.
5. the only problems with the free one is that there are adds on the bottom left, very small noninvasive adds.
6. you can do cool crap like not only mark an email as read, but mark it with 10 different colors, so you can seperate them between clients/problems or etc.
Some just show that these people do not understand UI design (all powerful right-click. Yup, nice idea, but when you say how many options there are in modern clients, I wonder how you expect them all to fit in a context menu? As an example they give 'send all mail from this user to folder x' Well great, but to be all powerful they also need 'block email from this user','automatically reply to this user with x', direct all email with this subject to x' etc. all in the context menu)
Overall, a couple of nice ideas, a couple of dumb ideas, and a rehash of some oft-mentioned ideas. Hardly anything groundbreaking.
Some spammers put in an image tag that includes the email address, or encoded email address as part of the image request string so that they know it has been opened. That way, they can verify the address.
Fight Spammers!
I think you're being overly negative. OK, I agree that I'd probably turn off the majority of features. I don't use most features in most of the other packages I use, either. But as long as there's an easy option to switch off the bits you don't want and the UI isn't forced upon you, the features they suggest would help many people and inconvenience no-one, AFAICS.
As for things like PGP -- yes, maybe they are obvious, but apparently not so much so that mainstream e-mail clients already do it, eh? This article doesn't seem intended to provide leading edge research, it's a summary of the state of play, and where they think improvements could be made. In most cases, I think they're right. Putting them down because they don't have ten new improvements (and they didn't ignore good features just because someone's mentioned them before) hardly seems fair.
No, most of it wasn't groundbreaking, but I don't think it was meant to be. It was a wish list, a summary of some missing features they'd like to see incorporated into e-mail clients, and a pretty good one, IMHO.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
As for autoresponders, they shouldn't be in the client unless that client (a) has access to envelope information, and (b) can send things as error messages (null envelope from). I also have rant about broken autoresponders.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
There are three major points for my perfect email client:
1. Look and feel the same in X and console, so that I could make use of both xpdf/mozilla and remote mail reading.
2. Localization. Being non-native english speaker, this one is pretty important.
3. Keyboard navigation
For the last 4 years I am extremely satisfied with the combination:
- fetchmail (getting mail)
- procmail (sorting mail into mailboxes)
- mutt (reading/replying)
- vim (editing)
When it comes down to analyze mailbox and generate some reports, like for example, in the case with antivirus reports, I use perl with Mail::MboxParser module.
For all my friends, who need GUI to read email, I recommend using Mozilla and or Evolution
Leonid Mamtchenkov
The proposed design is way too busy with too many features I'd turn off if I were using it. The ultimate e-mail client IMHO is one that does e-mail, only e-mail and does it well. The ultimate e-mail client needs to:
1/ Support *all* inbound e-mail standards, pop, apop, pop over ssl, imap, imap over ssl, MicroSoft exchange (I don't want to run Outbreak^h^h^h^h^hlook), etc. I don't want to change e-mail clients to match up with whatever e-mail server is in use where I am working.
2/ Support *all* outbound e-mail standards, smtp *and* the various authenticated smtp methods. Security matters.
3/ Deal with *all* content standards, MIME, HTML, etc. and provied fine control over how they are viewed (e.g. no html, html without downloading images, etc.)
4/ Supports crypography (GPG, S/MIME, etc).
5/ Message filters. Filter inbound mail, filter on demand, etc. Filter on any header or other part of the message. Filter using external programs like spamassassin, etc.
6/ A Clean UI. No oversized cute buttons, etc. Let me decide where to put the list of my folders, messages in a folder, etc.
An example of an e-mail client that's close to ideal for me is KDE's Kmail.
When some moron sends me dual-encoded HTML/text mail, let me prefer to show the text version. If they sent HTML-only mail, convert it to text. I never want to see HTML. Ever!
I am sick of getting HTML spam that automatically starts banging on my net connection, even before I get chance to blacklist the appropriate site through Junkbuster.
(And no, I don't want to use a text-mode client. That's throwing the baby out with the bath water.)
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
Threading and scoring.
I don't know how I'd get through my mailbox without mutt threading and scoring things for me. I don't want things just dumped in another mailbox...I want my mail scored so that it has a priority meaningful to me. Threads clear up the view considerably.
I'm still trying to get Cygwin and mutt to work with my mail system, but no luck yet.
The Bat (previously mentioned) DOES have threading, so it's part way there. Pretty decent for a fairly cheap client.
Anyone I've ever recieved more than N messages from, make a folder for me, and setup the filters to automaticly put messages from that person into that folder.
Also put symbolic links to any messages I've ever sent that person (or list) into that folder.
Why do I say put links?
Ever write a message to multiple friends and you have no idea which folder the message was filtered into? It's either in some random folder for whichever filter was first, or worse there are multiple copies of the message in each persons folder.
I want it all to be automatic, so automatic that magicly my mother's 500+ message InBox is suddenly cleaned up as a series of neat and clear folders.
If it's not automatic, 99% of users (like those who never program their VCR) will never use filters for folders. At most I see people using folders manually. It needs to be all automatic!!
I'd also like all my messages stored as plain text, one file per message, one directory for each folder (like PMMail except use better filenames). I want my mail to be indestructable, and not tied up in anyones database format. Screw mbox or worse the encrypted junk in Outlook. Let the OS do the work! Then I can search for messages, move messages between folders, do all sorts of cool stuff directly to the message base.
Maildrop may be a reasonable replacement to the procmail part, since procmail's rather messy and has a filter language that would make Larry Wall blush.
Lasers Controlled Games!
I agree, Sylpheed is a supeorior client, pretty much like what balsa would be like if balsa wasn't buggy as hell, and wasn't trying to be a eudora clone and failing.
I havn't tried the Claws add on for Sylpheed yet, but I hear it's good if you like that sort of thing.
The one thing Sylpheed is missing is return reciept. Return reciept may not be something geeks often use, but users at work like to use it a lot, and it's not complicated to implement.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
I am surprised to not see Mulberry suggested. It's one of the few email clients (if not the only email client) specifically designed from the ground up for use with IMAP. It's fast, reliable. It doesn't fully support HTML mail (a good thing). It has versions for almost every platform - Win, Mac OS 9, Mac OS X, Linux, Solaris.
I've been using Mulberry for a year and a half now, and there is no way I would go back to Exchange or Eudora (whose crappy behavior started me looking for an alternative).
Forget Outlook. If rules are what you are after, and scoring, and colouring, sylpheed-claws is the answer. These features may end up in the main sylpheed, as well.
Well if you don't want anyone to give you alternatives what do you want? Should we just say "use outlook and enjoy it, dammit!"?
Can outlook use IMAP servers? Can it see folders in an IMAP box? If so you can send the mail to to a Linux box have it autofile it, serve it up via IMAP. Then you can use whatever client you want...which is apparently only outlook :-)
P.S. is it just me or is this article all about craming a bunch of stuff into a mail reader that doesn't belong? I would much rather have a bunch of applications that work together then on big one, too hard to replace the big one. With a bunch of little apps I could replace the "to do" part with one that works better with my PDA, or that has repeating items or just look better without having to find the better todo stuff in an app that does all that other crap too! Maybe this is why people like giant bloated software, and leave me puzzled?
(the Apple mail app is a little like that, it leaves the "address book" stuff up to another application; still too integrated for my taste...MH anyone?)
Here's one!. Maybe a little long on design and short on implementation, but overall sounds like a good idea to me.
I think there is a world market for maybe five personal web logs.
A long while ago (pre-win2k), I used a little program called Becky! (official site here), a shareware Windows email client. It has the best interface I've seen yet. ...however, it doesn't get updates frequently and it's primary language is Japanese. Oh, and it's not free beer let alone free speech.
...and you can't beat Pine for remote access (unless you're a fan of webmail, and even then you're hard pressed for something free).
I'm currently using Pine for receiving and Mozilla for sending. Once I get an IMAP server up on my linux box, I'll use Mozilla for mail at home and Pine for remote. Personally, I think this is the optimal solution; with your own personal IMAP server, you NEVER have to worry about switching email clients and converting everything.
Use my userscript to add story images to Slashdot. There's no going back.
Of course not.
Well, I guess if it really was one of those 'of course' things, I wouldn't be responding, would I? :-)
Users know only one thing. "I want this." This doesn't just apply to software, it applies to any industry, from cars, services, whatever. Users only know what they want, and they typically want the stupidest stuff.
It takes people who understand the problem domain and the issues involved to actually make solutions work. This is why joe-6-pack doesn't make solutions. When they do, they make Homer's Car.
They've committed several 'crimes' on their wishlist. The most prominent is that they used Outlook as a launching point. Good god. Outlook shouldn't be a launching point for anything, especially a Dream Email-PIM system.
Besides that (I'll admit that I've got several grudges with Outlook), they've ignored problems with scalability and configurability. It's easy to dictate "I want this here, and it should do this," but it's much harder to decide how it's supposed to adapt to varying amounts of data and user workflows. The split email view is bad on so many counts- it makes showing subjects and dates harder, and what if you have 5 email accounts (such as I do) that you need to monitor? It just doesn't work. You need a better solution.
And there's the whole issue of feature bloat. I'd say reviewers are fairly savvy with the software they use (if not, they don't deserve their job). But a new users (and many not-so-new users; basically whenever anyone encounters something outside of their knowledge domain, which anything that they're not used to working on) have to take a blind eye to 90% of the features of feature-bloated software. It's information overload; so much that the new user doesn't know where to start, or what half of those things are useful for.
It's just the 90/10 rule; 90% of the work is done by 10% of the code- or interface. Don't put the rest of the 90% of the interface up front, it's just not useful.
For people born and bread on Microsoft Office, it would be hard to picture another way of working. But it's not for those people to decide; it's up to the user interface designers to make those decisions and come up with appropriate solutions.
That's the most important factor when writing software. Most programmers and managers (and reviewers) completely miss that fact, and we all end up working with complicated (== $$ on training), inefficient (== $$ on time), feature-rich software designs (== $$ for MS and people who support it, like that NT sys admin at work you love so much) that don't help the user.
UI designers exist for a good reason. Good ones understand their problem domain better than anyone else, and are best suited to make solutions for it. To get anyone else to do the job is akin to putting non-tech people in charge of digital copyright laws. It just doesn't make sense.
Moderators should have to take a reading comprehension test.
That almost happened. When I worked there, I was bugging them to port Eudora to Linux. (I've been a Linux user for a long time, and essentially had to use Windows since I had to use Eudora.) Well, one day a PHB type (sorry, John...) comes into my office and says "We'd like to talk about what it would take to get Eudora working on Linux." w00t!
So I go searching for someone to do the port. Among my searches, I would up talking to Loki Software. The Linux game company that just went joysticks up. So I brought them in (they were in Tustin, QCOM was in San Diego, so it was a easy thing). We had them sign NDA's, the works. Scott Draeker came, as did two other geeks. I had fun talking to them. Way smart people. One of them was a GNOME user, the other KDE. I got them going on that. Kind of a troll, but I needed an ice-breaker. :-)
Anyway, I burnt a CD with Mac and Win Eudora source and gave it to them. They looked at both and said that the Windows source could be ported in like 3 months. I was a happy camper.
Then, doom. Money got weird. The ads were selling, but there were internal QCOM politics. I can't go into it, but if I had talked to Loki three, four months previous, there likely would have been a Linux Eudora Pro. And Loki might still be in business (since we were going to pay them a boatload of money). And I would have been happy. But now I make do with Pine and Kmail.
This is all an interesting story, actually. I should write it up one day. I still have friends at Qualcomm, though, so I'll have to wait.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.