Difference between revisions of "Slicer3:TranslatingBrandIntoUIDesign"

From Slicer Wiki
Jump to: navigation, search
(Created page with 'Return to Slicer3 Interface Design and Usability <br> = General Design Guidelines that Reinforce Slicer's Brand =')
 
m (Text replacement - "\[http:\/\/www\.slicer\.org\/slicerWiki\/index\.php\/([^ ]+) ([^]]+)]" to "$2")
 
(17 intermediate revisions by one other user not shown)
Line 4: Line 4:
  
 
= General Design Guidelines that Reinforce Slicer's Brand =
 
= General Design Guidelines that Reinforce Slicer's Brand =
 +
 +
==Core values of the 3D Slicer software and development effort==
 +
 +
===Software associations:===
 +
 +
* Clarity & usability
 +
* Control & Precision
 +
* Information richness
 +
* Interactive & responsive
 +
* Reliable & Trusted
 +
* Easily extensible
 +
* Open source & cross-platform
 +
* Showcase for advanced research
 +
 +
===Effort associations:===
 +
 +
* Advancing scientific research
 +
* Assisting treatment/therapy
 +
* Established and long-term
 +
 +
===Design concepts that reinforce the brand===
 +
 +
'''GUI Appearance:'''
 +
* Clean white background
 +
* Precise hairline around buttons, icons, menubuttons, and white background.
 +
* Black text labels where reasonable.
 +
* Verdana is the font of choice, if GUI toolkit permits (can compromise on this for usability issues).
 +
* Icon conventions are [[Slicer3:Human_Interface_and_Style_Guide_for_Developers#Slicer_icon_conventions_.26_developer_resources|here]]
 +
* All icon image data for application GUI can be found in '''Slicer3/Base/GUI/ImageData'''. Individual modules may use these icons too, as well as define their own.
 +
* Conventions for icons as menubuttons, radiobuttons and checkbuttons, see [[Slicer3:Human_Interface_and_Style_Guide_for_Developers#Icons_as_PushButtons.2C_MenuButtons__RadioButtons_and_CheckButtons|here]]
 +
* Application should have a consistent presentation of checkbuttons and radiobuttons. So either use the custom icons provided in above reference, or use default presentation consistently, application-wide.
 +
* It's very important to acknowledge contributing projects, labs, and funding agencies. Provide a standard space for acknowledgement for any software module within the module.
 +
* Preserve the footprint of space beside Slicer's logo; do not include other logos in the main application GUI.
 +
 +
 +
'''Compact, readable design:'''
 +
* Where possible, multiple pop-up interfaces should be avoided; this can lead to clutter.
 +
* Functionality in module interfaces should be clearly and cleanly grouped
 +
* Where possible, group functionality in collapsible frames, so a user can hide unused elements and simplify Slicer's face.
 +
* The highest level of functionality grouping should be visually dominant (e.g. "Input", "Parameters", "Display", "Results"). See [[Slicer3:Human_Interface_and_Style_Guide_for_Developers#Collapsing_and_Tabbed_frame_styles|Stacked or Tabbed groups.]]
 +
* All modules should reinforce the same organization.
 +
* Choose a tabbed panel if each subpanel will require scrolling; choose a stacked panel if there would be too many tabs arrayed horizontally.
 +
* Arrange stacked or tabbed subpanels in an order representing workflow, up-to-down, or left-to-right respectively, where appropriate.
 +
* A secondary level of functionality grouping should be more subtle, and visually distinct from the highest level.
 +
* The density of widgets should be carefully considered. Widget packing should provide enough space to maintain readability, yet be compact enough to minimize the need for scrolling.
 +
* All widgets have balloon help on mouse-over for clarity.
 +
* Maintain keyboard shortcuts if possible. Please keep a consolidated list of all keyboard shortcuts as they are defined.
 +
 +
 +
'''Behavior:'''
 +
* In general, users should have to CLICK the mouse to trigger a UI event. Try to avoid UI behaviors that trigger on mouse-over, except for balloon help.
 +
* Any pop-up widgets that are designed to withdraw on a MouseLeave event should have a footprint big enough so the user doesn't accidentally exit the widget.
 +
* Good to have message dialogs that have "Message" "Warning" "Error" icon on them (this isn't currently consistently presented).
 +
* All collapsing panels should contain an indicator that communicates that they can be opened/closed.
 +
* The option to minimize/hide chrome and GUI around Slice Viewers is required, so a very minimal data viewer can be presented.
 +
* Commonly implemented mouse-control of window/level/threshold would be ideal, or some variation on this that doesn't interfere with pan & zoom.

Latest revision as of 02:29, 27 November 2019

Home < Slicer3:TranslatingBrandIntoUIDesign

Return to Slicer3 Interface Design and Usability


General Design Guidelines that Reinforce Slicer's Brand

Core values of the 3D Slicer software and development effort

Software associations:

  • Clarity & usability
  • Control & Precision
  • Information richness
  • Interactive & responsive
  • Reliable & Trusted
  • Easily extensible
  • Open source & cross-platform
  • Showcase for advanced research

Effort associations:

  • Advancing scientific research
  • Assisting treatment/therapy
  • Established and long-term

Design concepts that reinforce the brand

GUI Appearance:

  • Clean white background
  • Precise hairline around buttons, icons, menubuttons, and white background.
  • Black text labels where reasonable.
  • Verdana is the font of choice, if GUI toolkit permits (can compromise on this for usability issues).
  • Icon conventions are here
  • All icon image data for application GUI can be found in Slicer3/Base/GUI/ImageData. Individual modules may use these icons too, as well as define their own.
  • Conventions for icons as menubuttons, radiobuttons and checkbuttons, see here
  • Application should have a consistent presentation of checkbuttons and radiobuttons. So either use the custom icons provided in above reference, or use default presentation consistently, application-wide.
  • It's very important to acknowledge contributing projects, labs, and funding agencies. Provide a standard space for acknowledgement for any software module within the module.
  • Preserve the footprint of space beside Slicer's logo; do not include other logos in the main application GUI.


Compact, readable design:

  • Where possible, multiple pop-up interfaces should be avoided; this can lead to clutter.
  • Functionality in module interfaces should be clearly and cleanly grouped
  • Where possible, group functionality in collapsible frames, so a user can hide unused elements and simplify Slicer's face.
  • The highest level of functionality grouping should be visually dominant (e.g. "Input", "Parameters", "Display", "Results"). See Stacked or Tabbed groups.
  • All modules should reinforce the same organization.
  • Choose a tabbed panel if each subpanel will require scrolling; choose a stacked panel if there would be too many tabs arrayed horizontally.
  • Arrange stacked or tabbed subpanels in an order representing workflow, up-to-down, or left-to-right respectively, where appropriate.
  • A secondary level of functionality grouping should be more subtle, and visually distinct from the highest level.
  • The density of widgets should be carefully considered. Widget packing should provide enough space to maintain readability, yet be compact enough to minimize the need for scrolling.
  • All widgets have balloon help on mouse-over for clarity.
  • Maintain keyboard shortcuts if possible. Please keep a consolidated list of all keyboard shortcuts as they are defined.


Behavior:

  • In general, users should have to CLICK the mouse to trigger a UI event. Try to avoid UI behaviors that trigger on mouse-over, except for balloon help.
  • Any pop-up widgets that are designed to withdraw on a MouseLeave event should have a footprint big enough so the user doesn't accidentally exit the widget.
  • Good to have message dialogs that have "Message" "Warning" "Error" icon on them (this isn't currently consistently presented).
  • All collapsing panels should contain an indicator that communicates that they can be opened/closed.
  • The option to minimize/hide chrome and GUI around Slice Viewers is required, so a very minimal data viewer can be presented.
  • Commonly implemented mouse-control of window/level/threshold would be ideal, or some variation on this that doesn't interfere with pan & zoom.