20 April 2009

Customizability in Applications

One thing that bothers me about software fairly often is the lack of customizability. This is one of the strong appeals of open source software and operating systems, in that they seem to be built with customization in mind. Proprietary software typically has a specific feature set that it is built around and tries to be as consistent as possible so as not to confuse users. This post is about thinking through some of the issues associated with customizability, some ways to handle it, and some software that I think does it right.

There are two big issues I see associated with building customization into software:
  • Time and Cost -- Customizability is really just another feature that you have to build into software, and it's a big one, especially if you don't design with it in mind from the beginning. The problem here is also that for each new feature you add, you also have to add customizability for that feature so the development time has the potential to increase quite rapidly with the more features you add.

  • User Experience Failures -- This is an interesting side effect of customizability. There is the possibility that by allowing customization of certain features of your application, users will be come confused by inconsistencies. This becomes even more of a concern when thinking about the ability to use the software from any computer and expecting it to behave in a similmar manner. If issues like this arise, it can lead to increased support costs.
Regardless of these issues, I believe that customizability is almost always beneficial to software. Some of these benefits include:
  • User Control/Choice -- Users are given control to shape the software to do what they want it to do and little more. This allows the software to appeal to a wider range of users.

  • Avoid Feature Bloat -- Rather than try to handle a majority of user scenarios in your software, including fringe features which may be very valueable to some users but rarely used by the majority, you can allow users to customize the application to include the functionality they actually need. This cuts down on core development time, especially if you crowdsoruce the production of the fringe features to the community itself. Office apps in particular struggle with the 80/20 rule of feature usage, and I think Zoho could do well to mitigate this problem by exploring customizability for their applications.

  • Platform vs Application -- By thinking about customizability, you might find an opportunity to transform your software into an application platform rather than a specific application with specific purposes. This will allow the software a far far larger appeal. Twitter is a great example of programming to a platform instead of an application. They could have easily have gone a different route.
There are a few different ways to implement cutomizability in an application:
  • Plug-in Architectures -- Probably the best way I can think of to make your application very customizable is to build the base application that captures the most important or most used functionality, but build it in a way that allows people to build plug-ins that can be easily added on top of the application. This allows the application to take advantage of the crowdsourcing mentioned earlier, especially if you make the plug-ins easy to create. There are a number of examples of this being implemented well including Mozilla Firefox, Lotus Symphony (built on the Eclipse Framework), and Wordpress. Google does a similar thing for Gmail, but as far as I know these are still developed by Google Engineers. I have yet to see a hosted web-app that allows user contributed plug-ins. If anybody knows of one please let me know.

  • Configuration Settings -- Most apps have some form of "preferences" page or configuration settings that you can tweak. Unfortunately these rarely go far enough to allow true customizability of an application. The other problem is that these configuration settings are rarely able to be synched across computers, which means each time you change a setting for an application, you need to change that setting on other computers you use that app on as well. This is also a problem for plug-ins, but Mozilla has an interesting solution to the problem they are developing called Weave (It's still in developmet, but you can host your own instance of it if you want to play with it).

  • Personas -- Similar to configuration settings, it is sometimes useful for people to aggregate particular settings into profiles or personas. For instance, I might want a certain configuration of a word processing application when I am writing a professional memo versus when I am writing poetry. It would be useful to be able to switch between personas with the click of a button. Once again Firefox comes through here with Profiles, but that is not the most useful solution in many applications as it requires you to restart the application

  • APIs and SDKs -- I'll only touch on this one, but the ultimate in customizability is to open up some of your functionality and data through web services or some other programming interface so other developers can actually build other applications on top of your core. This is the final step to becomming a true platform and there are many examples of this being done well, including Twitter and Eclipse.
All in all I think customizability is typically worth the effort and users appreciate it more and more, especially as it becomes more mainstream. That being said, not everybody agrees with me. Apple is probably the poster child for anti-customizability. They like to control every aspect of the user experience and make sure that their software/hardware has a consistent feel throughout. While there are some benefits to this method, in my opinion it is more annoying than anything, because if you don't like the way Apple does it, you can't really change much. Even when they allow developers to write apps for their hardware, they like to control as much as possible how those applications function and are distributed (read: the iPhone Apps dev process sucks)

2 comments:

Nick said...

37signals is a big proponent against the customization of their software (as far as giving the user options in their software). I like a little bit of customization in software, but not too much. There is a wide gap in-between no customization and having everything available in an API. There are a few winners, and quite a few losers in this space. I like IBM's approach to customization - This video shows how users can customize their web 2.0 experience.

Kevin said...

That video is really cool, I still don't understand what their tools do from it exactly, but the animation is really sweet.

As far as 37signals is concerned. I find their outlook funny especially considering I used basecamp for a while but stopped because it did not quite have the features I needed and I couldn't tweak it to make it work. Even in their Getting Real book section about preferences, they quote a tech lead from Red Hat talking about how preferences are useful but do have a cost. Obviously.

Also that page talks about how preferences are worthless b/c it means developers are lazy for not making a decision. That's a stupid philosophy because while it is important to pick smart defaults, not all of your customers are going to go for those defaults. You need to analyze the cost/benefit of adding customization to a piece of software, not reject it entirely. Also the costs can be mitigated by some of the methods mentioned in my post (especially user contributed customization).