Difference between revisions of "GUI Design Guidelines"

From Audacity Wiki
Jump to: navigation, search
(My thoughts.)
Line 22: Line 22:
 
* '''Disallow alphabetic characters in text input fields in plug-ins, so that you can get to Preview in any effect by just pressing "V" (as you currently can in Equalization)''' JC: Needs more thought, e.g. plug ins that allow frequency change from C# to A, very convenient to have alphabetic entry.
 
* '''Disallow alphabetic characters in text input fields in plug-ins, so that you can get to Preview in any effect by just pressing "V" (as you currently can in Equalization)''' JC: Needs more thought, e.g. plug ins that allow frequency change from C# to A, very convenient to have alphabetic entry.
 
* '''[LL] Greater consistency of '...' in History list (Does this belong in this group? What does it mean?)''' JC: I think this indicates condensed entries, and if so we do want to be consistent there.  It's a programming issue.
 
* '''[LL] Greater consistency of '...' in History list (Does this belong in this group? What does it mean?)''' JC: I think this indicates condensed entries, and if so we do want to be consistent there.  It's a programming issue.
 +
[[Category:For Developers]]

Revision as of 15:02, 10 September 2008


Standards

JC has suggested this page where we propose and discuss 'visual standards'. Should we write a "Style Guide" for visual appearance? This could cover examples such as:

  • When to use a dropdown menu and when radio buttons? JC: Drop down when four or more items? I find the long list of radio buttons for the FFT size ugly.
  • Buttons on toolbars to be styled as for operating system default? JC: I think not. I'd rather we have the flexible themes.
  • Use of same kind of sliders throughout? JC: Sliders need improving so that we can easily enter precise values. If we use different kinds we should at least have an excuse or reason, e.g. I'm OK with a different slider in preferences to in the track, but I think overall output level and per track level should use the same visual design.
  • Are dialogues too wide and buttons too large (look at Tracks > Resample as an example, where the text box is about eight times longer than needed to accommodate the text input). Is there any consistency now in why dialogues with little text are as wide as they are? JC: Yes, we are too wide in places. Let's never have sentences on buttons, instead single words, e.g. [Download] Lame installer, with the 'Lame Installer' text that's alongside the button.
  • Whether we put units in brackets or not, if so "( )" or "[ ]"? JC: If we have units on the left, then we need brackets.
  • Whether units go after text boxes or before. We are inconsistent about this in Preferences (see Audio I/O where text is after the box, Quality where it's in the text in the box, and Spectrograms where it's before the box inside circular brackets). We also have a consistency problem that the style of recent type 3 Nyquist plug-ins has moved the units value to left of the entry box. Also, these values are in square brackets. GA thinks if we want to be consistent this implies units to left (or above) boxes, as some boxes/controls are simply too long to reasonably have units after the box. Additionally, screen readers can't read the units unless they are before/above the box. JC: Not keen on units on the left, but I do buy into the argument, so yes, labels on the left.
  • Quotations - should these be " " or ' ' (applies to documentation also). JC: Depends on context.
  • Menu paths - should they use " > " , "->" or what? (mainly applies to documentation) JC: Mild preference for '->'
  • Capitalisation of all words, or nouns only? JC: Other. I think style guide is that important words get capitalised, words like 'and', 'for', 'of' don't. It also depends on context, e.g. maybe different rules for wiki titles. Don't have a strong opinion.


Some other specifics

  • Suggested we should use the same smaller logo and higher screen position of Welcome Message for About Audacity JC: After having seen the About box again, yes, would be better.
  • Disallow alphabetic characters in text input fields in plug-ins, so that you can get to Preview in any effect by just pressing "V" (as you currently can in Equalization) JC: Needs more thought, e.g. plug ins that allow frequency change from C# to A, very convenient to have alphabetic entry.
  • [LL] Greater consistency of '...' in History list (Does this belong in this group? What does it mean?) JC: I think this indicates condensed entries, and if so we do want to be consistent there. It's a programming issue.