Joel Spolksy is right about simplicity and the 80/20 rule:
“A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%. Everybody uses a different set of features.”
Simplicity is a goal all developers should strive towards, but it’s a mistake to think that simplicity means having a small feature set. You’re rarely going to sell more copies of your software by providing less features.
If you want to sell more copies, focus on figuring out which are the features that 80% of your customers want and make them obvious, then make the other features less obvious but still easily accessible through a menu item and/or keyboard shortcut. That way new users aren’t overwhelmed by the sheer number of toolbuttons staring them in the face, and power users aren’t underwhelmed by the lack of features.
The hard part, of course, is figuring out which features fall in the 80% category. If you hide a feature that 80% of customers want, they might not try your software long enough to discover that it actually does what they need.
This is one place where beta versions come in handy. Beta versions don’t have to be used just to find bugs: they can also be used to figure out which are the most important features.
Sometimes in beta versions I’ll deliberately remove (or obscure) access to a specific feature just to find out if people really use it. If a lot of beta testers complain about the feature being removed, then it’s an 80% feature that needs to be an obvious toolbutton. If only a few complain, then it’s a feature that only 20% want so it can be demoted to a menu item.
If you’re a developer, take a look at your UI and try to figure out whether all those toolbuttons really need to be there by default. Chances are you can hide a lot of them, which will make your application simpler to learn without making it any less powerful.
I was thinking on posting about Joel’s article. To me the real solution is a software product line where a short interview allows a user to generate their own customized solution with the 20% of the features that they need.
I posted a little about this some time ago and I think you’ll hear a lot more about these approachs in 07 and 08:
http://www.pbell.com/index.cfm/2006/8/15/What-am-I-doing-The-ultimate-Software-Product-Line
Nick, you are one of my ‘shareware heroes’ and I absolutely love your insights on software development and the microISV-ing in general.
It’s a pity you don’t write often on these topics. It would be great if you share more of your philosophy on software design.
Joel is spot on with this, and I think one example of this flaw can be found with what the Microsoft Office team did with their Ribbon. They all but hid their keyboard shortcuts while adding larger and more icons to their ‘ribbon’ — all under the guise of showing off more of say, Word’s features. And instead of taking advantage of current widescreens and allowing that huge ribbon to be docked as a sidebar, they said no.
Without customization, Office’s ribbon becomes a ‘take-it-or-leave-it’ UI, making Microsoft appear to be fascinated with what they “could” do rather than what customers wanted.
Another option is of course to actually monitor this. E.g. as per google toolbar ask users if they mind their usage info being stored and polled to a data collection service and see which are the actual features users are using.
How valuable could that info be?
Jensen Harris’ blog (http://blogs.msdn.com/jensenh/default.aspx) covered how Microsoft addressed this issue in great detail – in particular drawing on an immense usage database collected through their customer experience programme.
The general consensus appears to be positive towards the beta of Office 2007 and the interface certainly doesn’t seem threatening despite the immense feature-set of the MS Office products.
Thanks, Boris – that’s very flattering. I agree that I should write about developement more often, and I hope to (finally) do that over the coming months.
Zaine, while I understand your point, I have to disagree with you about the ribbon UI. I think in Office 2007, Microsoft really paid attention to what their customers wanted: a simpler UI that enabled them to more easily focus on the task at hand.
I agree with Boris, Nick. I’m not a developer, but I use a lot of software on different platforms and I know what I like and I find it interesting to learn the process behind it. Often I will try an application because I like the developer’s work and style. That’s certainly what started me with FeedDemon! :-)
Slightly off topic Nick, but have you ever considered using TestRecorder (optionally of course) in a beta and parsing the results to see how at least your beta testers use FeedDemon and TopStyle. I know they are both “open apps” so you are “80%” there. ;-) I’ve hought about this off and on over the years and a recent podcast of Jon Udell as well as your blog is making me think about doing it in my own apps.
–Greg
good points, and, if your toolbars are customizable anyway, users who want ‘hidden’ features can add those buttons themselves if they want.
Greg, I have thought about using TestRecorder, but not for that purpose. That’s an interesting idea…
That is a good idea, but one would have to make dang sure that any potential beta testers knew darn well it was being used (and why)
Hi:
I’ve experimented with intelligent UI’s before such that the application monitors what the user does and moves those options to the forefront to make them more available. After a while, the application often looks very different between users.
I think this technique is something to consider in future UI’s.
tedd