Build Your Own Features
I've been reading Nick's series on simplicity; all good thoughts and definitely true in many cases (in particular, the checkbox hiding a universe of complexity). His latest, on power users, really got my interest. The core of Nick's post is in these two paragraphs:
Power users will request features that nobody else wants, and they'll ask that existing features provide a ton of options that maybe 1% of customers care about. More than anything else, power users want to be in control of the software they use, so they'll choose something complicated over something simple if doing so leaves them in charge.
The tradeoff is between keeping power users satisfied and working on areas more appliccable to the majority of your users. It's quite true - your power users can be a pain in the neck, because you as a developer tend to be at their beck and call. But I'm not sure that these are mutually exclusive goals.
I dabbled in building Firefox extensions a couple years ago, and I discovered one very interesting thing about Firefox: the application itself seems to consist of a rendering engine, a Javascript interpreter, and a whole lot of XUL and Javascript that comprise the actual, visible Firefox application. I'm probably greatly oversimplifying, but the point is that the "browser" as such seems to be implemented entirely in XUL; making the extensions written by people like me not too different from the application itself. Since then, I've found that to be true of a number of applications. I've found a number of applications that are really programming platforms in disguise - Emacs, or Frontier, for example. It seems to me that turning your power users into programmers is a pretty good way to allow those users to scratch their particular itch without necessarily having to do that for them.
That said, an application must be architected much differently to do this. You would need to approach your application as a set of components held together by some sort of glue - Javascript, VBA, or maybe a DSL. You would need to address extensibility outside of the scope of what you as the designer have found necessary - Mozilla's XPCOM, for example. On a Windows platform, you could do this via ActiveX, in a managed language you can define extensibility interfaces as well, or allow your users access to the typeloader or classloader. But the effect is that this now puts the programmer and the users onto an equal footing; you're both using the same tools to create or extend the application. In fact, what you have is a platform, and both the programmer and user are writing extensions for the platform.
This holds true for web applications, I think. The difference here is that you need to stop thinking of your application as a website. The website exists as a face on components that you've created on the backend. Naturally, for these components to be useful to anyone else, you'd have to expose them as services. There's entirely too much effort directed at the basic problem of putting a web frontend on a database. This is obviously a vital goal (at least if you have a database that you want to put on the web), but it leads one into a shallow architecture - a one or two tier architecture that minimizes the distance between the user and the database - not really a bad thing, particularly if you're trying to get something done quickly, but it now makes you, the developer, the sole arbiter of that interface, because all your users have no way of interacting with your data outside of the mechanisms you've chosen. If your users are ambitious enough, they'll come up with ways to scrape the data out of your HTML and compose operations of their own, but this is almost never ideal - changes in markup can break their applications, and the user's approach will probably not be optimal in its use of server resources.
Of course, Nick has authored several wildly successful products, while I'm saying this as more of a statement of philosophy. Still, I think that the point holds - when applications are written as an extension of a platform, you are now dealing with your users in an entirely different way.