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.