Validity of bugs whose solution involves adding an option somewhere

Fri Dec 14 15:20:14 UTC 2012

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 <notgary at 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 at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-desktop/attachments/20121214/dd89376b/attachment.html>