Elizabeth Churchill was kind enough to send this link: (01)
> http://www.research.ibm.com/remail/index.html
> (02)
Which Eric then reviewed, somewhat brutally, below...
---------------------------------------------------
Hmmm. They're tackling some interesting problems, but
I'm not sure they're the *key* problems. Their intro
starts out saying that "pressure to respond quickly"
and "lots of stuff" are the problems they're trying to
solve. But those are general overload issues, rather
than issues that are central to the collaboration
process. (03)
In other respects, they have some good ideas, but the
the quality of the implementation really determines
how useful the results will be: (04)
* Integration of email, calendar, and chat
The screenshots are blurred and too small to read,
and don't link to larger versions, so it's difficult
to know how things work. The calendar might be
useful -- or it might not. I'm not sure how useful
an integrated chat system really is, but it might be. (05)
* Date dividers
Visual separators showing the day and date, with
only the time showing up in the inbox are great.
It really looks nice -- as long as the messages
are sorted by date. But what happens in a threaded
view? (06)
* Threaded view -- sort of.
There is a "threaded" view, but it's some sort of
list with rollover windows and some weird graphic
with dots and arcs that looks good for 5 messages,
but will die quickly when there are 30 or 40 messages
in a thread. This is pretty unimpressive. (07)
* Marking messages with different colors
That *sounds* like a good idea. But MS outlook found
that's it's easily possible to screw it up. NS and
Mozilla have a single "flag" column. You click in it,
and that's it. Simple. Easy. Useful. Outlook had a
right-click submenu to choose the kind of flag you
wanted. A disaster. Right click, choose menu item,
choose submenu item -- three steps to carry out an
exceedingly simple operation that you do a *lot*.
A single flag that means different things depending
on the message you apply it to is infinitely better. (08)
* Collections
Looks like a useful facility that lets you categorize
messages and view them in a collection. Most importantly,
a message can belong to multiple collections. Very nice. (09)
* Integration
Supposed to support RSS feeds as well email, and NNTP
discussions. May work in practice. Not sure. (My email
client supports NNTP discussions, but I rarely if ever
participate. Somehow, they just don't work for me.
Integrating an RSS feed may be useful, though.) (010)
* Calendar
Could be useful. But I'm finding that a calendar I keep
in my pocket is the most valuable for my appointments,
plus a huge calendar on the wall for deadlines. I put
the deadlines up with post-its, so I can change them,
and see how far away from my next deadline at a glance.
When it comes to calendars and todo lists, I've come
full-circle from fully automated to totally non-automated.
But again, this more a PIM issue than a collaboration issue. (011)
* Visualization Tools
These look like very interesting, amusing, and essentially
useless bits of fluff, to me. I love good graphics, but
the three different kinds of visualization tools they've
come up with just don't seem to have any real utility that
I can discern. Someone once pointed out that graphic displays
work great in demos, with a small number of nodes, but that
they rapidly fail to scale. Since hearing that, I've observed
it to be true. But your mileage may vary, if you're more
graphically inclined. (012)
Conclusion
----------
The project appears to be tackling "the problems of email",
totally within the context of an email system. It does not
appear to be addressing the vastly greater potential of
"interesting problems (especially collaboration problems)
that can be addressed using exceptionally capable email
clients". (013)
For an inkling of those capabilities, see:
http://collab.blueoxen.net/forums/yak/2003-11/msg00018.html
A tremendously concise summary of the major issues,
authored by Tom Munneke. (014)
http://www.eekim.com/cgi-bin/wiki.pl?ProblemsWithEmail
http://www.eekim.com/cgi-bin/wiki.pl?Abelard
A deeper analysis and a prospective alternative, by Eugene Kim. (015)
http://www.treelight.com/software/collaboration/whatsWrongWithEmail.html
http://www.treelight.com/software/collaboration/requirements.html
http://www.treelight.com/software/collaboration/SimpleSystem.html
http://www.treelight.com/software/collaboration/KnowledgeRepositories.html
A lengthy review, plus requirements analysis and proposals
for alternatives, by Eric Armstrong. (016)
John Sechrest also found these links, which I rediscovered when
looking for the items above, and which I have yet to review: (017)
http://domino.watson.ibm.com/cambridge/research.nsf/0/b5ab62165addd0ed85256c690070a2c8/$FILE/TR2002-10.pdf
"Email as a habitat" (018)
http://www.ai.mit.edu/people/dfhuynh/p345-bellotti.pdf
"Taking email to task: The design and evaluation of a task management
centered email tool" (019)
http://csdl.computer.org/comp/proceedings/hicss/1998/8245/00/82450044abs.htm
"CAFE: a Conceptual Model for Managing Information in Electronic Mail" (020)
--
This message is archived at: (021)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=3FD7DB34.60801@sun.com (022)
|