I think the subtle point here is that users don't want bloated applications but
1) They will vocally advocate for additional features that meet their specific needs
2) They will buy upgrades (particularly of boxed software) based primarily on new/additional features
The nice thing is that this problem of desktop applications hasn't actually translated directly to the web. On the web, doing one thing well is much more valued on than on the desktop.
I suspect that this is because more users understand and feel comfortable with the web than feel comfortable with the non-browser desktop.
I think the key aspect is that adoption of web software is easy, and most web software (e.g. gmail, google maps, flickr, twitter) is free, or at least has a reasonably useful no-cost usage tier. This may contribute to users feeling they are less locked in to a single application, more able to switch to a competitor if need be, and more able to use additional software to provide additional functionality (e.g. twitpic + twitter).
The author appears to conflate feature-bloat with "rich" web UI platforms. This doesn't have to be the case.
When I'm making something using Flash, AJAX, scripted SVG, or <canvas>, I like to think in terms of which UI elements can be simplified or eliminated by having a more expressive interface.
For example, AJAXified controls can eliminate the need for a "save" button in some forms, drag-and-drop can simplify moving and reordering operations, scripted SVG can bring sanity to working with tree-structured data, AJAX polling or Comet streaming can eliminate UI actions like page reload or manually checking for updates, etc.
I bet most of the MS Word features could be replaced by a single scriptable extension feature.
It's a little more complicated than to just keep it simple. Spamming a bunch of simple features is bad, but more complicated (high quality non trivial) features is almost never bad. So basically anything that most people can't script themselves, like a face detection feature or something like that, would be a great feature to implement, whereas something like linking Entourage with iCal (which is horribly implemented in Entourage) is a shitty feature. A bunch of these simple things which offer little value and must be customized for individual uses anyways may as well be implemented as extensions instead of features.
MS Word already has a comprehensive scripting extension system, it's called Visual Basic for Applications. It's been in there since at least Office 2000. It gives you programmatic access to nearly everything in the application you're scripting.
Yes, but the community can develop the extensions for various purposes instead of Microsoft developing everything. That's what I meant. Obviously most word users don't know scripting and don't care to learn.
Good article though it's worth appreciating that leaving things out is not just about adding less it's about knowing more.
You need to know which tools your users actually want to use. You need to know which order they use them in and when to present them. You need to understand what people are doing with your app and how to strip everything out except what they want next.
Focussing on a minimal set of features lets you focus on a minimal set of customers. Instead of half-serving two ill-defined groups with a chimera application you service one well defined group with an application of clear value. Saying "no" to the ill-defined group isn't always easy though.
Users do not generally want less. It is not unusual in Corporations to actually compare features before a buying decision and there is always a strong perception that the software has more value if it has more features. It also ensures that your competition always stays a few months behind you.
B U T, users want simpler interfaces and quick ways to find something. So KISS the UI, but complexify the rest may be one good proposition.
If you consider library API's as a UI for coders here is an example from jQuery:
$().css(data);
NOT
$().getCss(data);
$().setCss(data);
More complexity in the library, less complexity in the API's UI.
Neil's point is basically "KISS", which is excellent advice. I wish he had also talked about the other half of the statement, though: figuring out what users DO want. In my experience, the tricky part is not keeping it simple, it's knowing what to build. Really effective advice on how to determine what people really want...now that's something I would love to read.
To determine really what people want you need to be the proto USER, you need to understand the needs in solving a problem and what the outcome should be.
Great software ideas that stood the test of time were mostly developed by someone that wanted to solve his own problem first.
I would start with Knuth and TeX. He wanted to solve his own typesetting problems. I will leave it for others to add more examples (Lotus? AutoCad? HTML?)
Spolsky said it best: the average user will only use 5% of the features in your do-all app, but each user will use a different 5%.
Twitter doesn't count because they didn't solve an existing problem, they invented something new that everyone found useful. Apple doesn't count because they target the small niche that does things the Apple way. They don't try to appeal to everyone, unless they are manufacturing appeal like Twitter.
The web doesn't count because it's easy and cheap to try out new web apps and to use many of them at once. You don't have to shell out for one vendor to solve all your problems. It's just too bad that web apps can't really talk to each other.
You have to give Microsoft credit for embracing diversity. They try to solve everyone's problem and they pay the price in complexity. Perhaps a more connected web or a more responsive open source ecosystem can replace the MS mega-app, perhaps not. There is a lot of dirty work out there that nobody else wants to do.
It's easy to get caught up in adding features with the belief that adding X or Y feature will help you get a little bit more market share. When in reality, you should be focusing on doing something simple, but doing it really well.
Barry Schwartz (The Paradox of Choice) puts it best: "[as people are given more and more options they] become overloaded…. Choice no longer liberates, but debilitates. It might even be said to tyrannize."
I found that especially on enterprise software, being web-based limits the amount of damage a mediocre programmer can do. Of course there are myriad ways of messing up the web experience, but native apps have all the OS resources at their disposal to make your life miserable. And when the OS is Windows, well...
There's something to be said for a simple Google-esque user interface, but I can't think of any time when a user has contaced me and said something like:
"I think the software you've written is perfect - it doesn't need any more changes and it does absolutely everything I want it to do".
" Assuming you’re not one of the 10% of people who “power-use” Word"
Where did that statistic come from? Word is essential for students and most of its features, especially the word count, the thesaurus, the referencing for the footnotes, the formatting of paragraphs, the spell checker, I can't actually think of anything that I do not need and even if I did not, word loads quickly, its interface is somewhat simple and kind of intuitive, so why should I care about some hidden feature which I do not use.
Doctors use word, dentists, lawyers most certainly, every office in the country uses word, every school, really only my grandma does not need word!
I think the author was actually emphasizing the point you made about "why should I care about some hidden feature which I do not use". The 10% of power users he was referring to are the ones who use far more than the features you stated. Those features you stated are actually general features which most people use, but these are just a small subset of the vast feature set that is available for users within Word. Most users don't even know these "extra" features exist, let alone what they do and how to use them.
