Difference between revisions of "Documentation-Rons-Rules-For-Tools"

From Slicer Wiki
Jump to: navigation, search
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
=Introduction=
 
=Introduction=
 
"Rules for tools" is an informal set of rules that developers should keep in mind when working on '''interactive tools''' for translational clinical research. If you follow them, you will create tools that many people will use.
 
"Rules for tools" is an informal set of rules that developers should keep in mind when working on '''interactive tools''' for translational clinical research. If you follow them, you will create tools that many people will use.
 +
<BR>A [[media:2014-09-13b-Rules for tools.pdf|presentation]] on this topic was given at the [http://interactivemedical.org/imic2014/index.html IMIC workshop] at MICCAI 2014.
  
−
#You make it, I break it
+
#You make it, I break it. <ref>tools need to be robust and function with a variety of workflows, not only the one envisioned by the developer</ref>
−
#Your tool works when it works on my laptop with my data. Until then its useless to me.
+
#Your tool does not exist, until it works on my laptop with my data. <ref>Until then, it's an unconfirmed rumor.</ref>
−
#I am lazy. Make my life easy. <ref>
+
#I am lazy. I do not like to move the mouse or to type. <ref>User friendliness:
 
*Minimize the number of clicks
 
*Minimize the number of clicks
 
*Minimize the distance my pointer has to travel
 
*Minimize the distance my pointer has to travel
−
*Make sure your module sets up everything for me, but allow me to override. E.g. if you create an output file, use the input filename plus name of the module.
+
*Have good default values for the parameter and I/O, and allow me to override.  
 +
</ref>
 +
#No more than one simple parameter. <ref>If I need more than 20 seconds to figure out how to set the parameter, I won't! See also [http://www.johndcook.com/blog/2011/06/21/how-to-fit-an-elephant/ here] about the dangers of too many parameters
 +
</ref>
 +
#I have [http://en.wikipedia.org/wiki/Attention_deficit_disorder ADD]. Make your algorithm fast. <ref>Performance Requirements
 +
* ADD = attention deficit disorder
 +
* instantaneous is what I really want (this is where the slider comes in)
 +
* under a minute is good
 +
* 5 minutes are acceptable
 +
*10 minutes or more are not
 
</ref>
 
</ref>
−
#No more than one parameter that I can set.
 
−
#If I need more than 20 seconds to figure out how to set the parameter, I won't!
 
−
#If I can take my lunch break while your algorithm is running, I won't return to it.
 
−
##under a minute is good
 
−
##5 minutes are acceptable
 
−
##10 minutes or more are not
 
  
−
=How To Cope With Variability=
+
==How To Make Algorithms Robust==
−
*Build a case library with 10 cases
+
*Build a case library with 10 or more cases
−
*Use 5 for development, cycle through the cases daily
+
*Use half for development, cycle through the cases daily
−
*Use the other 5 for testing
+
*Use the other half for testing
  
 
==References==
 
==References==
 
<references/>
 
<references/>

Latest revision as of 18:26, 10 December 2015

Home < Documentation-Rons-Rules-For-Tools

Introduction

"Rules for tools" is an informal set of rules that developers should keep in mind when working on interactive tools for translational clinical research. If you follow them, you will create tools that many people will use.
A presentation on this topic was given at the IMIC workshop at MICCAI 2014.

  1. You make it, I break it. [1]
  2. Your tool does not exist, until it works on my laptop with my data. [2]
  3. I am lazy. I do not like to move the mouse or to type. [3]
  4. No more than one simple parameter. [4]
  5. I have ADD. Make your algorithm fast. [5]

How To Make Algorithms Robust

  • Build a case library with 10 or more cases
  • Use half for development, cycle through the cases daily
  • Use the other half for testing

References

  1. ↑ tools need to be robust and function with a variety of workflows, not only the one envisioned by the developer
  2. ↑ Until then, it's an unconfirmed rumor.
  3. ↑ User friendliness:
    • Minimize the number of clicks
    • Minimize the distance my pointer has to travel
    • Have good default values for the parameter and I/O, and allow me to override.
  4. ↑ If I need more than 20 seconds to figure out how to set the parameter, I won't! See also here about the dangers of too many parameters
  5. ↑ Performance Requirements
    • ADD = attention deficit disorder
    • instantaneous is what I really want (this is where the slider comes in)
    • under a minute is good
    • 5 minutes are acceptable
    • 10 minutes or more are not
Retrieved from "https://www.slicer.org/w/index.php?title=Documentation-Rons-Rules-For-Tools&oldid=44321"