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

From Slicer Wiki
Jump to: navigation, search
Line 4: Line 4:
 
#You make it, I break it
 
#You make it, I break it
 
#Your tool works when it works on my laptop with my data. Until then its useless to me.
 
#Your tool works when it works on my laptop with my data. Until then its useless to me.
#I am lazy. Make my life easy.
+
#I am lazy. Make my life easy. <ref>
##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.
+
*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.
 +
</ref>
 
#No more than one parameter that I can set.  
 
#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 need more than 20 seconds to figure out how to set the parameter, I won't!
Line 19: Line 20:
 
*Use 5 for development, cycle through the cases daily
 
*Use 5 for development, cycle through the cases daily
 
*Use the other 5 for testing
 
*Use the other 5 for testing
 +
 +
==References==
 +
<references/>

Revision as of 13:49, 7 March 2011

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.

  1. You make it, I break it
  2. Your tool works when it works on my laptop with my data. Until then its useless to me.
  3. I am lazy. Make my life easy. [1]
  4. No more than one parameter that I can set.
  5. If I need more than 20 seconds to figure out how to set the parameter, I won't!
  6. If I can take my lunch break while your algorithm is running, I won't return to it.
    1. under a minute is good
    2. 5 minutes are acceptable
    3. 10 minutes or more are not

How To Cope With Variability

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

References

    • Minimize the number of clicks
    • 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.