Posted By Paul Kafasis on December 11th, 2004

A few days ago, I wrote about three things users do when requesting a feature that can irk developers. While doing so, I wrote (and then cut) a large section on how we consider features for ourselves. However, this makes for an interesting discussion on its own. Below, you will find an overview of some of the things we consider when contemplating a new feature or addition.

Can it be done?

If it’s possible, we can move on to other considerations. Some things simply aren’t possible – Nicecast will never be able to broadcast out over the FM bands, for instance.

Is it feasible and reasonable?

Just because it’s possible doesn’t mean it can be done in a reasonable time frame. Given a decade, we could probably code decent voice recognition and make all our apps voice-controlled. That doesn’t mean it’s a good idea.

Is it valuable to a reasonable percentage of users?

When someone requests a feature, he no doubt has some use for it in mind. But does this user represent a larger subgroup? Or is this an obscure request with no benefit for others?There’s often another flawed mindset at work here. A user will often assume that because he wants a feature, many others do too. Many times, this is absolutely true, but it’s certainly not true by default. The mere act of requesting a feature does not mean there are hundreds of others who also want to see it. But that’s another crotchety rant for another crotchety day.

Does it fit the app (1)?

Is the feature relevant to the product? Audio Hijack Pro records audio from RealPlayer, but it’s not responsible for making sure RealPlayer is working properly, in the same way a VCR isn’t responsible for making sure the cable service is working.

Is it easy to use?

Once we’ve come this far, we need to know if what we’re planning will be easy for a user to understand. Adding a great, powerful feature is near-useless if no one will ever be able to figure out how to use it, and no amount of documentation can take the place of a simple design.

Is it marketable?

This is an odd item on the list, but it’s a necessary consideration. Every hour spent developing a feature is an hour spent NOT developing other features. The features that are likely to attract the highest numer of customers are the features considered first – that’s simply how a business must be run. This is not to say we exclusively add features we expect to make money, but that there is a certain capitalistic method of deciding what will be added, especially in terms of major features.

Does it fit the app (2)?

We established that this feature is germane to the app in version one of this question. Now, the question is, does it belong inside the suggested application, or should it be a separate application? Detour was first suggested as an additional feature to be added to Audio Hijack Pro. We could have done that, but it doesn’t truly fit. It makes much more sense as a separate application, so that’s where it is.

Once a feature makes it this far, it gets added to our infamous “list”. Placement on this list doesn’t mean much, but everything on it is considered worth adding and will eventually be added. So there it is, an overview of how the process we ourselves consider features for addition. Do you have your own feature request or suggestion for one of our products? We’d love to hear it, so drop an email to <productname>@rogueamoeba.com.