From Teaching Religion to Writing Mail Act-On & MailTags - Scott Morrison at WWDC

Each year at WWDC, TMO interviews a few Apple developers who want to tell their story. The result is usually a number of serious insights into the state of mind of the developer community. In our tenth and final interview, Dave Hamilton chats with Scott Morrison of Indev, famous for MailTags and Mail Act-On for Mail.app on the Mac.

_________________________________

Dave Hamilton: So you are obviously an independent developer, but you have three pieces of related software with two of those, MailTags and Mail Act-On, being the most popular. An then the third is ...

Scott Morrison: Mail Perspectives.

TMO: So, I’m curious to hear your story. What got you started? And what’s been interesting along the path?

SM: It goes back about ten years or so. Ten years ago, I was a high school teacher, and I taught computer science and moral and religious education. Now, there’s a mix! It was a lot of fun, and it was a job I really enjoyed. I miss aspects of it even now. I was working with 13, 14 and 15 years old kids, teaching them how to use computers. Teaching them how to do research. Teaching them how to think.

The second course was more of a philosophy course rather than any kind of religious course, and the situation was that, for some reason, I wasn’t as busy as most teachers are, and I was casting about for a hobby. So I decided to learn Objective-C.

TMO: There’s a hobby for you!

SM: Yeah, there’s a hobby! This was back in, I think, Jaguar days. OS X 10.3. So the tools weren’t really well developed, but there was a culture behind it. And there were a few software companies that I really admired. Ranchero and NetNewsWire [See our interview with Brent Simmons.] and there was Graphic Converter [by Thorsten Lemke]. I was thinking, wow, these guys are doing things! It’s not to say that my intent was to run a business. I just had that background in computer science, and always kept my hand in it, so I decided I was going to learn Objective-C.

I keyed in on Ken Ferry at Apple. He had a Mail plug-in called Type Select. Basically, what it did was let you use a keystroke to go to the first letter of a list -- which is now built into the OS, by the way. And so I took a look at that and thought, wouldn’t it be kind of cool to hit a keystroke, and rather than just select a message, do something with that message.

I poked around, and Ken’s was an open source project, and I realized it wasn’t too hard to figure out methods and stuff. So I kind of tweaked into the idea that it would be interesting to hit a keystroke and then run a rule on that message. It didn’t take too long before I had something fundamentally working. I don’t have a lot of background in reverse engineering, so I was working with ClassDump and just lots of trial and error.

After I got it working, I put it out there as open source myself, and I got a few people interested in it. I made it donationware. It was nice to get started this way because there was no real obligation. Right?

TMO: Sure!

SM: No obligation on the customer’s part and no obligation on my part. It wasn’t like, “Oh, I paid good money for this, you better make it work!” Then a couple of real programmers said to me, “Well, this isn’t working properly because you’re just treating everything as a single thread. And when I did multi-thread it, there were thread safety issues. So they actually helped me out with a few aspects of it. And that was really nice, and it kind of pointed me into some different directions.

Once I got Mail Act-On working relatively well, a person emailed me about an issue where they had multiple rules for the same keystroke, it never occurred to me that you could do that. Then I realized, omigod, you can have multiple rules for the same keystroke but have different conditions. And they will fire off differentially for different messages. That’s really powerful!

TMO: I tried that too, and it worked!

SM: That was a revelation for me. It’s one of those things where you don’t realize how people are using your software until you actually hear from them. I think, “Oh, wow, I didn’t intend that! But we’ll go with it.” So that became a feature.

And then I was also really interested in the notion of adding extra information to emails after you received them. One of the limitations I always found with email was that the information in the email is what the sender intended you to have, but it’s now how you think about the email. The original idea was to put a note on the email, say, added information that will always be associated with the email. Keywords, projects and stuff like that.

I did some poking around and figured out how Apple was storing the email, how I might work with that, and that evolved into MailTags. Again, that was donationware. This was about 2005, almost 2006. And usually the story with donationware is, of course, if you like it, send in money. And then at the end of the year, you go out and celebrate with a beer. Because that’s exactly how much money you’re going to get!

[Laughter all around]

At the end of the year, I was able to set myself up with a completely new computer system and pay my ticket to WWDC that year and had money in the bank. And so, it really got me to thinking that this is something that people have really found useful and are willing to pony up money for. And that got me to thinking – I was still working at the time as a teacher – okay, maybe there’s something more to this.

So I changed to putting a registration code on it and implemented a 30 day trial and thought, we’ll see what happens. It kept going, it was really great for about two years, where I had my day job and this on the side, but I had to work all day, then sit down each night to grade papers, and do the prep for the next day, and then I could do user support -- and try to develop code and fix bugs. Nuts!

TMO: Right. Sleep is for later.

SM: Sleep is for mortals. That developed for awhile, but after a couple of years, I realized that this is actually a gig. I really enjoyed it. A lot. So it was time to cut the apron strings. I gave noticed at my day job. It was the kind of job where I could take a year’s leave of absence from being a teacher and so I had a safety net in case, first, it didn’t work or, second, I didn’t like it. In case I didn’t like the total freedom and flexibility!

[More laughter]

TMO: With that comes some risk.

SM: Yes. And this was back around 2008-ish, when there wasn’t a huge community. Yes, you got email, but we didn’t really have Twitter back then, we didn’t have a whole lot of conferences, and there wasn’t a whole lot of networking between people. Basically, you’re one guy and the machine. And it can be a little socially isolating. Whereas working in a classroom is very not socially isolating. So I worried if I would enjoy being a developer.

As time went by, I discovered that conferences got scheduled right in the middle of the school year, but then I was actually able to go to C4 and other conferences where I started meeting other people that were doing the same kind of thing I was doing. So then I had the freedom to build my network. It’s grown since then. Also, we acquired Mail Perspectives, I think that was about 2009. With the three products now, I like to call it: process, organize and monitor. MailTags is about organization. Mail Act-On is about processing. And Mail Perspectives is about monitoring.

The latter app may be of lesser interest, but it’s one of those things where some people say, “This is absolutely indispensable.” They need to work in such a way that they can always keep track of a certain group of emails. And Smart mailboxes just don’t cut it as much.

TMO: I get it.

SM: So it fills a niche. I find it absolutely indispensable for user support. I’m the kind of guy, where, yes, I have seven different inboxes. But, I won’t want to unify them. I want to know, this is for user support, and that email is social. I don’t want them all grouped together. And then I want to recognize that these emails have tickle dates that I need to follow up on. And these emails are for projects. And keep them all visible for the time being. Then I don’t have to filter a list. I know that this has to do with that .

TMO: I’m curious. Not only do you write the software, you clearly use it. And it was initially written for you!

SM: Yes. It was to scratch an itch.

TMO: Do you have an iPhone?

SM: Yes.

TMO: Does managing your email frustrate you to no end on your iPhone because you can’t scratch the same itch?

SM: I see where this is going!

[Laughter]

Yes it does, but breaking into the iOS business is a bit of a hurdle for us right now. Partly because what we have is keeping us very busy. And what we really want is something that’s consistent across all three devices, your Mac and your iPad and your iPhone.

TMO: So you’d have to start with a brand new iOS client.

SM: Yeah. And there’s also understanding how people deal with mail on the iPhone. Email on the iPhone is all about checking your messages and processing as fast as you can with the least effort as possible. It’s not bulk management, and it’s not bulk binding of messages. You’re walking down the sidewalk, and it’s really about, oh, I gotta deal with that. Let’s file that, mark that quickly, and it should be just a swipe.

TMO: There’s clearly interest in that with Mailbox and Triage and EvoMail. This is a category that’s still defining itself right now.

SM: Still defining itself. A lot of these apps are not rule based, they’re just action based. So my concept is, edit your rules on the Mac, then use them on the phone.

TMO: I’m sure it frustrates you the same way it frustrates me.

SM: I like to just mark my mails, boom, boom, so that when I get back to my computer, I can sit down and respond to them as needed. If I can defer until later, that’s barely adequate. But that means you have to process it twice.

TMO: Interesting. All the stuff that exists on the iPhone now is all about deferring until I get back to my Mac. It would be great to process on the phone.

SM: Right. Implement the front end of a workflow on the phone. What’s tough there is that IMAP, more or less the standard protocol, is, I’ll put it diplomatically, challenging to work with – because it’s an old protocol, and because there are varying implementations of it, and because some follow the protocol loosely. And Gmail is a nightmare for IMAP -- they have their own implementation. It’s a bit of a hack, but the people with the biggest hammer get to build the fort.

TMO: It’s almost like they’re defining a new standard from a hack they didn’t want to do initially.

SM: Plus, I can’t see any motivation [by Google] to get the email off the website and onto a client where we have no advertising space. Gmail is all about eyeballs, not about providing a service for free. So it’s hard to see how Google is motivated to make IMAP a really good client.

Anyways, that’s the ecosystem I have to work with. And Gmail does kind of provide a few tools to deal with labels. And that’s a huge request I get. Can we interoperate with Gmail labels? And, yes! It’s coming. But with that, you know you only have one chance to implement it and you have to implement it right. There’s a large user base out there, and if it goes south, then boom!

[Some side discussion went to the cutting room floor.]

A heavily used feature of MailTags is Tickle Days, where people can put date information into an email and search for that data as a date as opposed to a label. That opens up a lot of things because now I can put an arbitrary date on an email message, so for example, I can see a list of all the emails I have to deal with in the next three days, automatically filtering in every day – that’s huge. You can’t do that with a simple label.

Also, it always strikes me as really odd that it’s the sender who can set the importance of a message, but not the receiver. I’d like to be able to say, “Thank you very much, but that’s not important.”

TMO: To me, that’s what your products do. They let me manage email as the person who has to actually do something with it. So many of us use our inbox as our ToDo list in some way, and it’s odd to have a ToDo list that everyone else in the world can add things to. And they get to manage what’s at the top of my list more than I do. But I digress, is there something else we need to chat about?

SM: I'm looking to the future a little bit. One of the problems with making email plugins is that as the Mail app evolves, I gotta keep up. So, with OS X 10.9 being announced tomorrow, I’m biting my nails a little bit. What does that mean for my summer? First, when are they going to ship? Second, what kinds of changes will there be? Underneath?

TMO: Nothing? Or wholesale?

SM: When Lion was announced, Apple said we’ve redone the interface. That changes everything! It was good in that it meant I could do a complete product refresh cycle on MailTags, but it meant I had a lot of development ahead of me. And that brought a lot of new interaction with beta testers. Well, my beta testing period went on for months, developing and tweaking.

Lion shipped, I think, in July 2011, but I didn’t ship MailTags 3 until March of 2012. It’s always difficult because I’m always playing catch-up. I can’t dictate my own release cycles. As a business, I’m not always at the steering wheel.

TMO: Right. You’re at the mercy of Apple. Like many of us.

SM: If Apple says they’re shipping on July 15, that means I’m shipping on July 15. That means I have to burn the midnight oil. So, in hindsight, that’s not something I’d recommend people engage in!

[Laughter]

Having control over a product line is very important. And not relying on external things. Now, the minor tweaks that Apple makes to their frameworks aren’t going to easily kill a product. They may make some things easier, fix bugs ... not that Apple ships anything that has bugs in i.... But it does mean that chances are, when people install the latest OS, they’ll fire up a product, and there’s a good chance it’s going to work.

Not so with my stuff.

TMO: But [Apple’s] Mail is built to be extensible....

SM: Yes and no. Mail does have a plug-in/bundle loading mechanism. And there’s an ID system to make sure the plug-ins are current to the current system. So there’s that. But there’s no formal API. There’s no documentation. There’s no official way of doing anything. And because it’s not a stand alone application, there’s no entry into the Mac App Store. So it’s a real gray area. That plug-in architecture actually goes back to NeXTSTEP days.

In fact, I went to the National Computing Museum in Bletchley Park a fews months ago when I was in the UK and they had a NeXT box there. No one was around, so I sat down started reverse engineering Mail – it was very cool – there was actually recognizable code in there!

So there’s no official mechanism there. Apple allows it, but they’re not going out of their way to encourage people to do it. And so, who knows what the future will bring because there’s no commitment to it.

I can understand that because creating a public API is a lot of work, not because of the coding, but rather deciding what functionality to expose. It also ties Apple’s hands if they have a public API, they have to document it and more or less stick to it. And if they’re not going to stick to that API, they have to go through a process of deprecation and obsoletion. So it ties their hands.

It’s totally understandable, that they don’t do it. There are maybe only a dozen developers out there who are doing Mail plug-ins. There’s some really good stuff out there. And there are a lot of people whose workflow relies on these plug-ins. And not just individuals -- fairly large organizations. This is all something that’s very useful, but it’s also a gray area.

TMO: It’s an interesting world to live in!

SM: It keeps me busy.

TMO: That’s good! I think that’s a good place to wrap up. Thanks for taking the time to chat.

SM: I hope that was interesting and useful.

TMO: It was! Thanks!

______________________

Interview by Dave Hamilton, transcription and editing by John Martellaro.