Hi, I have thought about this a lot too, as a developer. It is hard to make an overall judgment that is true in all cases. Sometimes an option really is needed, and trying to "workflow" around it just leads to frustration. Take for example, the fact that you have to log out to get to a shutdown button on Windows 8 -- this leads to huge frustration for users because they don't have the option to shutdown from the desktop. Sure, *there exists a workflow* for them to shutdown, but it is more complicated than necessary.
On the free desktop, the two extremes of option implementation that I see are GNOME 3.x versus KDE 3.x (or, arguably, recent KDE 4.x too). On the one extreme, anything that could be seen as an option is avoided. On the other extreme, and especially with KDE 3.x, almost every application has a toolstrip (or two toolstrips, or three) along the top of the window with various actions and options. One perspective that I have held recently is that the needs of power users and software developers are very different from the average user. Thus, it stands to reason that a desktop that is useful to developers is going to look very different from a desktop that is useful to end-users. This might explain why my assessment of all the recent desktops -- from GNOME 3.x, to Unity, to KDE 4.x, to Windows 8, has been pretty much the exact opposite of the typical non-tech-savvy user. "If they love it, I hate it" -- and vice versa. However, my perception is that we *needn't* have this awful, painful schism between power users and basic users, and as you'll see further down in my post, I believe I have a middle road. I can say one thing for sure, though: if you *only* cater to the average user, and the *only* way to achieve the less-common use cases is by modifying the source, you're going to get a lot of forks from fed up developers who need to scratch an itch. Or, if they're not feeling up to the programming task, they'll just switch desktops, or run Windows, or something. When you consider the high cost of losing a developer who might contribute to your platform, this is not something you can really afford to do with any regularity. Think about it from a benefit-to-the-project perspective: is it more beneficial to have one developer on the project who contributes code and patches, or is it more beneficial to have 50 happy end-users? If you had to choose one, which one would you choose? Well, I'm sure that some people might choose the 50 users, but me, I'd choose the developer for their ability to give back to the project. Again, though, this is an awful choice to have to make. Why can't we do something that makes everyone happy? Maybe we can! Here's a thought that may not have occurred to you: plugins. In my opinion, plugins provide the best of both worlds: the default install can be pared down and minimal so that new users don't get confused, while advanced users who know they have the need can discover the plugins and install them. I have written plugins for Rhythmbox and find this model to be most excellent. Rhythmbox, out of the box, is fairly simple; and can be made even simpler if you disable the plugins that are installed by default. Now, if all the plugins ever written for Rhythmbox were part of Rhythmbox *core*, and all of them had some kind of checkbox somewhere as an option, that would be fairly annoying, even for power users! But the plugin nature of Rhythmbox makes it very easy to get extra functionality by googling for it, or searching Ubuntu Software Center, for instance. Based on my experience working as a plugin developer for Rhythmbox, here is my viewpoint: You are writing a piece of software, or maintaining an open source project. You realize the potential for some feature to be implemented. This is a feature that you don't want to automatically be built-in to the application with no way to turn it off, because you know that some people will want it, and some won't. Now, you are at a four-pronged fork in the road: Choice 1: Implement the feature directly into the application with no way to turn it off. This is dangerous, because user pushback of "it's too complicated!" or "it's annoying!" is likely. Choice 2: Don't implement the functionality AT ALL. This is also dangerous, because power user pushback of "this app is useless!" or "it doesn't have the features I need!" or "I'm going back to Windows!" is likely. Choice 3: Implement the functionality buried in some preferences pane or menu option. This is not a terrible idea, but once you start having dozens or hundreds of checkboxes and dropdown lists and toggle buttons, the user gets overwhelmed. Even a power user, when first running your app, will get overwhelmed. Your app will be popular, but will have a small niche community of power users who love the options and understand the nuances of each one. These users will have a great time, but the rest of the 90% of the potential user base are locked out because they can't get past the idea that it's too complicated an app. Choice 4: Implement a plugin architecture for the app, and make the additional feature available as an add-on (the best way I can think of to do this is to ship it as a separate debian package in the repositories). At your option, you can create some kind of plugin marketplace or browser within the app that provides information and search capability for each available add-on; otherwise, you can rely on the existing infrastructure of Google, AskUbuntu, and the Ubuntu Software Centre as possible ways that users can discover available plugins. The plus side is that users with very basic needs will see a nice, smooth, streamlined app out of the box with no "fat". The other plus side is that power users with advanced needs will be able to discover and easily install the functionality they need. The downside, of course, is the significant chance that your plugins are *not* discoverable, so that someone searching for them will give up the search before finding them. Example of an app that frequently elects Choice 1: Microsoft Office. Example of an app that frequently elects Choice 2: GNOME Shell. Example of an app that frequently elects Choice 3: KDevelop. Example of an app that frequently elects Choice 4: Rhythmbox, gEdit, Eclipse. Personally, I'm all-in with the Choice 4 crowd. Seems like the best of both worlds to me. :-) Regards, Sean On Fri, Dec 14, 2012 at 9:43 AM, Chris Wilson <notg...@ubuntu.com> wrote: > Hey, > > I've been thinking a lot lately (through my job) about adding options to > software. Personally, I try to avoid it, both at work and in my personal > projects, as feel they get in the way of the user being able to understand > how your app works, as well as adding more routes through the code that > need to be maintained. > > There's a great article > here<http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html> on > the subject. > > This <https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/264816> bug > report got me thinking about how this applies to paper cuts. Adding an > option to an app may sound like an easy fix that satisfies the largest > number of people, but is it really going to satisfy more people then the > app would if it weren't added? Wouldn't it be a better solution to design a > work flow that didn't require an added option? Is there really a demand for > these options? > > My question to you is: should requests to add options to app be considered > paper cuts? Personally I think they shouldn't, and we should instead look > at the underlying problem that got the person asking for the option in the > first place. I think we should also remember that the paper cuts project > exists to fix the issues affecting the *majority of average users, *and a > lot of options that are requested will only be of any real interest to a > minority of users, not to mention the fact that average users don't usually > customise their computer in the first place. > > What are people's thoughts in this? > > Chris > > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop > >
-- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop