Slashdot Mirror
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
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.
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.
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.
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!
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
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.
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.
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).
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.