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.
- 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.
- 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.
2 comments:
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.
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).
Post a Comment