2010 (old posts, page 1)

I have a minor obsession with email clie...

I have a minor obsession with email clients. I'm fascinated with how people use email and how clients have (and haven't) evolved over the last 40 years.

So, I started a separate blog on Tumblr to explore email clients, called mike checks mail.

The idea is to look at clients available now on OS X, and discuss their features and their flaws. It's basically very focused app criticism.

The first few posts have focused on the three free apps I use daily - Apple Mail, GMail and Thunderbird. Eventually I want to explore the other major mail clients currently on the market, including Entourage, Postbox, Eudora, and Outspring. I'd also like to dive into other platforms, to avoid reinventing something smart that's been in (say) emacs for 30 years.

Take a look, and send me questions and suggestions for topics. Let's geek out on mail clients…

Unread counts

One common misguided feature of mail clients is putting an attention-grabbing red badge somewhere showing the count of unread messages in your inbox (or some other folder). It's worst if it's on the dock badge and you don't hide the dock - then there's no way short of quitting the app to completely avoid this visual interruption. Sure you can just ignore it, but why should you have to?

A quick survey of the three main mail clients I've been using shows that they all have some way of putting unread counts in your line of sight, and only Apple Mail (I use v 3.6 on OS X 10.5) really lets you shut it up - you can tell it not to badge the dock at all. If you had a subset of mail that really does need to interrupt you, you can also restrict the unread count to a particular smart mailbox.

AppleMail Quiet Prefs

The smart mailbox feature is interesting. It's hard to imagine what kind of email is just important enough to show the unread count for, but not important enough for a more obvious alert. I'm sure the feature comes from a different viewpoint on mail - perhaps the idea is that you'll never read all your messages, so you want to see a count of how many "important" ones you need to read. I think that's just treating a symptom, though, honestly.

On the other end of the scale, Thunderbird 3 has no way that I can find to turn off the dock badge:

TBird dock badge

They do give you a way to make it more annoying, though - you can have the dock icon bounce for every new mail! I can't think of any good reason for that, except that at some point when the dock was new, it was fun to make things bounce.

Tbird quiet prefs

Finally, GMail - I take my GMail more or less straight-up, in a dedicated browser app with no extra frills, that I wrote in 2006 (see post here ). I understand that apps like Mailplane add some nice desktop integration, and multiple account support, but I don't really need that stuff. So, assuming a basic straight-up GMail, it has no dock badge, but it does show an unread count in the title bar:

gmail unread

While that'll show up in some menus and on mouse-over in Exposé, it's really not a big deal. I'd say that GMail (in the browser) and Apple Mail are about the same in terms of visual distraction, once you change the prefs in Mail.

I'd prefer that an email app didn't do anything to make all unread messages look like something important you need to fix. If I'm going to check the mail, I'll notice the messages. If I'm not about to check the mail, I don't want to know. I think this is best for everyone, too - like the insistence on filing vs. searching, it's an outdated habit from a time when email volumes were lower.

Either a message is important enough for a major interruption - a pop-up window with a beep, for instance - or it's OK to let it sit for a while. The unread status alone is a poor substitute for "important", and we should move past it.

HTML mail is here to stay, so a client needs to handle it well. Since images in HTML mail are securi

HTML mail is here to stay, so a client needs to handle it well. Since images in HTML mail are security problems, a good client won't load them until you say so - and should also let you white-list some senders.

GMail does this well enough, with two links - one to show the images in a message once, and another to whitelist the sender. I'd say that's about the best you can ask for. If you want to remove a sender from the whitelist, it's a little obscure - you have to find an email from them and there's a link in the details that says "Don't display from now on."

GMail image whitelist

One interesting thing is that this is a separate list of addresses from your Contacts (which in GMail, includes every address in every email by default).

Thunderbird starts off with basically the same interface as GMail. They show a big loud bar that alerts you to the missing images, as if you couldn't tell. You can press a button to load it once, or click a link (why not another button?) to whitelist the sender.

Tbird image whitelist

This is where we go a little haywire, though - all I want to do is whitelist the sender for images, but Thunderbird throws up a sheet asking me for all kinds of contact info - now the sending email is in my address book. So I end up with a bunch of noreply addresses in a group in my address book called "Personal Address Book." Thanks?

Tbird addrbook

I think a whitelist just for image display that's separate from the address book is the way to go - it seems more natural. An address book seems like something I should control manually. Ideally, in a desktop mail client on OS X, the client's address book is just the system's Address Book DB - so that other apps can use the info. And since that's system-wide data, you really don't want a client just dumping everything in there.

Let's talk some more email philosophy. An email client should help you quickly get through new email

Let's talk some more email philosophy. An email client should help you quickly get through new emails, on your schedule, and turn them into whatever you need them to be once you've read them. Then it should shut up until you call it again.

Again, I'll point at Merlin Mann as my original inspiration, and if you want to hear more about the reasons behind this line of thought, go listen to his recent podcast appearances.

Further - I'm against unread counts, against new-mail sounds, against pop-up notification of new mail. I can't think of a job you could have where there's a good reason you should be interrupted by an email client for every new message. Sure, some things are important and ought to interrupt you - but there are a host of better technologies for urgent communication - IM, SMS, Phone calls, etc.

I'm for search, against filing. If you're shuffling email into folders, part of what you're doing is building an index. Computers know how to index text, and they can do it faster and more completely than you can, so stop wasting your time - especially if you're just filing it according to data that's already in the message, like sender or date. If your filing system is adding some information to each message, then a client should just let you add that info quickly and then index it for you. Not enough clients do this well.

Finally, like many people, I work at a big company that runs its own email infrastructure and won't be giving control to Google any time soon. This means that while GMail is an interesting case study and a useful option for personal email, I need to use another client for most of my email. That's why mikechecksmail is about desktop mail clients. I use a Mac, and so it's about Mac desktop mail clients. That said, I won't ignore other systems - good ideas are good ideas.

Why mikechecksmail

I think that email clients are important, and worth a little criticism. We all use email, and lots of us complain about it - especially professionals. It's such a critical tool for our jobs, and it's frustrating when it doesn't work as well as we'd like, or when it distracts too much when we have better things to do.

What's my philosophy on email? If you want the original inspiration in long form, check out what Merlin Mann has been saying for years now, at Inbox Zero. The short version, which might look funny on a site where I plan to talk about email clients, is that most of what people don't like about email isn't the email software's fault. If email is a huge problem for your work, you probably can't solve it with a better client. I can't agree more.

However, that's no reason not to insist on continued improvements in the one tool every single knowledge worker uses, and that's what this site is about.


Link: http://is.gd/b0K5b

Merlin has a suggestion about inboxes and default views:

Assuming I want to see unprocessed messages every time I do anything with email is like making me trudge out to my home mailbox every time I take a leak, turn on the oven, fold a towel, or do any of the 500,000 other things I can easily accomplish without asking for new information.

Every mail client ever misses Merlin’s point. There’s more than one thing that we do with email, and every time we do one of them, we have to pay the distraction tax of seeing our inbox. The way to fix this is to completely separate processing new things from the other tasks - composing new mail, referring to temporarily useful mail, and searching for old mail.

I like Merlin’s approach of having a separate “app” for each view onto his mail. I do wonder if this kind of thing would catch on. This feels like an extension of something I wrote a while ago, the webmail-only browser, where the idea is to identify a single task that you need to wall off from distraction, and make a separate app just for that.

Let's start things off with a key-shortcut gripe from Thunderbird 3.

Let's start things off with a key-shortcut gripe from Thunderbird 3. "Forward" is ⌘-L. Not ⌘-F (that's find-in-message, which is pretty common, if rarely used) or even ⌘-⇧-F, like it is in Mail. ⌘-⇧-F in Thunderbird brings up this bad boy: Message search dialog in Thunderbird

We can talk more about search later, but for for the sake of the keyboard shortcut discussion, why not start with the nice search field in the toolbar? Google has taught us that a single text field is how we should do search, and we almost never need to fill out a big form to search for things.

Another thing the web has taught us is that ⌘-L is basically "go to the command line". It's so hardwired at this point that using that shortcut for anything other than a generalized command interface seems like a missed opportunity.

Snakes on Demand: How to write a Python Launchd Agent

Suppose you want to write a Launchd agent in Python that communicates using UNIX domain sockets. There's no sample code for that, but the information is out there to figure out how (especially because the launchd source code is available). Most search results will tell you that you need to read the Daemons and Agents Tech Report TN2083, but it's pretty long and not a great tutorial. A better intro reference is Chris Hanson's blog post "Launchd: better than sliced bread!", but that doesn't tell you everything, and doesn't mention Python.

I decided I'd share what I've learned recently to make getting started a little easier. I'll give a short description here and post the resulting code to bitbucket at py-launchd.

Note: This was written and tested on OS X 10.5.8 with the default /usr/bin/python, version 2.5.1. Since I wanted to use multiprocessing, I used the backport to 2.5 available at google code: python-multiprocessing . For convenience, it's included in the repository, and so is its license.


What we're trying to do is have some python code that gets called when launchd notices someone connecting to a UNIX domain socket. UNIX domain sockets are local-only, so this is ideal for agents that only serve local apps. We're also using launchd "agents" not "daemons", so we're assuming that it's OK to have one agent process for each user. If you're managing access to something that needs to be unique system-wide, then this won't work (but you can still use Launchd).

launchd overview

The launchd process will read a launchd plist you give it (at login, via launchctl or the 10.6 framework), and listen on the socket you tell it to. Once it sees a connection, it'll start the agent program you specified in the plist, and that program can make some calls using the launchd C API to get a file descriptor for the socket that was connected. This is important - you don't need to call bind() or listen() on the socket, because launchd already did. It's just handing the open socket's file descriptor straight to you and your code can just call accept() on it.

Using launchd with Python

You need to create a C/ObjC tool that can do the launchd check-in to get the open file descriptor, then pass that off to your Python code. This is pretty straightforward using the Python framework included in OS X and the Python C APIs.

What I've done is create an agent loader that I called PyLaunchd that loads and runs server code in Agent.py. It expects Agent.py to be in the same directory.

PyLaunchd is built separately and copied into the test app's Resources folder with an XCode script phase.

I have the app delegate copy PyLaunchd and Agent.py to ~/Library/Application Support/PyLaunchd/ on loading. It also customizes the launchd plist to set the path correctly for the current user, then writes that to ~/Library/LaunchAgents/, and loads it. (Actually it first unloads it, then reloads it. I'm not convinced this is the right way to do it). It uses system() to call launchctl, but I believe in OS X 10.6 there's an API you can call to do it directly.

Finally, the sample app is really simple - it just opens the socket using the multiprocessing Client class, and sends whatever you type. The example Agent I've included will ROT13 it and send it back.

Please let me know if you have any comments, questions, or improvements.

How BibDesk generates Apple Help and a web manual

This is something that had been on my old blog in 2006 and went away, so I'm reposting something I wrote to the macsb list a few years ago:

For the BibDesk open source project, we wanted to have legit in-app apple help, as well as a web page (and PDF), without maintaining separate sources, since we were all working out of spare time.

We tried a few free options, and eventually worked out something decent with Texinfo, a latex-like markup language that can be processed into latex (and then PDF) or HTML.

I wrote a custom init file to have the (standard) texi2html script print out apple help compatible HTML. One post-processing script and a simple xcode script build phase later, and we get apple help.

We also get a version a little more suitable for the web (more content per page) from the same source: http://bibdesk.sf.net/manual/

It's worked well for a couple of years, and it's a good choice if you don't mind learning texinfo (it's pretty nice compared to writing in Docbook or HTML, IMO), and very good for version-controlled collaboration, since it's just text.

For an example, here's what the help source text looks like:


The init file and other stuff is here: http://bibdesk.svn.sourceforge.net/viewvc/bibdesk/trunk/bibdesk/BibDesk%20Help/

If anyone's curious about it, feel free to ask me questions here. I'll try to remember how it works.

Tinkering in the Sideshow

Last week, Alex Payne and Mark Pilgrim both made some heartfelt arguments explaining why they think the fact that Apple's vision of the computing future as a relatively closed appliance is depressing. I agree, and I want to explain exactly why, now that I think I've figured it out.

Each post got plenty of responses. Dissenters have a wide variety of reasons for why it's no big deal, ranging from "tomorrows tinkerers will just play with different technology, like bio-mecha" (fascinating!), to a lot of people saying, essentially, "Just don't buy the appliance if you want a computer" (obvious!).

Others have made a solid point that the iPad is the next big computing paradigm. Steven Frank calls it a "New World" device. I can't help but agree, and of course powerful devices that empower instead of confuse the user are a good thing. Replacing most of the world's overcomplicated, fussy laptops with focused and reliable devices is a good thing.

Of course, general purpose, hackable computers are not really going away, not soon. Even if everyone uses an iPad for personal stuff and a Chrome OS netbook to access private cloud services for business work, there will still be a need for workstations, and I hope the people building complete personal systems out of Free Software don't give up.

However, in a response to comments on his post, Mark Pilgrim made a gloomy prediction: "People haven’t figured it out yet, but Mac OS X is on its last legs. By 2015, Apple will make appliances and developer add-ons. Not general purpose computing devices."

If you ask me, this is the real problem.

The problem is that hackable computers that I want to use could very well be fading out. Maybe Mark's overstating things, but I would not be surprised to see the Mac, and OS X, as a relatively low priority for Apple in the near future. Design and development effort and creativity will naturally go increasingly toward the more profitable platform - the one making computing finally pleasant for the normal person.

I'm worried that this will happen for third-party developers too. I'm not the only one. Back in 2002, Brent Simmons described developing user code for the Mac as "the show". Is there any doubt that Apple's mobile OS is "the show" now?

Where does that leave the rest of us who still have to or want to use a more powerful platform?