done so because I have a personal bias against being surprised by software, but
your mileage may vary.Reply and Forward buttons on view windows, too?
Minor potential ergonomic improvement: we could include Reply and Forward
buttons on the message view windows, too, instead of requiring these operations
to be selected in mail list windows only. As this system’s sole user, I prefer the
uncluttered appearance and conceptual simplicity of the current latter approach;
GUIs have a way of getting out of hand when persistent pop-up windows start
nesting too deeply. It would be trivial to have Reply/Forward on view windows,
too, though; they could probably fetch mail components straight from the GUI
instead of reparsing a message.
Omit Bcc header in view windows?
Minor nit: mail view windows may be better off omitting the Bcc header even if
it’s enabled in the configuration file. Since it shouldn’t be present once a mail is
sent, it really needs to be included in composition windows only. It’s displayed as
is anyhow, to verify that Bcc is omitted on sends (the prior edition did not), to
maintain a uniform look for all mail windows, to avoid special-casing this in the
code, and to avoid making such ergonomic decisions in the absence of actual user
feedback.
Check for empty Subject lines?
Minor usability issue: it would be straightforward to add a check for an empty
Subject field on sends and to pop up a verification dialog to give the user a second
chance to fill the field in. A blank subject is probably unintended. We could do the
same for the To field as well, though there may be valid use cases for omitting this
from mail headers (the mail is still sent to Cc and Bcc recipients).
Removing duplicate recipients more accurately?
As is, the send operation attempts to remove duplicate recipients using set opera-
tions. This works, but it may be inaccurate if the same email address appears twice
with a different name component (e.g., “name1
better, we could fully parse the recipient addresses to extract and compare just the
address portion of the full email address. Arguably, though, it’s not clear what
should be done if the same recipient address appears with different names. Could
multiple people be using the same email account? If not, which name should we
choose to use?
For now, end user or mail server intervention may be required in the rare cases
where this might crop up. In most cases, other email clients will likely handle names
in consistent ways that make this a moot point. On related notes, Reply removes
duplicates in Cc prefills in the same simplistic way, and both sends and replies
could use case-insensitive string comparisons when filtering for duplicates.
Handling newsgroup messages, too?
Because Internet newsgroup posts are similar in structure to emails (header lines
plus body text; see the nntplib example in Chapter 13), this script could in principle
Ideas for Improvement| 1121