This is one of my journal's many "channels."
What I haven't yet seen mentioned is that "top posters" are notorious for only replying to one part — possibly even just one line or sentence — in a longer email. Many times over the years I have written a long-ish message to a client, explaining how I would do something (and for how much), only to receive back a copy of my entire message with a question at the top like, "How would that part work, exactly?" or "Could you send me a sketch of how you think that part would look?"
See, I've sent a message with twelve paragraphs explaining the overall flow of an application, and the question I get back could refer to almost any of it.
Even better (worse) is that my original message probably included a few questions which have gone completely unanswered.
That, to me, is the biggest benefit of the inline-reply style. You have to pay attention to what you're doing! You start your reply by quoting the entire message. As you go through the original message, you delete the stuff which needs no reply and which isn't needed for context, and then insert your own comments immediately after the relevant parts that remain. Since most email programs show different levels of quoting in different colors, it's very easy to follow the conversation.
Recently someone sent me a "breath of fresh air." It was another software developer, and we've been talking about me helping him out with the next version of his (only) application. Our conversation has stretched out over three months, but we're both sticklers for the inline-reply style so reading back through these email messages is just wonderful. Trying to have a conversation like this with a "top-poster" (someone who always quotes everything that came before, and only puts replies at the top) would be awkward, if not impossible.
Unfortunately, some email clients make inline-replying a little difficult. Gmail, MobileMail (Apple's Mail on the iPhone), and Outlook/Entourage are all good (bad) examples. They can all make very "pretty" email with bolds, colors, fonts, links and pictures, but those things are secondary (or tertiary) to good communication. At the opposite end of the spectrum are apps like Mailsmith, which *can't* create fancy-schmancy bold/colored/linked/imaged messages, but which provide tools to make inline-replying even easier than it is already. (There are other apps like that, but Mailsmith is the one I use. Claris Emailer was another great example of this type of app, back in its day.)
At long last — and folks, I *do mean* LOOOONG last — Mailsmith 2.2 has been released to (semi-)public beta.
Like John Gruber and Michael Tsai, I've been using pre-release versions of Mailsmith for years (nay, centuries!), so most of these features are not new to me. But still, I'm very happy with this release. It's good, and a very welcome improvement over the previous public release (which was already my least-disliked email client).
(That may sound like a backhanded compliment. It's not intended to be. My old thoughts on email clients still ring true today.)
The change list in this 2.2 beta is commensurate with the amount of time Mailsmith's users waited for it. Some of my favorites:
Excellent Unicode support. Their new and improved support was what inspired me, last year, to treat all messages in Conversant as UTF-8.
Zip compression. StuffIt no longer required.
Inline spell checking.
The new Simple Query window is wonderful (though this is an area that's clearly still in beta)
Replies can be automatically moved to the same mailbox as the original. Love it!
"Send PDF with Mailsmith" — handy workflow feature
The new soft wrapping options and format=flowed feature are conceptually related, and are a couple of my favorite new features.
The whole Menus preferences system (mainly because I like to hide what I know I don't need)
The clippings changes, because they stem from work I helped with (a little) in BBEdit and I have an ego ;-)
Don't Bug Me! My number one favorite new feature is the "Do Not Disturb" feature. See the "Mailsmith" menu, or the dock icon's contextual menu. (I called it the "Don't Bug Me" feature when I requested it. I saw another beta tester refer to it as, "the greatest feature he never knew he needed.")
All the new toolbar icons.
The text version of HTML messages is much nicer. It might look surprisingly similar to some people around here... ;-)
The list is so long that I'm reminded that anybody new to Mailsmith 2.2 probably won't know where to start. So I suggest that you set the following (new/changed) preferences if they're not already:
Under "Sending," set "Move it to Original's Mailbox"
Under "Editing: General," set "Soft Wrapped Line Indentation" to "First Line"
Under "Mail Lists," set "Show Buttons in Lists"
Under "Menus," turn off the "Tools" menu if it isn't already.
Make sure you at least notice the options at the bottom of the "Menus" preference pane, where you can control which items appear in the contextual menu.
The simple query window won't default to the currently selected mailbox(es) unless you run this command in Terminal:
defaults write com.barebones.mailsmith Misc:AlwaysUseSelectedMailboxesForQuery -bool YES
Update: I see Michael agrees with me.
The issue here is that users have two conflicting "needs" with the Query windows. I almost always want the Simple Query window to open with the current mailbox pre-selected. However, there are a few occasions (and it's probably more common for other types of users) where I have carefully chosen a subset of my 63 mailboxes (folders) and run a search, then realized that I left out a search term. With the above preference set the way I have it now, reopening the Simple Query window reverts the mailbox selection to the "current mailbox", so I need to reselect the subset of mailboxes to search.
I'm not the fan of "prefs for everything" that I once was, and I totally understand the need to keep the UI clean and simple.
My thought for this particular problem would be a way to move back and forth through a history of selected mailbox sets. When a query is run, another set is added to the history unless it's identical to the most recent set.
Just thinking out loud, I guess.
If you're a Mailsmith user (past or present), give this new version a spin. The link for downloading is at the bottom of the change list.
A bug in my preferred email client annoyed me enough that I camped out in the developer's own living room until he fixed it and gave me a new build. :-)
I kid you not. Mostly.
Plus, he bought me breakfast. This was really a good deal all around.
(He even took a picture of my breakfast!)
Then we reviewed the other unreproducible bugs I've reported in the last year (I'm as good at finding the bizarre bugs in other people's software as I am at creating them in my own!), and fixed all of them except one. That one was a doozie, though... I think they had bets in the BB office about my sanity. (Sorry, Steve, you lose! Rich saw the bug with his own eyes.)
So my "breakfast" with Rich turned into a very productive, all-day event. I didn't arrive home until 7:04 pm: 12 hours (almost to the second) after I left.
The donor who wrote to me a few weeks ago asked what lessons I had learnt and what I was planning to do differently this year with the auctions.
I wrote back to say that one of the hardest parts of the auctions, last year, was contacting the donors at various times in the process.
Of course, I got a bounce message just a minute after writing back to the donor. Their mailbox is full. Case in point.
For years, we've had this nagging little problem with Macrobyte's mail server: sending mail was sometimes very slow.
Yesterday I was finally annoyed enough with it to really debug it... and found that the culprit was what's known as the ident test. When an SMTP connection is opened to the server, it in turn tries to open an IDENT connection back to the client to get the true identity of whoever just opened the connection.
Unfortunately, testing indicates that it (almost) always fails, at least with messages being sent by people. (And for the alternative, which is mail being relayed from another SMTP server, the identity of the daemon sending the mail just doesn't matter.)
Shutting off that test in Exim's config file immediately solved the delay.
Lest this make anyone feel like yelling at me, I'll just point out that it was a gigantic waste of server resources. Like I said, the calls nearly always failed. I realize some systems provide useful responses to RFC 1413 requests, but most do not.
is Seth Dillingham's
personal web site.
More than the sum of my parts.