Posts tagged giantcomet
Matt Gemmell wrote a great article recently that’s been making the rounds about supporting only the lastest version of an OS for your app. I highly recommend reading if it you haven’t already.
Matt covers a few reasons: less hassle, less code, better customers, free marketing. I won’t rehash it, but wanted to add one other point: making a better app. If you’re a small shop — particularly if you’re solo developer — you have limited resources. Everything you choose to add (or not add) to your app is a balancing act. You’re probably using a single version of an OS yourself to develop the app, so you’ll never be able to test the app as well on other versions. Being able to write less code, and do more testing will result in a better experience for your users.
When I was developing Flint, I originally supported Snow Leopard and Lion throughout the beta, and dropped Snow Leopard before release. Why? Besides the obvious reasons Matt mentioned, like less code and hassle (I deleted a lot of code going Lion only), it allowed me to make a better app. I no longer was a Snow Leopard user. I built and tested the app on Lion. I had my old Macbook Pro still running Snow Leopard, so I fired that up every couple of builds, and made sure it ran. But I couldn’t give it the amount of attention I gave the Lion build, the one I was using all day, every day. I wouldn’t find the weird bugs and behaviors that happen in edge cases, or only reveal themselves after extended use. I won’t find all those in one operating system, much less two.
In the end, I sacrificed having more customers to have a better app. For a brand new app, with no existing users to upset, it was definitely the right choice. Every day, there are more Lion users, and less Snow Leopard users. In six months, Lion will most likely be on a majority of the machines, and I’ll be ahead of the curve, with no legacy code to support. I can just focus just on what matters, making a better app.
I just submitted Flint 1.0 to the Mac App Store this morning. My goal was to finish it and submit by September 1st, 2011, and it took about 6 more weeks, which isn’t too bad all things considered. It was time well spent. I got more beta testers, added a few more nice features, and fixed a lot of bugs. But still, I had more that I wanted to do. I just kept thinking about adding one more little thing, one more tweak.
Whenever I’m at that stage of a product, I think of two quotes. The first is the famous quote by Steve Jobs, which conveys so much for being so succinct. In light of Steve’s recent passing, it takes on a new urgency for me to build and create and put things out there.
“Real artists ship.”
– Steve Jobs
The other that I always come back to is this tweet:
If I knew Rands personally, I would have thought he wrote it about me, as I’m particularly prone to that behavior. It’s never good enough for me, there is always more to do, more features to add, more bugs to fix, it will never be finished. So it’s a question I always have to ask myself while at the end of a product, am I improving or just tinkering? If I’m tinkering, it’s time to ship.
I think I should get posters of both of those quotes and hang them above my desk.
For the last couple of apps I’ve made, I’ve been creating a sort of mind map to help me come up with the name. Finding a good name for an app is hard, but having a somewhat formal and repeatable process has made it much easier for me.
I say “sort of” mind map, because there aren’t really any strict rules I follow about organization/hierachy/line length/color/etc. It is more of a free association with a bit of structure. I write any words that come to mind, and connect them in whatever way makes sense. I try not to filter myself at all, because while I know I won’t use it as part of the app name, it may lead to something that will.
Here is an example of the map I created to name my most recent app, Flint, a Campfire client:
Excuse my sloppy writing, I usually create these fairly fast, and I’m the only one that ever needs to read them.
In this case, the words were anything related to camping, fire, or chatting. I could have taken it much further, but I found a few names I liked, and settled on Flint. Note, this is designed to create the kind of names I like for apps. Short, preferably one word, that has some connection to what the app does, however thin that connection is.
When the Mac App Store came out, I decided to update my app – Spot Color, and release it as a new app called Hues. That’s caused a bit of confusion about how Hues is different from Spot Color, so I thought I’d explain a bit of the differences and reasoning.
Spot Color was just a wrapper around the built-in Mac OS X color picker, and had no features of its own. It allowed you to use the color picker as an app, and wasn’t useful without installing some 3rd-party plugins. My main goal with Hues was for it to be fully featured and stand on its own without needing any other plugins. With Hues, you can grab colors, get the Hex, RGB, or HSL out of it, custom format the outputs, have the value automatically copied to the clipboard, and view a history of recent colors. All of those features are new to Hues, and didn’t exist in Spot Color.
To avoid having two different color pickers with the same icon, different features, one free and one paid, I decided to just get rid of Spot Color, changing the name to Hues in the process to make it clear it was a whole new app. I thought it be too confusing to have both out there. Plus, I wasn’t going to update Spot Color anymore, so thought it best to remove it.
If you liked Spot Color, I think you’ll love Hues.