TANSTAAFL

It is almost 4 years since my first application was released and there is a threat on the horizon. The threat of feature bloat. Becoming the dreaded bloatware. Each new version added something to be more (or less?) powerful. When I watch people working with the application, I can see they are only using a tiny portion of the features. Adding a new feature may actually make the experience worse for them.

If you are wondering how I am able to watch people working with an application, it is through youtube. Granted, videos recorded by users just for fun and posted on youtube are not a representative sample. There may be people, who dig a bit deeper and find some of those useful features I worked so hard to implement. On the other hand, maybe things are really that grim. In that case, feature bloat is a very real problem for me.

Ways to deal with the bloat

What one user considers bloated software application with lots of unnecessary functions can be exactly the right thing for another user. Newbie users would like to have the simplest possible application that accomplishes their task. Experienced users would expect each new version to deliver more advanced features.

While it is sometimes possible to simplify a function yet make it more powerful, it is not always the case. What to do in cases, when extending the functionality makes an application more complicated? There are multiple ways:

1. Once all the crucial needs are covered, stop adding any significant new functions. Good for newbies, but experienced users may complain that the software is not evolving and look elsewhere.
2. Keep adding features and embrace the bloat. Experts will be happy, but the learning curve may become very steep making new users very unhappy.
3. Re-invent yourself in each new version. For each added feature, remove another one. This way, the bloat is reduced, the application is evolving, but expert users can be a bit irritated by the fact that their favorite features are being removed and they must partially re-learn the application with each new version.
4. Branch the application. Make a Lite and a Pro version, targeted at different users. There is of course the risk that even newbie users choose the Pro version, because people want “the best” for themselves. Also, two applications instead of one must be maintained.
5. Make an adaptable user interface. This is a variation of number 4, but distinct enough. The adaptability may manifest itself as the personalized menus in Microsoft Office XP or as the plug-ins in the Firefox browser. Effectively, there are multiple interfaces and the maintenance and support costs are rising. The personalized menus were considered a nuisance by some users. Firefox’s plug-ins make upgrades difficult as plug-in authors must check/update their plug-in for each new version. This is not an easy path to walk.
6. Focus on educating users. Each added feature must be placed properly in the application and introduced to the user in the right moment. This is very hard. People usually do not read documentation. They just look for familiar things and explore the application as long as it amuses them. If they run into a complex feature before they understood its prerequisites, or if it is not introduced to them when they are able to comprehend it, their attention is wasted. In short, distance education is hard.

Which path to choose?

The mentioned approaches cannot be easily combined (with the exception of the last one). While you can try to combine more than one approach, I would advise against it. Each approach has its costs, its weak and strong points. Combining them may cancel out the advantages and you still would need to pay both costs.

I cannot recommend you the best approach. The best depends on your application and your long-term plans. What I can do, is give you a couple of examples (my field is computer graphics, so do not wonder that I am using graphic tools as examples):

#1 - freeze

Few years ago I did a very simple application for photo resizing. I took path #1 and refused to add any new significant features. While the change log is pretty long, do not be fooled with it, all those are mostly trivial 30-minutes changes. I chose not to add support for non-.jpg pictures, refused to give it proper user interface or features for rotation, cropping or canvas extension. Approach #1 is suitable for very focused products for non-expert computer users. There is a lot of them.

#2 - bloat

Adobe Photoshop is is typical example of the second approach. They keep adding features to their already overloaded solution. They can afford it, because they are considered the best. Their application is hard to use for newbies (the existence of hundreds of sites with Photoshop tutorials is a proof of this fact). Newbies still invest their time to learn to use Photoshop, because it is considered best. It is a closed circle. Because you are best, you do not need to focus on newbies. Newbies invest their time to learning to use what they consider the best. Hence, if your product is considered the best, you can adopt approach #2. Just do not overdo it or you’ll lose too many newbies. This does not work for the second best though ;-).

#3 - reinvent

I am actually having a hard time finding an example application for approach number #3. I might be walking on a thin ice, but I believe Office 2007 or Windows Vista could be considered a fairly good examples. There was a significant overhaul of the user interface in both cases. Experts were irritated, but Microsoft had no other options. If you are unwilling to focus just on experts or just on newbies, and cannot persuade the newbies to learn the advanced features, approach #3 might be the right way. Making product for everyone is like politics (eeek).

#4 - split

Approach number #4 is quite common. There is a lot of Lite and Pro versions. Often, there are also different licensing terms, Lite being free and Pro being paid. It makes sense, those who invest their time to learn the application usually use it in business scenario and do not mind paying for it. But there are people, who do not like using Lite versions, they have the feeling that the Lite version is just a demo and developers do not pay attention to it. I have never seen a Lite version become popular, it does not get the attention of media, because there is something better: the Pro version. But that does not get the attention either, because it is paid and has to stand against other commercial products. In general, avoid approach #4. If necessary, split product by use cases into non-overlapping applications.

#5 - adapt

Firefox and its plug-ins. It is very customizable, experts can find the right plug-in just for their unusual needs and newbies get an easy-to-use application. This is very nice, use approach #5 if you can afford it. Developing an application with a solid open interface is more difficult than a monolithic one. Then there is a trust and stability issue. Are the plug-in authors trustworthy enough? What if I install plug-ins from 2 different authors? Would there be a conflict? It is impossible to test every combination of plug-ins. Designing and maintaining a flexible system has its costs.

#6 - teach

Do it. As much as your resources allow you to. You cannot go wrong by explaining users how to work with your application.

Summary

None of the solution is perfect, some may only work for a limited time. Depending on your situation, you may need to switch from one approach to another one. The important thing is knowing, where you are now and where you want to be in a couple of years. Then the right choice may just seem obvious.