Proposal Smart Help
|Proposal pages help us get from feature requests into actual plans. This page is a proposal for context sensitive help in the preferences panels.|
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.
- Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.
Detailed context sensitive information on each configurable parameter in the preferences panel. This information will be automatically extracted from the html help reference section which has been written with this use in mind. Smart Help would also give context sensitive help on buttons, giving more information than can usefully fit in a tooltip.
- James Crook I have done some development work which could be built on for this. The most useful part is a change in ShuttleGui.
- Shorter descriptions: This will allow us to use very short descriptions in the preferences panel, e.g. just a tick box with the word 'Overdub' beside it. Experienced users will already know what this does. Inexperienced users or users who have forgotten what the parameters in a particular parameter group do can click on the title for a group to get a description for each parameter in the group.
- Audacity GUI as the index: Instead of reading the manual and finding the right place in it, Audacity can find the right place and just present the information you asked for.
- Interleaving comments with settings in a multiscroller works well. An example is shown on the page about User:James/AU14TrackPanelTheming theming. This can and should be extended to support hyperlinks, to dig deeper in the manual. This would open a browser window. The comments in this scroller can address groups of related settings. The scroller design means that it is usable on space constrained screens, netbooks, yet can make good use of more vertical space if it is available. This was previously a problem with preferences where we had to break the preferences up into 'same sized' categories.
- The 'information' button, the i with a circle round it, can show/hide a panel with additional information. When the 'i' button is down, the panel shows and the lower part of the panel has information from the manual.
- The information panel can have information that changes as the tooltips show and hide. Most usually the panel will have general information about a toolbar, and information about buttons in it would highlight as you move from button to button. The information panel hyperlinks, to dig deeper in the manual.
- The panel is not full screen, so it is not suitable for displaying manual pages that have wide screenshots in them. We might need to rejig the manual a little to ensure we have pages suitable for the panel. This could be markup on key landing pages to exclude wide images and related text. Hyperlinks from the panel will open a full browser.
- With the 'information' button mechanism, regular tooltips can and should be short. Normal style in modern applications is to be single-line. As an example, the 'home' button in Chrome browser has the phrase 'Open the home page' as its tooltip. We should do that too. We do not need to show shortcuts in the tooltip. Having a button IS a shortcut for mouse users. Keyboard users can learn the keyboard shortcut keys from the menus, or from the key-bindings preferences.
- Multi-function buttons, where different functions are accessed by a modifier key (shift, ctrl, alt, ctrl + shift) have many problems. We could, for example, have whistle-triggered-record accessed from record via a modifier key. If we did this, we'd be mixing heavily used and esoteric features and making the interface more confusing. That said, multi-function buttons can save screen space. Looped play is very useful, and arguably it does belong with normal play. Generally Multi-function buttons need a rethink.
- Click-and-hold on a toolbar button could drop down more options. Effectively the button becomes the head of a menu. Chrome does this with the back-button, where click and hold on the back button shows browser history and a choice of pages. Click-and-hold gives more options. In Chrome, the tooltip is: 'Click to go back, hold to see history'.
- With this change, it would be OK to still retain the modifier keys. However, we do not need to advertise the modifier key in the tooltip. 'Click to play audio, hold for more play options' would be a possible tooltip. Click and hold then gives a mini-menu that includes loop-play as an option, and showing shortcut key combinations. That menu can have lots of options, play, loop play, play-excluding, play-at-speed, loop-play-at-speed, play-through, play-with-swearwords-bleeped and so on. When a modifier key is held down, the icon can, if we want, still change, and the tooltip can change, e.g. hold down shift and the tooltip becomes 'loop play'. It's become a minor feature, rather than crucial to discoverability.
- Customisable buttons advanced users (I am thinking 1% of users) may enjoy customising their toolbars, adding optional buttons, so that they have both a button for looped play and play, and possibly buttons for some preset speeds, e.g. play x2. Once users break out the options, we shouldn't be changing the icons based on a modifier key being down.
- The information panel can work for menu items in the same way as it does for buttons. The discussion above shows that buttons are just a different visual design for a menu.
What else is on the information panel?
- The top item in the information panel is the 'mode' audacity is running in, standard, custom or full. The panel will contain information about the currently loaded projects, file size, location, disk space. Advanced users will be able to customise this display so that it has more information that they choose. The idea is that the information panel will be useful to advanced users too, and so justify having a large button on the toolbar.