Difference between revisions of "Slicer3:Interface Design and Usability"

From NAMIC Wiki
Jump to: navigation, search
Line 32: Line 32:
 
* design mechanism for centrally specifying look & feel (and permitting overrides);
 
* design mechanism for centrally specifying look & feel (and permitting overrides);
  
'''Status:''' completed alpha, beta versions; ongoing refinement.
+
'''Status:''' beta. ongoing refinement.
  
 
=== [[Slicer3:UIDesign|UI Design]] ===
 
=== [[Slicer3:UIDesign|UI Design]] ===
Line 66: Line 66:
  
 
'''Status:''' complete.
 
'''Status:''' complete.
 
 
  
 
= User Feedback: Feature, Resource, Application Convention Requests =
 
= User Feedback: Feature, Resource, Application Convention Requests =

Revision as of 16:16, 20 June 2007

Home < Slicer3:Interface Design and Usability

<< Back to Slicer3 main page

Go to Slicer3 Developer Info >>



Project goals

  • Design and engineer Slicer3 UI.
  • Develop human interface and style guidelines for developers.
  • Develop a user-centered design practice for developers.
  • Design a new brand for Slicer3.
  • Develop visual communication guidelines for the Slicer3 brand.

Project overview

The scope of this effort is sorted into four categories: Engineering, UI design, Usability and Slicer3 branding. The subtasks of each category are itemized below and specific information about each category is located on the linked pages.

UI Architecture & Engineering

Tasks: (more detailed UI Architecture & Engineering information can be found on the UI Architecture & Engineering page).

  • design thin GUI layer, separate from the control logic and data model;
  • design a model for representing the UI and managing local events;
  • extend the model for handling remote events;
  • design means of mapping KWWidgets onto that model;
  • set priorities with Kitware involving extensions & modifications to KWWidgets;
  • determine the api to application logic, used by GUI and by scripts;
  • design set of base classes for slicer modules and custom widgets that give module developers an easy pattern to follow;
  • develop guidelines for slicer base developers and module developers;
  • design mechanism for centrally specifying look & feel (and permitting overrides);

Status: beta. ongoing refinement.

UI Design

Tasks: (more detailed UI Design information can be found on the UI Design page ).

  • design overall look to Slicer3 application in keeping with core values;
  • design look & feel applied to developer modules;
  • implement Slicer3 Application GUI
  • design conventions for specifying global and module-specific keyboard accelerators;
  • specify and document global keyboard accelerators;
  • iterate on prototype(s) and present them for comments and suggestions;
  • develop and publish Human Interface & Slicer Style Guidelines for Developers (currently under development).

Status: main application GUI complete. Time should be allocated for user-centered refinement of core module GUIs which were hurriedly assembled. Style guidelines are currently being drafted.

Usability

Tasks: (more detailed Usability information can be found on the Slicer3 Usability page ).

  • develop and publish a light-weight user-centered design practice that support usability and software consistency.
  • use this process to design and implement main application interface, and some core functionality.
  • promote awareness of this process and encourage its adoption among developers

Status: practice is developed and published on the wiki. We have used this practice where appropriate on some base modules. The practice has not yet been actively promoted.

3DSlicer Brand

Tasks: (Slicer3 brand sketches can be found on the Slicer3 Brand page ).

Status: complete.

User Feedback: Feature, Resource, Application Convention Requests

We are collecting feature, conventions and resource requests from users and developers. Appropriate entries from Slicer2's bug tracker will be periodically added to this repository also.


Working questions

  • Getting correct render window size information from vtkKWRenderWidget (answer: yes, vtkKWRenderWidget::GetWidth() is actually its superclass' vtkKWFrame::GetWidth(), which is misleading, it's more a "requested width" kind of option. What you did by calling Tk is OK).
  • First pack/unpack of Nav/Zoom widget interacting with scrollbar, making display flash (answer: fixed, update KWWidgets, in vtkSlicerViewControlGUI::PackZoom/NavWidget replace "-fill x -fill y" by "-fill none" if it is still flashing)
  • Registry and window size (answer: investigating)
  • Progress feedback (answer: vtkKWWindowBase::GetProgressGauge()::SetValue())
  • Using registry (what application and module state is reasonable to save?) (answer: I would recommend: the last selected module, the collapsed state of "Manipulate Slice Views", "Manipulate 3D View", the layout (i.e. 1 over 3, or 2x2,etc), if the slice controls are collapsed or not).
  • In the toolbar, the indicator should be off, and we could use a different image for the selected and unselected state of a button. Sadly, doing so still seems to make the button recess/shift when it is selected (answer: investigated this one thoroughly, there is sadly no work around that, it's a Tk problem unfortunately).

Return to Slicer3 Interface Design and Usability

Return to Slicer3 main page