On Simplification and Adding New Features
Simplify, simplify, simplify. It should always be one of your goals when designing and developing software. I'm a big fan of simplification. There's a certain elegance and single-mindedness to a simple application. But there's at least one problem: for every user who wants an application to stay simple, there's at least one other who is demanding feature "X."I'll use MacGourmet as an example. Version 1 started with the "keep it simple" goal of not adding too many features, of keeping things almost to a minimum. Some people liked the application this way. Soooo many others demanded more fields, nutritional calculation, menu planning, more publishing options, more printing options, more import and export options... well you can see where this is going.
It's really, really hard to do both: add the features users really want, and keep things simple at the same time. For instance, there is just no easy way to add nutritional analysis and menu planning to MacGourmet, not without complicating things somewhat. Each of these features requires new UI elements, and new organizational elements. You need to somehow incorporate them into the user interface, without overwhelming it or cluttering it up, and this takes time and thought, and well, design.
On top of meeting the demands of your users who want more, there's the drive to "release or die," the reality that in order to keep your application selling and generating revenue, you have to keep doing releases and updates. Beyond bug fixes and minor enhancements, this usually means new major features, especially if you want need to charge for your upgrades.
Finally, as if all this weren't enough, it really doesn't matter what people ultimately use and what they don't, when purchasing and picking their application from a group of competitors, they will often ultimately pick based on feature set, whether or not they will use all of the features. Then, however, they don't want the unused features in their face while using the application. It's a difficult balance to maintain.
So, what's the solution? How do you keep things simple, add new features, and keep making money? There are many schools of thought on this.
The first one is pretty much K.I.S.S (Keep It Simple Stupid). Essentially, just don't add major new features, Keeping things simple, and very focused instead. This works, if what you are doing will always appeal to new users over time, and what you are doing satisfies enough people. This path can suffer though, when your application is compared to competitors in the same space.
The second possibility is some kind of adaptive UI. Microsoft tried this with Microsoft Word, hiding little used features and menu items, but I personally found this maddening. Things would just disappear if you hadn't used them in a couple of weeks, forcing you to try and remember where it was in the first place, and to search for it's location if you didn't remember.
Finally there is the plug-in route. Start simple and let people add things "a la carte," instead of loading up your application with a bunch of features, all of which next to no one will use in their entirety.
I chose the third method for adding major new features to MacGourmet. Plug-ins allow you to add and remove features as desired. They also allow me to keep MacGourmet, at its core, much simpler than if every feature that every user ever wanted was added to the base product. I've already received some push back from people who say MacGourmet 2 is more complicated than the first version, and they're right, it is, but that's only because so many people had been asking for so many things.
Starting with Nutrition, major new MacGourmet features will be made available via optional plug-ins, some free, and some at an additional cost. Doing this, however, will allow the base application to stay as simple as you want it to be, and hopefully I'll be able to maintain the "free upgrades" path that it's been on so far. Don't read this the wrong way, there will still be major improvements to the "core" application, like a much improved shopping list (which has already been redesigned) and other features that are considered essential to a basic recipe application. The good news for some of you, if all you want is the basic application and if this method works, is that you'll probably keep getting improvements for free. So long as the basic application keeps paying its way with new users, there shouldn't be a need for upgrade fees.
Labels: Indie Mac Software Development, MacGourmet, Musings
Digg This | 
Post to del.icio.us
posted by Michael on Thursday, September 20, 2007
|
0 comments
What else caused a delay? Well Apple announcing Intel Macs at Macworld 2006 and shipping them in February greatly sped up my plan as to when I was going to do all of my universal binary work. They had originally said that there would be no Intel Macs until around July. MacGourmet 1 benefited, because I had a universal version available a lot earlier than I had expected, but it also set back other development. I was almost hoping that only version 2 was going to need to be a universal binary.
Making MacGourmet universal actually wasn't that bad, the hardest problems were with 3rd party products I use. I had to wait for eSellerate to update their framework, and when they did, they required a switch to a different SDK, so that was a project I wasn't expecting to have to spend time on. Because I use my own SQLite build, I also had to build both SQLite 2 and SQLite 3 as universal binaries. Again, more work I would have preferred not to do when I did it.
Well it's that time again, a time when I like to look back at the year that was and take stock, and gaze out at the coming new year a bit.
