Completed Proposal Preferences Reorganisation
|This page is meant to discuss necessary improvements to Preferences. Current and future issues include a redesign so that preferences don't overflow the screen when using Audacity in certain languages; and how to incorporate context-sensitive help into the preferences window.
Spring 2009 redesign to prevent locale overflows
This is a P2 bug on Release Checklist: Preferences menu in some locales overflows using smaller screen sizes/larger fonts, or default Mac at 1024x768. There is a preliminary devel-list discussion about it here.
- hard coded upper limit (800 x 600) with vertical scrollbars when the limit is exceeded
- only one column per option tab
- The length of the translated commands in the Keyboard preferences is a part of the overflow problem. Should there be a wrap after a given length? Or, there is plenty of unused white space to right of the key combinations - can we hard code the width of the key combinations to take up much less space?
- Larger number of tabs, for example:
- the Audio I/O page could be broken down into Playback and Recording
- Playback page could have the existing Playback, Effects Preview, Cut Preview, and Seek Time group boxes.
- Recording page could have the existing Recording, Playthrough, and Latency group boxes
- MP3 and FFmpeg Libraries on their own tab
- New "Dependencies" tab for the when importing.." (except normalize) and "when saving.." (except Metadata) group from Import / Export - it's a tab with a lot of space, but gets the issue noticed by users
- New "Import / Export behaviours" tab for the "when exporting tracks" group from Import / Export, plus "Normalize when importing" and "Metadata show/hide". That gives space for the eventual new preference to always use default sample rate when importing, and "normalize when importing" would have space if we wanted later to have a radio button to choose between normalising all tracks in project and only normalising the imported audio. We could even move the mixdown options from "when exporting tracks" to the Export dialogue where they could (more usefully) be set on the fly
If anyone wanted to, we could have some screenshot mock-ups here.
LRN 03:38, 14 March 2009 (PDT) - Two columns -> One column + vertical scrollbar (not depicted):
LRN 03:38, 14 March 2009 (PDT) - Long radiogroup -> short dropdown list:
For those using screen magnifiers, it would be best to have a single column per category, and no vertical scroll bar: there would need to be more categories/sub-categories. --DavidBailes 01:26, 1 April 2009 (PDT)
Also, there are a number of text boxes for numeric values which have the units to the right of the text box. These units are currently not read by screen readers.
Difficulty finding keyboard shortcuts
Stevethefiddle 16:31, 14 March 2009
- Gale 23:20 UTC 14 March 09 - +1 (probably after 1.4). This suggestion is already on Release checklist not aiming for 1.4 - some users already feel the only way to find the bindings you want is to export as XML. If Widgets supports it, different colouring for the different sections would really help sighted users too. If we don't sort, there should be some sort of divider so you can see which menu group you are in.
Note you can iterate through commands by typing their first letter, but this is largely broken in HEAD because many of the commands are indented. If indentation was intended as a grouping method, we should not do it that way.
What about left-align of the commands - was there some consensus this was better than the right-align we used to have?
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.
Integrating contextual help into 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.
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.
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?