Re: "CNET imagines the perfect e-mail client" - can Emacs be it?

[(Chris Beggy ) news@kippona.com]

Ken Raeburn <raeburn@raeburn.org> writes:

> Well, they certainly aren't targeting UNIX computer geeks who enjoy
> spending hours fiddling with their tools to get them to do exactly
> what they want (or anything remotely close to it), who don't mind huge
> sets of key bindings that take forever to learn, and who like figuring
> out for themselves how to get different tools to work together, no.
> But I don't think Emacs should target them exclusively, either.

I understand your point.

Don't underestimate, though,  the time and money corporations spend when
they adopt a new email or PIM client.  People will typically go
to a 4-8 hour training class in a short window before or after the
rollout.  The MS UI and feature sets cannot be understood by
*most* people without taking time to learn.  
 
I wouldn't be surprised if in the future insurance companies give
a discount on rates to companies that pull the mice off
the machines, and have *exclusively* keystroke controlled
software.  This would reduce RSI.

Sure, emacs without any training is impossible, but given its
feature set, maybe with color-themes, emacro and training it's
attractive.

I think what is outstanding is that emacs has many of the
features *today* that those authors would like to see *tomorrow*.

> I think a bunch of the specific visual details are beside the point,
> and as Gnus developers we can ignore the standalone PIM stuff, but

But PIM is rarely standalone in new email/notes/collaboration
systems now.  The target, as the article mentions, is to
integrate them.  Emacs has this capability, in the scenario
of emacs + gnus + bbdb with private newsgroups on a collaboration
server running inn.

> some of the general ideas may be useful.  Template responses to email
> (basically form letters) are a good idea (maybe not for me, but for
> some people).  New email notification slightly more discriminating

Many of us are using skeletons now, and maybe some have bbdb
hooked into that use, but I don't yet.

> than "you have mail".  A simple UI for "always file this email address
> [or subject] in folder X" rather than pulling up an editor on a text

emacs + Mew can do this without *any* UI right now.  I bet the
creation of splitting rules for gnus will improve with time, too.
Mew also automatically verifies pgp keys and snarfs new ones,
which is a feature on the CNET wishlist.  I think some folks are
using a bbdb field to set the email correspondence privacy level
on a person by person basis, too.

> buffer in some obscure (to Mom) format.  Displaying contact info from
> BBDB when the user moves the mouse over an email address.  Putting

Emacs + bbdb doesn't have mouseover, but maybe these CNET authors
need to see the behavior of (setq bbdb-view-pop-up t), which is
quite similar.

> "reply to message X" in your to-do list to come back to later.

Maybe someone has done this with a mail client and the to-do
function in bbdb-records.  I do a similar contact management
function with mew + bbdb + records using a special field in
the bbdb record rather than the records-mode record.

I also use emacs to dial voice calls to respond to email I'm
reading.

> Some random writers at CNET are
> probably just as good at the "user friendly" side of it as many of us
> are, if not better.

I think it was a good article, and a kind of requirements
document for a mail client.  I didn't quite understand their
vision for document sharing though.  Did anyone else?

Some unanswered questions I have are about IM and emacs, and if
anyone is using it in emacs the way those authors have
described.  The article doesn't mention ldap, but that will be a
more common way to recognize people in the email client, and I
know we have eudc.  

Chris