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."
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.
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.
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.
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.
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.
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.
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.