Validity of bugs whose solution involves adding an option somewhere

[Milan Bouchet-Valat]

Le vendredi 14 décembre 2012 à 10:20 -0500, Sean McNamara a écrit :
<snip>
> 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.
Actually, GNOME Shell has elected Choice 4, and maybe even more than
Rhythmbox, if you count the number of extensions on
extensions.gnome.org. And they can affect any part of the Shell's code,
since it's JavaScript.

> 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