Proposal Preferences Reorganisation

Proposed Feature
Reduce the width of preferences making it single column. Increase the number of panels so that each is less crowded. There is also a separate proposal for context sensitive help on the preferences panel.

Developer Backing

 * Most developers who have expressed an opinion are in favour.

Use Cases

 * Users of small screens such as net-books that are becoming increasingly popular.
 * Users using large fonts for accessibility.
 * Expect to fix some problems with size of translated text at the same time.

Spring 2009 redesign to prevent locale overflows
This was a P2 bug on Release Checklist: Preferences menu in some locales overflows using smaller screen sizes/larger fonts, or default Mac at 1024x768.


 * Suggestions implemented included:
 * Hard coded upper limit (800 x 600) with vertical scrollbars
 * Larger number of single-column tabs


 * Not implemented:
 * LRN 03:38, 14 March 2009 (PDT) - Long radiogroup -> short dropdown list:
 * [[Image:Audacity_prefs_long.png]] -> [[Image:Audacity_prefs_short.png]]

Bugs remaining

 * The current bugs for Preferences on bugzilla are here. Relevant to the 2009 fixes, some overflow and truncation issues remain in localised Preferences as at March 2011 - see Bug 295. Not being able to resize Preferences horizontally beyond 800 px is seen as a drawback by complainants about this bug.

Textual Version of Preferences
Firefox which has very extensive preferences. It additionally offers a textual tabular version which actually gives more preferences than are in the standard panel. In that version any preferences that are set away from default values are shown in bold. If we were to have such a tabular version, we could take some of the more esoteric preferences out of the GUI version to relieve the pressure on it.

Note that as per Release checklist not aiming for 1.4‎, RA suggested a case for all states currently settable outside Preferences (visible toolbars, Label Track font, Meter Toolbar refresh rate...) being at least visible in Preferences for diagnostic purposes. A textual version of Preferences could be the place for this.

Contextual Help for Preferences
Longer term we're hoping to have contextual help. Adding contextual help to Preferences would allow a reduction in the in situ Preferences text. This would help with the overflow problem, provided a good place is found for the help text. James believes that help at the level of one 'static box' is the right level of granularity.

There is also this discussion of Audacity preferences on the stack exchange UI site.

Trigger for the Help Text
The help text could take the form of tooltips, or buttons that open a pop-up or that open the inbuilt manual at the relevant place. There is already a modified ShuttleGui that makes the static boxes active. Click on the box, but not on any control in it, for example click on the name of the box, and the background of that box turns yellow (tooltip colour) and a 'help window' is updated.

Where to show the Help
Preferences is a large window. It could provide a scrolling or slide-out partition on its right-hand side to provide the extra help - though this would NOT work well for eeePC and similar small screens.

One approach to fitting the help in is to use the tree nature of the list on the left. The tree could have the main items as currently, and also have as indented sub-items the names of the static boxes. Click on the tab name and you get a one column display as in LRNs mock up - with a scroller if required. Click on the static box name, and you get JUST that static box, with an explanation underneath. This gives a very discoverable way to find the help.


 * Gale: It would seem to me that would make a vertical scroller inevitable unless the sub-items were expandable/collapsible, and only one group of sub-items were expandable at a time. The need to click on a + to expand them would make them a bit less discoverable for novices. Still, I prefer this to a right-hand partition, which I don't think is going to work given we are trying to reduce width. If we use help triggers within a Preferences tab which as now contains multiple static boxes, and those triggers open some new interface element, I vastly prefer opening an inbuilt HTML manual in a modeless window.

Vista guidelines
Microsoft guidelines suggest using links to provide contextual help: Vista help guidelines.

This is reasonably accessible for users of screen readers. --DavidBailes 01:26, 1 April 2009 (PDT)

Plug-in Module Preferences

 * d1-1: If the plan is to eventually move certain pieces of functionality out into separate modules, it's probably going to make sense sooner or later to have a separate section in the preferences for enabling/disabling and configuring them. The actual preference page for a module could be handled by the module itself - there would just need to be some code to tie it all into the main preferences dialog. It would be done dynamically by LoadModules, so there wouldn't be any need to include anything related to specific plug-ins. Any thoughts?


 * James: At the moment we just load all plug ins. In future we will indeed need to list all plug-ins, but only load the ones that the user wants.  That to me means that there will be a plug-in coordination page in addition to a page for each loaded plug-in.  In our early incarnations we will insist that plug-ins match exactly by version number, so only a 1.4.0 plug-in will work with Audacity 1.4.0.  It's more restrictive than it needs to be, but experience shows that getting a more sophisticated system right (where both plug-in and audacity can veto the loading) is more difficult.

Three-tier default Preferences settings
Peter Sampson 28Feb11: Three different default sets of preferences, for: The user would select their skill level via a dialog box on first run of Audacity after install and then get the appropriate set of defaults loaded to suit their skill level. Actual setting for each of the three skill levels to be decided later. Use Case: This idea was suggested by Vaughan in a recent discussion on the -quality list regarding the preferred default setting of the import Preferences as "Faster" (referencing external aliased audio files) rather than "Safer" (self-contained projects). "Faster" is the preferred default option, but the Forum Staff & Crew find themselves having to try to rescue many novices who fail to understand the implications of the "Faster" import setting and thus get themselves into difficulties. For novices therefore it may make sense to make their default "Safer", which would be part of "complete beginner". This is one way of making users safe when handling imported WAV and AIFF. For a complete discussion of alternative solutions, see Proposal User-safe Aliasfiles.
 * 1) "complete beginner"
 * 2) "familiar with digital audio"
 * 3) "power user"

Gale: Other possible "power user" settings:
 * -145 dB Meter/Waveform range
 * Waveform (dB) view
 * "Select all on none" OFF
 * No warnings
 * More pre-allocated keyboard shortcuts (or fewer for "complete beginner").
 * Maximum Preferences items listed (fewer for "complete beginner").

That said, I see no need for more than two tiers. Too complex to choose between the two more powerful tiers.