Screw the power users(nick.typepad.com)
nick.typepad.com
Screw the power users
http://nick.typepad.com/blog/2012/05/screw-the-power-users.html
88 comments
Is a "show advanced options" checkbox really that indigestible a concept?
HomeSite 4, wow that is a blast from the past. I still have a boxed copy somewhere, I think from the Allaire days. The program was way ahead of its time.
Has anyone written a "Screw the Novice Users" article yet? The market is wide open!
I increasingly think this as time goes by. Also, the similarly related "Think about the first 20 minutes, or the user who only uses your product once in a blue moon".
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.
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.
I really miss the "mark as unread" contextual button, but even without it FeedDemon is by far the best RSS reader I have. (The premium version is worth the money).
Also, lately I see a lot of great lessons from "lone wolfs" like Nick (FeedDemon), Marco (Instapaper) and Mark (Pinboard).
Also, lately I see a lot of great lessons from "lone wolfs" like Nick (FeedDemon), Marco (Instapaper) and Mark (Pinboard).
I totally agree. Every option added is another place for the application to go wrong. If you _need_ an option, put it in, but don't just pander to people who want to tweak everything.
That's what Microsoft did with Windows 8 :/
But instead of dropping features, can't they be hidden by default and enabled by the user?
But instead of dropping features, can't they be hidden by default and enabled by the user?
I'd say a focused application is better than one designed for unpowered users with advanced features glued on.
This strikes me as a failure to communicate to people whether they are your targeted audience or not. Even something as simple as a "RSS Feeds for mere mortals" or "Why Users Love This Basic RSS Reader" could be enough to correctly align this app wrt user expectations.
Emphasis on simplicity + social proof: http://i.imgur.com/f2wxZ.png
Emphasis on simplicity + social proof: http://i.imgur.com/f2wxZ.png
I think the article is less about "communicating to the user" and more about "which users to target." Should we reevaluate ourselves as developers and build apps that target a larger, less tech-savvy audience?
Interesting. To me the problem seems to be that users are requesting features and making other requests because they don't understand that FeedDemon is indeed supposed to be a very simple application. It's like not understanding that MS Paint is entry level software and requesting it should have layers, advanced color management, etc.
It sounds like the problem is that at the beginning it wasn't supposed to be "a very simple application." It started out complex and then got simple over time. Which screws up user expectations -- the people who were attracted to it when it was complicated aren't going to be people put off by complexity. So they may have felt misled a bit when the complex product they chose started becoming something else.
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.)
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.)
> (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
OR, you can delegate development to that power users community
Does anyone have a statistic on the ratio of apps that are built and require users to understand programming / markup? It would be interesting to see how much we are "plaguing" the software industry by what kinds of apps we create.
I'm not sold by this post until I see some stats.
I'm not sold by this post until I see some stats.
Surely this is solved already?
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.
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.
Yeah, in user interface design everything should be as non-geeky as possible, but not non-geekier. :)
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.
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.
Exactly what Apple has been doing forever and they have piles of cash to show for it.
> Power users were happy with all the features and all the options, but the extra baggage made it harder for less technical people to use the product.
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.
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.
> Poor design. Seriously. Simplicity is really really hard. Much harder than throwing a ton of settings, toggles, and switches at a user.
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.
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.
It's funny, it seems that many (most?) whistle makers aren't very virtuosic players. For the most part, I don't think it does their whistle-making any favors. Whatever they win in "ease of novice use" they lose in "ease of serious use", if you know what I mean.
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!
Awww, you gave up :) But seriously, go back to that first guy and learn to kick ass with his flutes!
Or you could track this flute maker down, learn how to use his flutes and then teach us what was being done wrong originally.
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 :)
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 he should learn to get better with the flute he has and then he can graduate to the more advanced tool.
Perhaps there are different tools for different levels of experience. Much like software.
Perhaps there are different tools for different levels of experience. Much like software.
I prefer my flute to be accessible to players of all levels. (/innuendo)
Windows' market advantage is hardly a result of its simplicity or ease of use. And the ton of settings isn't done through toggles and switches, but through Registry settings. Which is sort of like changing gears by taking the gearshift lever to a shop and re-shaping it on a lathe. In the dark, by informing a deaf-blind paraplegic through Braille.
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.).
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.).
Your car analogy made me chuckle. However, I think there are other items that it describes better than the Windows registry. For example, I remember using Ubuntu a few years back and discovering that the only way to change some system font setting (don't recall exactly which one) was to recompile a package from source.
Yeah, I recall an internationalization bug that required me to patch and build from source as well. Then again, it was pretty beta code.
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.
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.
And ... been meaning to amend my original post with this:
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.
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.
I'd expand - it's not enough to avoid throwing a ton of settings to a user, you have to design so they are not needed at all.
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.
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.
>Lots of developers, when faced with a choice, make it configurable instead of thinking hard about it and making the choice.
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.
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.
Define "needed". Much of the divide between casual vs power users is that the latter will want to use the software in every way possible, many of which you (the developer) won't even be able to imagine.
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 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.
I'd love to know what everyday tasks you're doing for which Chrome or the iPhone are too limiting.
Well, for one, I'm a Pentadactyl user just like slowpoke, but also of DownThemAll!, NoScript (from everything I've read, NotScripts is a poor clone - no offense to the developer, as I said, they're limitations of the browser API) and some others.
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.
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.
Not the parent, but for Chrome, probably the horribly limited extension API.
I could not even begin to imagine how I would use a browser without Pentadactyl.
Or Tree Style Tabs. Both of which are flat out impossible in Chrome. As are
tons of other extensions.
You begin on topic by talking about the experience of a user: "avoid throwing a ton of settings to a user", then sidetrack into the experience of a developer: "the effort of understanding the code, making changes, testing, even the runtime complexity", in your justification for omitting advanced options for /users/ altogether.
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.
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.
This is great advice. Chances are, you're not building an operating system. Since your software is less complex, try to figure out the decisions you need to make. It may require a few iterations, but it's the right thing to do.
It's possible, but extremely hard. The OSes are a good example: despite many years of development, those 'divides' still leak immensely.
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.
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.
An alternative: have two separate interfaces, one for everyday settings (= simple), and another for "powersettings" (= configurable). A good example are the web browsers: some have a settings dialogue, where settings are presented logically, and they tend to simplify these dialogues, and then you have the about:config or about:flags page, where you can access a bunch of other settings as well.
I think you're missing what's good about what the gp is advocating.
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).
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).
This makes sense when developer time is not an issue, but if it is, favour simplicity.
As a power user myself, and the free tech guy for a family of casual users, I totally agree with this approach.
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.
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.
Or just be smart: hide power options under power user tab/button/whatever. Not-power-users gets simply design and most useful tools (for them). Power-users gets powerful tools.
The problem is that every user thinks they are a "power user." So if you put a bunch of options behind a screen that says "power users only," the effect is kind of like building a treehouse and then tacking on a sign that says "NO GIRLS ALLOWED" -- the girls will climb the tree just to see what it is you're hiding from them up there.
I never even look at settings if I don't have a specific goal I mind. I just can't be bothered. I often try not to use unusual settings because people will not have anticipated it, and things will break.
And I thought this was just me... these days I would like to call myself a power user, but I remember back in the days of dial up internet and napster... I'd click the "Advance Options" just so I knew what was there
Why is that a problem? A "power user" is anyone who wants to tinker with the settings. It's not like you need a special license or security clearance.
Sounds like a great opportunity for Freemium.
>The problem is that every user thinks they are a "power user."
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.
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.
This is the most sage comment I have read here in some time. I constantly have to remind my parents, "Don't worry, the likelihood that you irreparably damage this system by clicking some button one time is approximately 0."
It may sound like a minor detail, but if you specifically select the colour, red (which obviously is not part of your colour scheme), it's almost assured that they won't touch it. And by putting the "advanced" button in your settings page instead of having its own tab(it should open in a new Window preferably), you're almost guaranteed to scare more than 99.99% of the users since you've indirectly hinted at the fact that "if you screw up on this page, we are not responsible, and we know you will almost screw up", without even saying a single word. Design and colour is a very powerful non-direct communication tool.
Of course, along with the normal people, there are exceedingly stupid people for whom you need to have a warning text.
Of course, along with the normal people, there are exceedingly stupid people for whom you need to have a warning text.
There's much, much, much more in being a power user application than just some advanced tools. The whole UI has to be redesigned with different expectations in mind.
The problem isn't power users. The problem is that people adapt to features. It's extremely difficult to remove a poorly thought out feature after the fact. People will complain, whether or not they're power users. People are change averse, even when it's just skin deep. When it changes their workflow, they're going to scream bloody murder.
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.
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.
That's the source of the mentioned complains in the support forum. They're complaining because something they used to have isn't available anymore.
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.
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.
I wish someone would finally create a choice-free mail client (web service): you just register and get an email address, and it answers everything with something vague and noncomital ('Just a note to say I got this. We'll be looking into it'...'thanks'...'Will get back to you.'...'could you call me?') etc. No need for the user to ever log in and make choices.
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.
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.
You can re-sell that as a "geek girlfriend/penpal" site.
Hook two of them together, watch them lase.
Isn't that the supposed point of a dating site?
As a power user[1], I want you to consider every time I have to change a setting like a punch to the face. Your software should just work. It's a tool. I don't want to spend my time tweaking tools ... I'm not 15 anymore. I have better things to do with my life.
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
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
When was the last time you saw a "power user" configuring a hammer?
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?
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?
This actually brings about an interesting question. Is it better to have multiple items do one thing well each, or have everything under one roof?
That's not entirely reasonable--what works for you is not what works for me and is probably not what works best for other sorts of tasks. Unless the tool in question is really narrow in scope, there is not single "best" solution to any particular problem.
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.
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 sit down for a weekend, get my computer working exactly the way I want, and I'm set
I think the parent poster is arguing not spending a weekend to setup something. It should just work, fast and great.
I think the parent poster is arguing not spending a weekend to setup something. It should just work, fast and great.
I understand that. My first point was that expecting every tool to work perfectly, or even well, for every person and every use case is not really reasonable.
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.
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.
I've seen plenty of "power users" configuring their cordless drill.
The cordless drill is my standby example against the idea that people don't understand/like modes (when I feel cantankerous and want to argue against the "no modes" thinking). Bits are each a mode. CW or CCW is another mode choice. People seem just fine with thinking about modes when the current state is apparent and how to transition clear.
The real power users have even more impatience and demand as much simplicity in usage as beginners.
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
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
[deleted]
Greatness is achieved when you can not take anything away anymore and you are only left with the important things.
Not quite an accurate quote/translation, and unattributed to boot.
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."
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."
Thank your for quoting it.
No one knows that business more than Nick but this part struck me as possibly faulty logic:
"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.
"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.
"cater to your audience"
Thanks for that phenomenally original advice and for using power user strawman to introduce it.
Thanks for that phenomenally original advice and for using power user strawman to introduce it.
I think that it is far more common mistake for mass-market targeted software to be hard for novice users than it is for software targeted at power-users to be insufficiently programmable.
I think the mistake is less about making software less programmable and more about trying to appeal to some mythical idealized "common man" so hard that you appeal to nobody. It's the same strategy a politician uses when they go to the Midwest to find "Real Americans" only to find out that nobody really cares all that much.
Power users aren't very common, but they exist. The idealized "common man" doesn't because everybody truly is different.
Power users aren't very common, but they exist. The idealized "common man" doesn't because everybody truly is different.
I disagree. Build products for yourself. If you're a power user, then so be it. If you're making a product to make your life easier and you happen to be a newb, then design with that in mind. Screw profitability[1].
[1] I may not make the best CEO...
[1] I may not make the best CEO...
I can see a case being made that a consumer product shouldn't add features that will hurt its main consumers for the benefit of a minority of users. That said, it's reckless and short-sighted to proactively exclude power users.
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?
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?
I agree wholeheartedly with this idea. Beginners and power users are useful categories but they are too simplistic and polarizing. There are many ways to be a newbie: maybe you're tech-savvy in general, but not familiar with this type of software, maybe you're using it every once in a while, maybe you're overestimating your skills, maybe you're underestimating them, maybe you're hopeless with computers and never going to learn anything.
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.
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 can't think of a way to address your points directly, but would you consider the massive sales of the locked and limited iOS devices to be a valid counter example?
No, I don't, but that's a good observation.
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.
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.
One could very easily argue that the USER ought to be empowered to take control of the UI. I'll use MS Excel as an example of a tool that I've used with regularity since it came to market. MS thought they knew better and utterly destroyed the UI with the introduction of Office 2007. As anyone who was a power user prior to that version and you are very likely to get a nearly unanimous thumbs-down on the changes. The ribbon interface, as well as other choices MS made, took a power user and made him/her feel like a total idiot. Could you learn it? Sure. Could you find the commands you needed? Of course. And, for a period of days and weeks your productivity went down to nearly zero. Here is a case of a company thinking it knew better and pushing forward changes that actually destroyed productivity in a massive way.
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.
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.
It seems to me this leads down a path to open source. Use a text editor to change the source, then recompile. Because even config files have to decide at some scope what can be "configged".
It's entirely possible for you to cater to the most power-usery of all power users while still letting the largely-nontechnical do their jobs with your software. Look at Emacs.
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.
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.
[deleted]
Is that the effect of Joel's 80/20 rule?