| |
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: st: Reading Statalist efficiently
On May 3, 2006, at 8:28 AM, Campbell, Richard T. wrote:
But Phil Schumm's message this AM refers to an email cliet "with a
good interface." I have used Eudora for years, and I suspect that
it doesn't meet Phil's requirements. But what does?
Sorry for that rather cryptic remark. I was thinking specifically of
the following features:
1) Filtering. This is perhaps the most important feature, as it
permits you to automatically direct mail from Statalist into its own,
dedicated folder. One of the biggest complaints people have about
mailing lists is that they can't handle all the messages -- filtering
solves this problem. Unless and until you look in the folder, it's
as though the messages from the list don't even exist. Of course,
it's nice if your mail client has a flexible and easy-to-use
interface for configuring your filtering rules, but if all you're
doing is setting up a single rule to handle the mail from Statalist,
it's not necessary.
2) Flexible notification. This is the one issue that (1) doesn't
address. Many people (perhaps even most?) have their mail client set
to notify them immediately (via a noise and/or visual indicator) when
new mail is received. This can work well for personal messages, but
when you are subscribed to a list with a lot of traffic, it can
become a real nuisance (i.e., if you're getting interrupted with
every new message from the list). Being able to exclude certain mail
(e.g., mail filtered to certain folders) from automatic notification
is very useful. Even better is to have a flexible notification
mechanism that offers different levels of notification so that, for
example, you can avoid being interrupted with new messages from
Statalist but can still, when you want, quickly determine how many
new (i.e., unread) messages are in your Statalist folder.
3) Threading. Ok, so now you've got a dedicated folder which
contains all of the mail from Statalist, and perhaps you've even been
able to avoid being interrupted as these messages have arrived.
Depending upon how long its been since you've last looked at the
folder (and how busy the list has been), you may have many new
messages to read through. I suspect most people keep their mail
folders sorted by date, and going through each new message in
chronological order is a good start. However, rather than having to
go through each individual message, it's much more efficient if you
can take one whole thread at a time, dismissing with a single
keystroke (or click) an entire thread that is not of interest.
Note that there are really two issues here. The first is the
procedure your client uses to determine which thread a message
belongs to, and where it falls in that thread. There are many ways
to do this. The best way is to use the In-Reply-To header, but the
problem with this is that some mail clients and commercial MTAs (read
MS Exchange) don't always respect this. Another way is to rely on
the Subject header, however parsing and matching these can be
difficult in cases (such as lists) where the subject header has been
automatically modified. Moreover, threading based on subject headers
alone cannot reconstruct the hierarchical structure of a thread
(i.e., which messages were sent in reply to which others). Good
algorithms use a combination of these methods, together with
additional information. Different mail clients offer different
levels of sophistication (and flexibility) in threading.
The second issue concerns how your mail client's interface permits
you to work with threads once they have been identified. For
example, in my client messages belonging to a single thread are
brought together into a single item, and if I select it, I get an
automatic summary of the entire thread (i.e., the main subject
header, how many messages are involved, and the From, Date, and
Subject headers of each message, in order). This permits me to
dispense with an entire thread in one keystroke if it is not of
interest, while at the same time permitting me to conduct a quick
visual check on whether all of the messages involved really belong to
that thread.
One final remark. In order for this to work properly, it is
important that Statalist members do the following:
- When starting a new thread, always use a clear and concise
Subject header
- Always use the "Reply" function in your mailer when responding
to a message
- Don't modify the Subject header when replying to a message
- Never hit "Reply" and then start a new thread
These guidelines are, I believe, already codified in the FAQ. By not
following them, people risk annoying others on the list (at best) or
having their message inadvertently ignored (at worst).
4) Searching. If you save all Statalist messages (and even if you
don't), being able to search through them quickly and efficiently is
invaluable. Many mailers (and even OSes) have made great strides in
this area recently; in my case (under OS X), I can perform
complicated searches of my entire Statalist folder from my Desktop
almost instantaneously, and can save a specific query as a dynamic
folder which is then automatically updated as new messages that meet
the criteria arrive (e.g., I have one such dynamic folder that
contains all postings by members of StataCorp). Note that in many
cases, it takes a bit of time and effort to learn how to use the
search facilities available to you most effectively.
5) Marking. Some time ago, someone on the list suggested that there
be a mechanism for identifying certain postings as particularly
"valuable" and collecting references to these in some web-accessible
location. The problem with this, however, is in determining which
messages should be flagged (i.e., who will do it and what criteria
will they use?). Note that if your mailer has a facility for
flagging messages (sometimes referred to as "marking" or "labeling"),
you can construct your own personal list (which would probably be
more useful to you than a list maintained by others). For example,
when reading new messages I generally flag any that are especially
relevant to me, and then have a dynamic folder which contains all
such flagged messages. This serves as a kind of personal Statalist-
based FAQ.
6) Editing. As a consumer of Statalist, one quickly comes to
appreciate well crafted postings. And constructing such postings is
much easier if your interface for editing messages is a good one.
For example, the ability, with a single keystroke, to modify the
level of quoting and to bring in other messages (in quoted form) can
make it much easier to construct a well-crafted and readable
contribution to a long or complex thread. Facilities such as being
able to rewrap lines, strip non-ASCII characters, etc. can also be
helpful. In some cases, it is even possible to construct messages
using your primary text editor.
I hope this gives you some sense of what I was referring to. In case
you're interested, I used to use Eudora, which as of 2-3 years ago
had excellent capabilities for (1) and (5) and some limited
capabilities for (3), (4), and (6). I currently use Apple Mail,
which is pretty good in all of these areas, but is unfortunately only
available if you are running OS X. I'm afraid I don't have much (or
any, really) experience with other mailers, but as you know, there
are lots (both commercial and open source) to choose from. I will
say, however, that while it may be worth spending a little time
taking a look at what's out there currently (and this is almost
certainly not as objectionable as having a colonoscopy), I'd
certainly suggest taking some time to make certain that you are
getting all you can out of your current mail client. It may have
features (or ways of using those features) that you're not aware of,
and many mail clients are extendable (e.g., via 3rd party plugins,
your own code, or external editors). What matters most is that you
are comfortable with your mailer and can use it effectively to its
fullest potential. After all, for many of us, our mailers are our
3rd most important application (after our text editor and Stata).
-- Phil
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/