Difference between revisions of "GUI Design Guidelines"

From Audacity Wiki
Jump to: navigation, search
(Any new logo would retain headphones idea and have trademark.)
(Details: link to new manual>wording page)
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Template:Audacity Devel}}
 
{{Template:Audacity Devel}}
  
 +
==General Points==
  
==Standards==
+
* '''Discoverability'''
 +
** It should be possible for a user to start using Audacity without a manual, and then gradually discover the features.
 +
* '''Attention is a resource''': There is a tension in design between uniformity and attention.
 +
** It is super to treat things the same internally inside Audacity uniformly, as it means less code to do more.
 +
** User-attention is a scarce resource, and more 'user attention' (colour, screen real estate, dynamic changes) should be spent on the most used features. 
 +
** So our menu items, small buttons and big buttons should all be the same kind of thing inside Audacity.  Yet in the GUI, we make just 6 buttons big, 26 small, and the rest are relegated to menu items.
 +
* Use '''"coding theory" in your menu layout'''. 
 +
** The less probable a menu click the more deeply in the menus it should be buried.
 +
** Coding theory gives a numerical guideline for how deep a menu item should be.  If items are used 1/10 the time of others, move them 1 menu item down.  If used 1/100 th as much, move two items down.
 +
* '''Alt-Green-Meta-Shift-Ctrl-Double-right-click-E''' is undiscoverable.
 +
** Please don't expect your users to stumble onto it.
 +
* '''[[Stuck In a Mode|Stuck-in-a-mode]] is evil'''. 
 +
** Your users won't even know what the mode they are stuck in is, just that what they are used to does not work anymore. 
 +
** You can avoid stuck-in-mode by returning to normal on mouse-up, by observing what the user clicks on next when they do get stuck-in-a-mode (Stuck in snap to was often followed by zooming in to select precisely), or avoiding modes at all by having draggers.
 +
* '''Avoid message cascades'''. 
 +
** Do not ask your user 'are you sure' and then pop up further options and possibilities. 
 +
** For warnings and errors, tell the user what hasn't worked and let them gather more details only if they want to.
 +
** {{todo}} we have message cascades at start up that should be fixed.
 +
* '''Avoid repeating GUI elements'''. 
 +
** {{todo}} It is a design mistake that we have 3x microphone icon and 3x speaker icon, and two play buttons.
 +
** {{todo}} It is a design mistake that we have separately a play button and a play at speed button.
 +
* '''Re-use rather than reinvent'''. 
 +
** We have three different kinds of zoomable rulers.  This is a mistake.  We should have one properly designed kind that is general enough to work well in all three contexts.
 +
** We have multiple ways of activating scrubbing, rather than one well thought out way.
  
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.
+
* YOU are not the only user. 
 +
** You have to think about it from the point of view of someone who does not already know what you know.
 +
* YOUR shiny new feature is (probably) not the most important feature in the program. 
 +
** Do not make a flashing neon red pop-up to draw attention to it.
 +
 
 +
 
 +
==Details==
 +
* Use '''Dropdowns''' rather than radio buttons when four or more items?   
 +
** {{todo}} The long list of radio buttons for the FFT size are ugly and should change.
 +
* Use '''Words''' not sentences on buttons.
 +
** We are too wide on buttons and dialogs 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. 
 +
* Use [[Guidelines on capitalization in Audacity dialogs and messages|consistent capitalization]].
 +
*[https://alphamanual.audacityteam.org/man/Consistency_in_wording_and_punctuation_in_Audacity#Wording_and_punctuation '''Wording and punctuation''']
 +
* Units
 +
** Units before an input box should be in brackets ().
 +
** Units are better after an input box.  ''to be reviewed as Gale points out screen readers may only read units if before.''
 +
** {{todo}} fix this for spectrograms.
 +
** {{todo}} fix this for Nyquist type 3 plugins.
 +
* We have a general principle of using '''blues and greys''' in the Audacity GUI (Light and Classic theme). New developers tend to like using red to make their new features stand out. However, we try to curb this tendency and tone it down to get a quieter look.
 +
 
 +
==Proposed and not Accepted==
 
* '''Buttons on toolbars to be styled as for operating system default?'''  JC: I think not.  I'd rather we have the flexible themes.
 
* '''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.
+
==Documentation==
* '''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. <font color="green"> 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. </font>  JC: Not keen on units on the left, but I do buy into the argument, so yes, labels on the left.
+
These points belong elsewhere??
 
* '''Quotations - should these be " " or '  ' (applies to documentation also).''' JC: Depends on context.  
 
* '''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 '->'
 
* '''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.
+
* '''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.
 +
** We do now have [[Guidelines on capitalization in Audacity dialogs and messages]].
  
  
==Colour==
+
<div id="icons"></div>
We have a general principle of using blues and greys in the Audacity GUI. New developers tend to like using red to make their new features stand out. However, we try to curb this tendency and tone it down to get a quieter look.  
+
==Icons, Logos, interface and websites==
 +
We often get people offering replacements for our well-known and long-established Audacity icon/logo.  
  
 +
* In fact we did [[Completed Proposal New Logo|update our Logo]]
  
==Icons, Logos and web sites==
+
The design of icons/logos is in many ways the cherry on the cake. At this stage in Audacity's development we are less interested in just a new logo. We are more interested in computer savvy graphics designers who will help us on an ongoing basis, improving the look of the entire Audacity visual experience (the icons in the application, the logo, the [https://manual.audacityteam.org/ Manual] - also developed using MediaWiki - and the other websites). We would like to have a unified appearance rather than a patchwork.  
We often get people offering replacements for our well-known and long-established Audacity icon/logo.  
 
  
The design of icons/logos is in many ways the cherry on the cake. At this stage in Audacity's development we are less interested in just a new logo. We are more interested in computer savvy graphics designers who will help us on an ongoing basis, improving the look of the entire Audacity visual experience (the icons in the program, the logo, the [http://manual.audacityteam.org/ Manual] - also developed using MediaWiki - and the other web sites). We would like to have a unified appearance rather than a patchwork.  
+
* A well-argued report on the usability and discoverability of Audacity features ''would'' be helpful to us. We have to use our resources wisely, so
 +
knowing what causes most users the most UX problems is where we need to start.
  
However we also want in future for the user to be able to customise the appearance of the Audacity software to some extent, for example to allow greater or lesser contrast in colour of the various GUI elements. So when our [http://manual.audacityteam.org/index.php?title=Theme_Preferences Theming] feature is working well, we would definitely like new skins for Audacity. Some of us feel that a small number of subtly different alternate icons could possibly have a place in non-default skins (without changing the default icon/logo).
+
If you have any images of suggested new logos or icons please link to them on [[Completed Proposal New Logo]] (ideally, upload your image to the Wiki and link to that). It is anticipated that any new logo/icon would retain the current "headphones" idea. A new logo would continue to have the "Audacity" name followed by the &reg; registered trademark symbol.  
 
 
At this stage, if you have any images of suggested new logos or icons please link to them on [[Proposal New Logo]] (ideally, upload your image to the Wiki and link to that). It is anticipated that any new logo/icon would retain the current "headphones" idea. A new logo would continue to have the "Audacity" name followed by the &reg; registered trademark symbol.  
 
  
 
Similarly, please link to images of suggested new skins on [[Proposal New Skins]]. However, don't expect anything to change in the immediate future.   
 
Similarly, please link to images of suggested new skins on [[Proposal New Skins]]. However, don't expect anything to change in the immediate future.   
  
We also have received offers of help with redesigning or "modernising" our web sites, especially the main site http://audacity.sourceforge.net/.  We're always interested in hearing well-argued [[Talk:Pending website changes|suggestions for improvements]], but we do not want to make change just for the sake of a "new look".     
+
We also have received offers of help with redesigning or "modernising" our websites, especially the main site https://web.audacityteam.org/.  We're always interested in hearing well-argued [[Talk:Pending website changes|suggestions for improvements]], but we do not want to make change just for the sake of a "new look".     
 
 
  
 
==Some other specifics==
 
==Some other specifics==
Line 41: Line 83:
  
 
'''To be considered:'''
 
'''To be considered:'''
* '''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.  
 
SD: If also applied to Nyquist plug-ins it would be impossible for users to input a path or file name.
 
SD: If also applied to Nyquist plug-ins it would be impossible for users to input a path or file name.
 
* '''[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]][[Category:Quality]]
+
[[Category:For Developers]][[Category:Graphics]][[Category:Quality]]

Latest revision as of 16:01, 19 January 2018


General Points

  • Discoverability
    • It should be possible for a user to start using Audacity without a manual, and then gradually discover the features.
  • Attention is a resource: There is a tension in design between uniformity and attention.
    • It is super to treat things the same internally inside Audacity uniformly, as it means less code to do more.
    • User-attention is a scarce resource, and more 'user attention' (colour, screen real estate, dynamic changes) should be spent on the most used features.
    • So our menu items, small buttons and big buttons should all be the same kind of thing inside Audacity. Yet in the GUI, we make just 6 buttons big, 26 small, and the rest are relegated to menu items.
  • Use "coding theory" in your menu layout.
    • The less probable a menu click the more deeply in the menus it should be buried.
    • Coding theory gives a numerical guideline for how deep a menu item should be. If items are used 1/10 the time of others, move them 1 menu item down. If used 1/100 th as much, move two items down.
  • Alt-Green-Meta-Shift-Ctrl-Double-right-click-E is undiscoverable.
    • Please don't expect your users to stumble onto it.
  • Stuck-in-a-mode is evil.
    • Your users won't even know what the mode they are stuck in is, just that what they are used to does not work anymore.
    • You can avoid stuck-in-mode by returning to normal on mouse-up, by observing what the user clicks on next when they do get stuck-in-a-mode (Stuck in snap to was often followed by zooming in to select precisely), or avoiding modes at all by having draggers.
  • Avoid message cascades.
    • Do not ask your user 'are you sure' and then pop up further options and possibilities.
    • For warnings and errors, tell the user what hasn't worked and let them gather more details only if they want to.
    • ToDo.png we have message cascades at start up that should be fixed.
  • Avoid repeating GUI elements.
    • ToDo.png It is a design mistake that we have 3x microphone icon and 3x speaker icon, and two play buttons.
    • ToDo.png It is a design mistake that we have separately a play button and a play at speed button.
  • Re-use rather than reinvent.
    • We have three different kinds of zoomable rulers. This is a mistake. We should have one properly designed kind that is general enough to work well in all three contexts.
    • We have multiple ways of activating scrubbing, rather than one well thought out way.

 

  • YOU are not the only user.
    • You have to think about it from the point of view of someone who does not already know what you know.
  • YOUR shiny new feature is (probably) not the most important feature in the program.
    • Do not make a flashing neon red pop-up to draw attention to it.


Details

  • Use Dropdowns rather than radio buttons when four or more items?
    • ToDo.png The long list of radio buttons for the FFT size are ugly and should change.
  • Use Words not sentences on buttons.
    • We are too wide on buttons and dialogs 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.
  • Use consistent capitalization.
  • Wording and punctuation
  • Units
    • Units before an input box should be in brackets ().
    • Units are better after an input box. to be reviewed as Gale points out screen readers may only read units if before.
    • ToDo.png fix this for spectrograms.
    • ToDo.png fix this for Nyquist type 3 plugins.
  • We have a general principle of using blues and greys in the Audacity GUI (Light and Classic theme). New developers tend to like using red to make their new features stand out. However, we try to curb this tendency and tone it down to get a quieter look.

Proposed and not Accepted

  • Buttons on toolbars to be styled as for operating system default? JC: I think not. I'd rather we have the flexible themes.

Documentation

These points belong elsewhere??

  • 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.


Icons, Logos, interface and websites

We often get people offering replacements for our well-known and long-established Audacity icon/logo.

The design of icons/logos is in many ways the cherry on the cake. At this stage in Audacity's development we are less interested in just a new logo. We are more interested in computer savvy graphics designers who will help us on an ongoing basis, improving the look of the entire Audacity visual experience (the icons in the application, the logo, the Manual - also developed using MediaWiki - and the other websites). We would like to have a unified appearance rather than a patchwork.

  • A well-argued report on the usability and discoverability of Audacity features would be helpful to us. We have to use our resources wisely, so

knowing what causes most users the most UX problems is where we need to start.

If you have any images of suggested new logos or icons please link to them on Completed Proposal New Logo (ideally, upload your image to the Wiki and link to that). It is anticipated that any new logo/icon would retain the current "headphones" idea. A new logo would continue to have the "Audacity" name followed by the ® registered trademark symbol.

Similarly, please link to images of suggested new skins on Proposal New Skins. However, don't expect anything to change in the immediate future.

We also have received offers of help with redesigning or "modernising" our websites, especially the main site https://web.audacityteam.org/. We're always interested in hearing well-argued suggestions for improvements, but we do not want to make change just for the sake of a "new look".

Some other specifics

  • We changed "About Audacity" to use use the same smaller logo and higher screen position of the "Welcome Message".

To be considered:

  • 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.

SD: If also applied to Nyquist plug-ins it would be impossible for users to input a path or file name.

  • [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.