Screw the power users
nick.typepad.com
nick.typepad.com
Poor design. Seriously. Simplicity is really really hard. Much harder than throwing a ton of settings, toggles, and switches at a user.
Your design has to be ridiculously simple, but be flexible enough to allow complexity when it is called for. It's hard to put into words, but I frequently spend months refining an interface to fit just right.
The best example of this is an operating system. Windows has to be simple enough for the least computer literate person to use, but flexible enough for you to configure anything you can imagine via the registry or command line. There is no link to the registry in the start menu. But every power user knows how to launch it. The complexity is possible, it's there, but it's hidden. It doesn't bother the new guy because he doesn't even know about it. Only the power use can find it.
If you prefer an example with Mac OS, the operating system by default is unbelievably limiting. There is very little you can configure via the settings. Pull out the terminal and you can change absolutely everything you can imagine. Again, the complexity and features are there ... but hidden. They don't interfere with the regular user experience, but they're there if needed by the power user.
Ditto for Linux.
As a user, I prefer a good UI that's firmly for one audience than one that manages to be both confusing and limiting, like oh-so-many are.
Even as a power user, I quite likely only want to change a few things "under the hood" and otherwise I appreciate a clean design. Further, the more programmers design an interface "for those other people", the more likely they are to make it purely brain dead. So you find up with two lousy interfaces instead of one well designed one (not just two interfaces take time but because you've started with the wrong attitude).
For me, the fact that you have to hide the "power-user" options, be it on the registry, about:config or under an "advanced" dialog somewhere is a sign of something much worse. All those toggles increase complexity of the software exponentially as they can be combined affecting each other, increasing the effort of understanding the code, making changes, testing, even the runtime complexity.
Lots of developers, when faced with a choice, make it configurable instead of thinking hard about it and making the choice. Developers are never popular when they decide against adding an option. I see it all the time on Google Chrome, or even on the iPhone to name some popular examples.
But some choices, even if they are hard to make, should be made.
It isn't an exclusive-or; if you want power users it needs to be configurable. What you need for beginners and casual users are really good defaults, which means doing the hard thinking to choose them. If you want both types of users, you need to do both types of work.
ADDED: It also helps to make the configuration choices discoverable, to provide a path for new users to become power users.
In fact, those decisions are one of the main reasons why I, as a power user, don't use Chrome or the iPhone - because I crash against the limitations imposed by those choices every day.
In the past, I've also used my own extension, that allowed me (and the few hundred other users) to select a piece of text and launch a terminal using it as a command. Absolutely impossible to do in Chrome.
Finally, Tiddlywiki - only usable in Chrome if you install and run a Java program (applet?). Since I don't have Java in my work laptop, no dice.
As for the iPhone, simply installing non-approved apps; old console emulators, for example.
The "hard" challenge for a developer is not caring less about offending people but to come up with a really clever design that accommodates both newbies and experienced users.
I think this is the key reason why "The Inmates are Running the Asylum."
http://www.amazon.com/The-Inmates-Are-Running-Asylum/dp/0672...
We programmers are much more immune to complexity than the average person. It's like when I was buying a flute at Seattle Folklife. There was this one maker who was a virtuosic player with amazing walking stick flutes. I couldn't get a sound out of any of them. The maker could, because he was an expert with a very strong embouchure, but it was just impossible for me.
I ended up buying a flute from a different maker, who wasn't such an expert player. I could make a good sound on his flute from the get-go.
Awww, you gave up :) But seriously, go back to that first guy and learn to kick ass with his flutes!
Or maybe you're not interested in doing all that work in return for the expected benefit. Maybe you're just going to give up :)
Perhaps there are different tools for different levels of experience. Much like software.
The non-technical user has no clue, and the power-user bristles every time they have to deal with it.
"Sane defaults" is the best way to accomplish ease-of-use. A mix of autoconfiguration to task-at-hand and reasonable interface expectations.
At least CLI and assignment-based config files are both scriptable and manageable in version control (and hence, through configuration management systems such as cfengine / puppet / chef / etch, and source control (git, Hg, etc.).
I'll also add that I'm no fan of GNOME's bug-for-bug compatible reimplementation of the Windows Registry through gconf. At least the underlying data are slightly more accessible, but it's still a massive festering boil.
One system that I find works pretty well is WindowMaker. Configuration is through a set of textfiles, but most functionality is exposed through a pretty slick configuration utility. Since all of this is based on Steve Jobs's NeXT interface, I'm not overly surprised that it works pretty well most of the time.
When I configure a new desktop/laptop, I just port over the GNUstep directory. Every 6-12 months I may tweak a configuration setting, usually through the GUI utility. But if I want to I've got the full functionality exposed through files.
A realization I had a few weeks back is that GUIs are ultimately limited in their surface area and dimensionality. There's only so much functionality they can expose, and in any sufficiently rich interface, some stuff will be buried deeply, and inevitably, two configurations you'll want or need to tune together will be in utterly different branches of the config menus/interface.
With a CLI, all dimensions are uniform. If the interface is sufficiently broken, you can write a wrapper around it (a classic example is rlwrap, a readline wrapper around other commands, such as Oracle's utterly broken CLI SQL client). I'll frequently write one-off shell functions to put the argument I want to tweak at the end of a command line to make readline bash editing easier and more convenient.
Granted, this is power-user stuff, but it's what makes the shell environment so damned powerful and flexible.
If what you build becomes sufficiently ubiquitous, then even a bad design becomes "intuitive", if only by way of familiarity.
Is it intrinsically "better" to drive on the left or right side of the street (it apparently mattered in days of knights on horseback and needing your sword arm where it could do some good). Probably not .... but once you make that decision, you'd damned well better stick to it, and there's a lot else that follows as a consequence.
Edit: There are very good points being made about knowing your target audience, designing for simplicity, etc. But in the end, if you change your user's workflow, they're not going to be happy, even if the end result is a better product.
It's only natural that they feel angry and betrayed. If the direction of the product's evolution really is removing those features, it should at least be done more gracefully. For instance, first disabling them for new users but maintaining them for current customers. Or releasing a new "light" version and giving the customers the option to stick with the old one.
"So with each new version I tried to simplify the user interface, and dropped features & options that complicated the product. FeedDemon became more popular as a result, but you’d never know it if you visited my online support forums."
I'm wondering if this is correlation problem - in other words, Nick perceives that the popularity of FeedDemon is due to his simplifying the design, however it is also possible that a rise in both the awareness of what RSS is/does and a corresponding search for tools led to the popularity. It could also be the additional press/marketing received from the Newsgator acquisition helped. It could be that Google Reader's concept was great but people decided it was too simple/not good enough and they wanted a power tool for RSS (thus Google found/educated people for Nick).
I'm just wondering if the foundation of Nick's particular business was built with the power users and it was the power users who got the word out about FeedDemon. If that's the case, then he's drawing the wrong conclusion and thus the future of FeedDemon is in danger.
I've been a FD user for 5+ years, I guess, and I certainly was one of those bloggers talking about it back in 2006 or 2007. I'm certainly in the power users category so I don't really know that I can be objective here.
When someone becomes proficient with your product, guess what they become? A power user. And if you don't have any features to cater to them, do you expect them to be using your product much longer? And once they stop using your product, do you expect anyone else to as well?
Now, imagine I am a intermediate user. I started to use your product because it's quite good and simple. But, as I don't like some setting, I open the preferences. What I find is five tabs, cluttered with many options, revealing the choices you couldn't make yourself. I cannot find what I'm looking for and quit the app out of frustration. By trying to cater to everyone, you tend to sweep the complexity under the rug and piss off users who don't fit in your categories.
I think the simplest answer is that the iPhone must be providing enough features for power users, even if not all the features they want.
That sort of thing led me to thinking that users ought to be empowered to completely customize their UI. Keep the mainstream on the new shiny thing, but enable a setting that allows me to use a text editor to completely redo all of your choices. Create a marketplace for the sharing of these config files under source control too. A mechanical engineer will have different needs than an executive assistant, not in complexity but rather in context and workflow.
When was the last time you saw a "power user" configuring a hammer?
[1] 80% of waking hours behind a computer, most of the software I use, I use several hours daily
Also, I never did understand the aversion (usually coupled with condescending comments like your "I'm not 15 any more", implying those who do configure tools to be immature) to tweaking tools. Setting my environment up is a one-time affair: I sit down for a weekend, get my computer working exactly the way I want, and I'm set.
The productivity benefits (and, at least for me, they are significant), are not one-time: they scale with however much work I do. The difference, of course, is that the benefits are less obvious than the time spent to get them. The only reason I'm well aware of them is that I've used both a nicely customized system and (for school) a horribly inflexible Mac OS system at the same time. Throughout the year, the difference between the two became more and more annoying until I was just gave up and did most of my work at home.
So really, the cost to customizing a system is O(1); the benefits are O(n). Unless the constants are very high (e.g. modifying the kernel for my own use would just take too long) or you don't plan on using a tool too much, optimizing it makes sense.
Coincidentally, while I've never seen anyone customizing a hammer (it's a rather simple tool which, chance are, you don't use that much or for too many different things), people do customize things like tool boxes for a very good reason: they're moderately complex and having everything organized the way you like makes you much more productive.
Additionally, I find another benefit to modifying my tools myself: it's much easier to remember my additions than even equivalent features that come standard with the system. I have added a whole bunch of useful commands to Emacs that save me quite a bit of work, and I did not have to spend any time remembering the new key sequences because I was the one who came up with them in the first place. Even if those features existed and were on by default, it would probably have been easier to set my own key commands for them.
In short: while it's fair to expect software to "just work", it is not fair to expect it to work optimally or even well for every case and every person. And customizing your own tools (which is one of the things I think it takes to be a "power user", rather than sheer quantity of use) really can make you more productive, even taking in the time needed to actually customize them.
I think the parent poster is arguing not spending a weekend to setup something. It should just work, fast and great.
My second point was that setting up my tools (e.g. sitting down for a weekend...) only takes a constant amount of time but provides a linear benefit based on how much work I do. This makes it a net gain in most cases. This is also more of a response to his "I'm not 15 anymore" comment rather than his expectations.
Never, because they're not configurable. My housemate does have five different hammers used for different things though - should we design software around that instead?
Emphasis on simplicity + social proof: http://i.imgur.com/f2wxZ.png
In other words, when he decided after launching FeedDemon that what it should have been was a simpler product, Bradbury might have been better off if he'd left the "FeedDemon" name on the original, complex product and then rolled out the simpler version under a different name. That way people who picked up "FeedDemon" wouldn't feel like they were getting pushed into using "SimpleDemon" (or whatever the streamlined version ended up getting called) instead. People underestimate the power of names in setting user expectations.
(An objection to this might be the increased difficulty of maintaining two product lines, but there's a simple answer to that -- just stop updating FeedDemon. Eventually the power users who appreciate the simplicity will get the message and switch over to SimpleDemon, and those who ABSOLUTELY MUST HAVE radio button #7,131 on the preferences screen can sit on their complicated, orphaned version for life.)
OR, you can delegate development to that power users community
That is definitely not true, and is the kind of thing one will only say if one has not actually interacted with ordinary users. Having had a fair amount of experience with teaching ordinary people to use computers, I can say that by far the biggest problem that they have is underestimating their ability to figure things out, while overestimating the damage they are likely to cause if they get something wrong. This is why the most important lesson to teach kids about computers is that as long as you have backups, almost any mistake can be fixed with a clean install.
Long story short, if you put your power user settings under a red tab labeled "Advanced", 99% of the non-power users will never even notice them.
Of course, along with the normal people, there are exceedingly stupid people for whom you need to have a warning text.
The folks that derive some satisfaction from doing things with a million manual settings (or doo dads) aren't really an addressable market, because lots of open source is that way.
Maybe it's just me
[1] I may not make the best CEO...
Sometimes it is really hard to figure out how geeky your potential customers are. I am building a markdown editor, and while I am trying to make it as non-geeky as possible it is not completely clear how non-geeky a markdown editor user can be at all as the most non-geeky users just probably stick with WYSWYG editors.
Also, lately I see a lot of great lessons from "lone wolfs" like Nick (FeedDemon), Marco (Instapaper) and Mark (Pinboard).
But instead of dropping features, can't they be hidden by default and enabled by the user?
There should be two layers.
You aim to create the simplest, most elegant product to monetize your basic consumers.
But, if there is a market for it -- and there may well not be in the case of FeedDemon --, you can also provide an extendible platform/API below the UX on which developers can build out innovative functionality for power users. This is fairly low cost and can have multiplier effects. If a market arises on the platform, you can copy the best ideas of your smartest users or you can provide B2B tools to automate tasks for those that are interested in paying.
Thanks for that phenomenally original advice and for using power user strawman to introduce it.
Power users aren't very common, but they exist. The idealized "common man" doesn't because everybody truly is different.
An application for power users doesn't just have a few advanced features or configuration switches. It has to be fully designed with different goals in mind.
Ease of learning vs efficiency, non-intimidating UI vs configurability, prettiness vs speed of usage; they're often at odds with each other, and while I'm sure some great examples of applications sitting comfortably in the fence can be found, most end up as a shitty experience for everyone.
Every time (about once every two months) I use screen I have to go and re-read the man page. byobu tells me in the bottom corner I can press 'F9' to get a menu, which then has some help. I'm sure this 'waste of screen' will annoy power users, but I find it saves both time and annoyance, on those rare occasions I want to keep a terminal open on a remote machine.
Is that the effect of Joel's 80/20 rule?
I'm not sold by this post until I see some stats.
Antoine de Saint Exupéry: "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
Or in the original French: "Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher."
It's entirely possible to use Emacs (by which I mean a graphical build of GNU Emacs or XEmacs launched under a window system of some kind) like Notepad: Use the File menu to open, save, and close files, use the big X decoration at the top right to close, and that's it. Ignore everything you don't understand (which people do anyway) and you're golden.
(GVim seems to be the same way now.)
So screwing power users is not the only option; you can move the complexity down into the interface a bit and leave it to the power users to find it out, because they'll be the only ones who will.
I think choice is often a veneer that divides us from a truly awesome application. Especially, but not only, when you're a pointy-haired boss. Screw the power users.