Tag Archives: email

Core Intuition Jobs shutting down

A few years ago, Daniel and I launched Core Intuition Jobs, a site for companies to post job listings for Mac and iOS developers. It was a really nice success. At one point I thought we might even focus more time on it, and expand it with a companion site of resources to help developers.

Fast forward a year or two, though, and it became clear that without that attention, the site couldn’t just coast along. New listings were becoming more infrequent. The site needed marketing and regular improvements, just like any product.

And worse, while the whole point was to build something just for Cocoa developers, the site would still sometimes receive job listings for Java or Python developers, for example, and we’d need to refund the listing and remove it from the site. It wasn’t a lot of maintenance, but it was enough that we had to decide whether to put more work into the site or focus on our main podcast and other projects.

This week we decided it was time to move on. Existing job listings will continue to run until they expire. No new jobs are being accepted.

Thanks to all the companies who used Core Intuition Jobs. Now when we are asked about other places to post jobs, we’re pointing people to the email newsletters iOS Dev Weekly and This Week in Swift, as well as Core Intuition podcast sponsorships. Good luck to everyone looking for a new job!

Email archiving with Evernote

For a long time, I’ve struggled with having important email archived in one place. I’ve switched between several clients over the years, from Eudora and Mailsmith and even Cyberdog, in the very early Mac days, to more recently the fairly reliable Apple Mail. Yet I still occasionally lose old email when switching between machines and not handling the migration properly.

Last year I set out to fix this. While I didn’t do an exhaustive search of archiving options, the main solutions I considered were:

  • Switch to Gmail. There are plenty of native clients for Gmail, but I fundamentally don’t like the idea of an ad-supported email service. I’m very happy with Fastmail and want to continue using it.
  • Local archiving with EagleFiler. This gets the email archived in a central place outside whatever mail client I’m using, which is great. However, I’d like something that is focused on cloud search first.
  • Save to files on Dropbox. All of my notes are stored on Dropbox, so why not put an email archive there too? But Dropbox doesn’t seem well-suited to accessing and searching easily.
  • Save to Evernote. I’ve never actively used Evernote for notes. Using Evernote for email would keep the email separate from normal notes on Dropbox, and Evernote already has excellent support for forwarding email into their system. I’d be able to search the archive from my Mac, iPhone, or the web.

I’ve settled into a pretty basic workflow of using Evernote to save any email that looks moderately valuable. This is usually a handful of messages each day, not every email I receive or send. By picking and choosing what gets archived, I can ignore everything else, letting it sit in Mail’s archive indefinitely or deleting it.

Here’s an AppleScript I currently trigger in Mail for any selected message I want to archive. It’s set to command-shift-S via FastScripts. If I’m away from my Mac, or I want to preserve HTML and inline attachments, I can save an email by forwarding it to a special Evernote email address. (I also pay for Evernote Premium.)

Now that I’m about a year and thousands of archived messages into this setup, I’m declaring it a success. I plan to continue using Evernote in this way for years to come. Let’s just hope they’re on the right track with their own business.

Pre-announcing Snippets.today

Earlier this week I sent an email to subscribers of the announce list for my microblogging project. These are people who signed up, wanting to hear more about what the project was and when the beta would be available.

I talked about this on Core Intuition 241 today. Some people signed up a year ago, and the longer I went without sending an email, the more nervous I became that I was missing an opportunity to sustain interest in the project. I was stuck on the idea that the first email to the list had to be when there was a product to either test or pay for.

These decisions of when to release a product, what to write about, how to communicate new ideas without overwhelming potential customers — they seem so monumental, but the truth is it just doesn’t matter that much. When the feedback started rolling in over email, I quickly realized that I was worried for nothing. People were excited and supportive.

I have a lot of work to do over the next couple of weeks before it’s ready to open up to real users. As I’ve talked about a few times on my Timetable podcast, I’m planning a Kickstarter project to complement the web app. I’ll be sharing more soon.

Pinboard at 7 years

Maciej Cegłowski of Pinboard has always been open about his stats for the service. Now, on the 7th anniversary, he also shares that revenue has grown to well over $200k/year:

I’ve added revenue this year because I’m no longer afraid of competitors, and I’d like to encourage people who are considering doing their own one- or zero-person business. The site costs something like $17K/year to run, so you can make a good living at this artisanal SaaS stuff.

Congrats to Maciej on his success. I’ve been a happy Pinboard user for pretty much all of those 7 years, and — as someone who also aspires to build a profitable web platform — I’m inspired by Pinboard’s consistency and growth.

Speaking of 6-figure income, I’ve also just finished reading Shawn Blanc’s write-up about launching The Focus Course, which had first-week revenue of over $100k. He describes the planning process and his strategy for using a mailing list to build awareness about the product.

Watermark transition plan

I sent an email to Watermark customers over the weekend, letting them know that the service as it currently exists will be going away on May 15th. As I wrote about last year, Twitter has improved their search enough that a part of what Watermark is good at is no longer as necessary as it once was. However, I still see interest in Tweet Marker, from developers and users, so I wanted to keep the web-based timeline and sync from Watermark and make it available to all Tweet Marker subscribers.

You can learn more about Tweet Marker here. I’ve had to significantly scale out the backend servers this year, including adding a second load balancer, so I’d love your support. The new timeline feature will roll out later in May.

While I’m happy to keep offering a part of Watermark (now back in Tweet Marker), I have less good news for Tweet Library. I’ve found it very difficult to justify the time to finish the new version. It’s now looking likely that the current version will be the last.

Sparrow and the unlimited indies

Recently I found myself in rare disagreement with Matt Gemmell:

“Indie devs are an endlessly replenishable resource. Good indie devs are similarly replenishable. This acquisition has no effect whatsoever on the rest of us, except for further legitimising the practice of big companies buying us up. That cannot possibly be a bad thing.”

While the general argument that Matt makes is solid — that Sparrow customers should be happy for the developers being acquired by Google, and that paying $3 for an app doesn’t give anyone a right to complain or feel betrayed — there are a couple ways that this acquisition could be a bad thing for everyone else.

Good indie devs, especially successful ones, are a limited resource. There are very few indie companies able to make a client as polished as Sparrow was, and even fewer with commercial success.

And with Twitter’s latest anti-competitive moves, we may end up losing another market that was friendly to indie developers and rich with UI innovation.

My favorite take on the Sparrow acquisition and what it means for sustainable indie software came from Rian van der Merwe:

“We need to reframe this argument. The real issue is much deeper than this specific acquisition. The real issue is the sudden vulnerability we feel now that one of our theories about independent app development has failed.”

The Sparrow acquisition came as a surprise to most of us. One day, they look like a successful company, taking on a difficult market and winning against free competition. The next day, they’re gone. I wish them luck at Google, but it is a loss for the community of small Mac and iOS companies.

(Speaking of Matt Gemmell, he’s just released a new Mac app called Sticky Notifications for sticking reminders in Mountain Lion’s notification center.)

Faster support response times

In an “interview with Kevin Hoctor on episode 5 of the iDeveloper Live podcast”:http://ideveloper.tv/shows, Scotty referenced my comment from Core Intuition that customers are so used to terrible support that they don’t mind a few days or even a week delay. I thought this was maybe taken out of context a little since we were talking about vacations, so I went back to listen to what I said:

“Most people are thrilled to get a response in a few days, maybe a week they’re still cool with it. They are used to sending support email to companies and not getting a response any time soon or maybe not at all in some cases.”

Of course I didn’t mean I strive for week delays before a customer gets a response, but looking back I think Scotty’s interpretation was right: in a way this was a confession that I’ve fallen down when it comes to support. My response times for Tweet Library questions are still very good (usually same day), but it’s dragging for my other products. Even when I’m quick to respond to an initial email, difficult follow-up questions often won’t see an answer for some time. I’m just not as responsive as I was when I wrote “this blog post about good support in 2007”:http://www.manton.org/2007/02/customer.html.

The worst part are the emails that fall through the cracks. They are on their 2nd or 3rd response to a problem that I don’t understand, or they’re waiting on a solution that isn’t ready, and months go by before I can pick up the thread again. I hate this.

I’m going to use this opportunity to get back to where I should be: less than 24-hour response in all cases, for all products. I’m adding a “stats section to my support page”:http://www.riverfold.com/support/ to keep me in check, and I’ve seeded it with response times for the most recent support questions via email and forums. This will also give customers an idea of what to expect without an explicit promise from me.

Fast customer support

Three years ago “I wrote the following”:http://www.manton.org/2007/02/customer.html about customer support:

“Most people who buy Mac software from independent developers know that it’s only 1-5 people behind the company. We can’t compete with the Microsofts and Adobes of the world on application size, but we can compete on quality customer service. _Being small is a competitive advantage_.”

Seems reasonable, but the fact is that many small companies are struggling to keep up with the support load. “Jesse Grosjean recently downgraded”:http://blog.hogbaysoftware.com/post/468160055/support-expectations his support expectations for customers. From the official site:

“I’ll answer basic questions and license key/order issues as fast as I can. I also appreciate larger questions and feature suggestions, but I’m finding that I no longer have time to answer them all as I used to (mostly). I promise to read and consider everything, but you may not get an individual response.”

I’m a huge fan of Jesse’s TaskPaper and his minimalist approach to Mac development. He is very honest with customers and encourages participation starting with early beta versions.

But it can be damaging to set support expectations too low. Here’s what a support page says about support in “Pastebot”:http://tapbots.com/software/pastebot/, another one of my favorite iPhone apps:

“We try our best to answer every support question. But please make sure your question hasn’t already been answered in our FAQ. If you email us with an issue that has already been explained in the FAQs, we may skip the email.”

This seems slightly backwards to me. The questions in the FAQ are the easiest to answer! I respond to those immediately. It’s the hard questions for which I don’t have a good answer yet that usually take the longest time or are more likely to fall through the cracks.

Is the weight of support for iPhone developers just too much? TaskPaper and Pastebot are both very popular. I guess we can all hope to be successful enough that we find out.

Meanwhile, I had a question for “Beanstalk”:http://beanstalkapp.com/ yesterday and received a response in just 19 minutes and an additional follow-up response in under 10 minutes. I like to show off impressive companies, so I tweeted how fast their response was. “Their answer”:http://twitter.com/Beanstalkapp/status/11270045214 to my tweet? “We’re usually faster.”

Yep, that’s the right attitude. Set your standards high.

Campaign Monitor

Last month, on the 7th episode of Core Intuition, we talked about promotion. In particular I had good things to say about Campaign Monitor, and the folks who built it heard the episode and wanted to ask a set of follow-up questions to use on their own blog. “That mini-interview with me”:http://www.campaignmonitor.com/blog/archives/2008/10/manton_reece_talks_email_marke.html about how I used the service is now online.

In closing out that blog post, Mathew Patterson of Freshview suggests a couple things I agree with, including sending a newsletter more frequently than once a year. In fact I would love to send another one soon, to link up a survey to get some more information about why customers are purchasing Wii Transfer.

Unfortunately my hands are tied with yearly. When I put together the Wii giveaway promotion, I specifically told users opting in that it would be about once a year. I did this to encourage people to sign up without wondering if they would be spammed all the time. And also, I doubted that I would have the time to send a newsletter much more often than every year. So it’s not ideal, but there it is.

Since then we’ve recorded 2 more shows. The latest “Core Intuition”:http://www.coreint.org/ hits the lifting of the NDA, the iPhone Tech Talk Tour, and Apple’s stock price.

Professional email app

Ignore that this post is a week late. While I was out sick last week there was a great discussion across blogs about email clients, starting with “Brent Simmons”:http://inessential.com/?comments=1&postid=3425 and then to “Paul Kafasis”:http://www.rogueamoeba.com/utm/posts/Article/Rise-of-the-OS-2007-07-05-12-00.html while passing through several good blogs in between.

Some of my additional gripes about Mail:

  • Text editor is terrible for text-only email, especially when quoting.

  • UI refresh glitches with mailbox unread counts.

  • Sluggish showing new smart folders.

  • Search is not powerful enough without making smart folders.

  • Overall stability problems.

I started writing an email client last year and worked on it in my spare time for a couple of months before abandoning it. It added a few new twists that other clients don’t have, including a server component in an attempt to embrace the benefits of both Gmail (access anywhere, automatic sync) and a native Mac client (better UI). No one I described it to thought they needed it, and I gave up before the UI was polished enough to actually show. Turns out the server piece was too complex and no matter how I juggled the numbers, it just didn’t seem a profitable endeavor.

The recent discussions really make we want to take some of the core pieces (great performance for huge amounts of mail and a tag-based filing system), rebuild it on top of IMAP instead of my custom web services gateway, and see what happens. But I probably won’t. Email clients are a tricky thing to get right, and I don’t have time right now to make it perfect.

I have no doubt that there is a market waiting for a great email client. You don’t need to compete with Mail.app, you just have to appeal to anyone who has been burned by an email client before. People who are serious about email.

Customer support

One of the most interesting (and difficult) parts of running an independent software business is responding to support email. It is very time-consuming and often more frustrating than writing code because the solutions can be illusive. You want to help the customer, but it’s not always obvious how.

Two blog posts in the last week take entirely different approaches to customer support. The first is from Ryan Carson, who is well known for DropSend and The Future of Web Apps conference. Here’s a snippet from his response to a customer:

I am now marking your email address as spam and your communication will no longer get through. If you don’t want to use our service any more, please cancel your account.

I was relieved to read the comments, which are more sane. I think Ryan made a mistake in how he dealt with the customer, and wasted a bunch of time in the process. Adding a customer to your spam filter? Yikes. I would have refunded the customer their $5 immediately.

(I actually like a lot of what Ryan writes and the events he puts on, but lately I find myself noticing the differences. As another example, his post about outsourcing programming work to Russia left me puzzled.)

Joel Spolsky also wrote an essay on support, and it’s just about perfect. I especially like his section on memorizing awkward phrases:

It’s completely natural to have trouble saying “It’s my fault.” That’s human. But those three words are going to make your angry customers much happier. So you’re going to have to say them. And you’re going to have to sound like you mean it.

For almost every support email I get, I start by responding like this:

Hi Bob, Thanks for purchasing Wii Transfer. I’m sorry to hear it was not working correctly for you.

This does three things right away that I think are important:

  • Greet the person by their name. Kind of like making eye contact. And it’s respectful without being overly formal.

  • Thank them for using the product. If they haven’t bought it yet, replace “purchasing” with “trying.”

  • Apologize that the software gave them trouble. This is mostly equivalent to Joel’s “it’s my fault” phrase.

Although I could probably respond faster by using some macro shortcuts that do this for me, I actually type this out every time, varying it slightly as is appropriate for the question. I then move on to the actual solution or follow-up question about their issue.

This is more than just trying to be nice to people. As someone in the comments to Ryan Carson’s post said: you need to show the customer that you are on their side. Going negative demonstrates that you care about receiving their money but not actually building something useful that makes their life easier.

Here’s a portion of 37signals take on being on the customers side, from Getting Real:

At 37signals, all of our support emails are answered personally by the people who actually build the product. Why? First off, it provides better support for customers. They’re getting a response straight from the brain of someone who built the app. Also, it keeps us in touch with the people who use our products and the problems they’re encountering. When they’re frustrated, we’re frustrated. We can say, “I feel your pain” and actually mean it.

Most people who buy Mac software from independent developers know that it’s only 1-5 people behind the company. We can’t compete with the Microsofts and Adobes of the world on application size, but we can compete on quality customer service. Being small is a competitive advantage.

I’ve exchanged at least a couple hundred emails in the last few months with customers or potential customers. (I don’t actually distinguish between users who have bought the product or who are just trying it out. They all get the same level of support.) Have I handled each one perfectly? Probably not. There are a few people who are still experiencing problems. But my hope is that just writing this blog post will serve as a guide and reminder of why taking support seriously is worth it.

Reflecting on WWDC 2006

WWDC 2006 was great. (Yes, it was two weeks ago. Finally making time to blog again.)

I won’t dwell on the announcements too much, but I generally agree with some that there was nothing earth-shattering. We have only seen a part of what Leopard will become (an improved Finder and some unification of window and control types seem inevitable). The most exciting stuff is new APIs for developers, not flashy end-user features.

I had a great time hanging out, catching up with people and meeting new folks too. Buzz Anderson’s “Monday night party”:http://weblog.scifihifi.com/2006/07/23/party-time-excellent/ was excellent.

In addition to the new Leopard goodness (hello Core Animation and Interface Builder), I also came back with new excitement for a side project that I have been working on: an email client. I had stopped active development until hearing what Apple had planned for Mail.app in Leopard, but now I can safely say that they are going in a completely different direction than what I want to focus on.

Threads like “this one on Hawk Wings”:http://www.hawkwings.net/2006/08/21/can-mailapp-cope-with-heavy-loads/ (via “Steven”:http://stevenf.com/mt/2006/08/big_mail.php) also confirm that there are a number of users out there who want the same kind of things I want in an email client. Of course it has to be fast and scale, but I think I have a few twists on the old formula as well.

In San Francisco we also stayed an extra day and visited the Oakland museum, drove up to Point Reyes, and saw a great musical Friday night: “Putnam County Spelling Bee”:http://www.spellingbeethemusical.com/. I recorded a bunch of audio for an upcoming podcast, although not as much as I probably should have. There were a few times in particular I wish I had taken my microphone out.

Email mistakes

John Gruber: “The elephant in the middle of the room, of course, is Apple Mail.”

For a while now I have regretted switching to Apple Mail. But this is not unusual, because I have regretted switching to every single email client I have tried since the Eudora days. Let’s face it — Eudora’s ugly, but it was a rock-solid app.

The first big mistake was moving to CyberDog. There was a lot to like about that app, and I was a big fan of OpenDoc, but even today I have a bunch of mail stuck in its proprietary formats. I need to boot into Mac OS 8 and extract that stuff one of these days.

Then I moved to Mailsmith. Unfortunately I lost mail due to corrupted databases. I have no idea how to get that stuff out. Even so, the 2.0 release sounds nice, and I’d be willing to give Mailsmith a another try. I’m stupid that way.

Back to Apple Mail. If you are ever confused enough to think it’s a great app, try this: delete a single email message in a folder containing 2-3 thousand emails. On my TiBook, the OS locks for a good 5+ seconds.

The saving grace of Apple Mail is that it is easy (presumably) to get out of it — they use standard unix mbox files for everything. Thank you Apple.

Now I’m at WWDC, and Steve Jobs just demoed the new Apple Mail. Pretty nice stuff, but no mention of performance. I’ll wait to dump Apple Mail until trying Panther, which I’ll install on an external drive sometime this week. Or maybe I’ll just get a G5 desktop and not worry about performance anymore.

It’s going to be a fun week.

James Duncan Davidson, author of

James Duncan Davidson, author of the upcoming Learning Cocoa (2nd edition), has a new blog. He’s already started rolling with thoughts on preserving his blog posts:

“As long as I can make sure that my data migrates to long lasting media at some point, I can protect them and read them far into the future. However, when that migration happens, I may have all my data, but I’ll have no idea when I wrote it. You see, all those filebase time information will be blasted away when I move the data onto a new filesystem.”

I’m using Radio for this site, and it can automatically archive blog posts to XML files. That is definitely a step in the right direction, and more than most other products will do. It is particularly tricky to get data out of Blogger.

And I still have too much email stuck in old proprietary formats that I may never be able to retrieve completely. Sigh.