Difference between revisions of "Sept-2009-SlicerWidgetsBrainstorm"
From NAMIC Wiki
Line 29: | Line 29: | ||
** http://gwt.google.com/samples/Mail/Mail.html | ** http://gwt.google.com/samples/Mail/Mail.html | ||
** http://earth-api-samples.googlecode.com/svn/trunk/demos/drive-simulator/index.html | ** http://earth-api-samples.googlecode.com/svn/trunk/demos/drive-simulator/index.html | ||
− | * http://pyjs.org/examples/ | + | * http://pyjs.org |
+ | ** http://pyjs.org/examples/ | ||
+ | ** http://pyjs.org/examples/mail/output/Mail.html |
Revision as of 18:30, 31 August 2009
Home < Sept-2009-SlicerWidgetsBrainstorm- Location: 1249 Boylston Street
- Attendance (People actively involved in Slicer GUI development and use are encouraged to attend and contribute):
- Will Schroeder
- Steve Pieper
- Ron Kikinis
Goals
The purpose of this meeting is to discuss development strategies to migrate Slicer to a new GUI layer. For some background see here.
Important questions to consider at this meeting are:
- What functionality does the application need to have in order to accomplish the needs of our DBP and clinical collaborations over the next several years?
- What look and feel should the application have?
- What capabilities will help us build the community of developers and users
- Standard tools - well supported with ample documentation, support, etc
- Flexibility to run in many environments
- Ease of use and productivity for developers
- Can we get a realistic estimate of the workload required and what skills are required to do the work?
- How much work have comparable project required (by people with what skills and experience?)
- What resources do we have to devote to this project compared with other demands?
- Are we comfortable that we have considered all the viable alternatives?
- What are the trends in GUI interface development for applications like ours
- What are the risks/benefits/complexity trade offs of various approaches