Documentation-Rons-Rules-For-Tools - Revision history

Kikinis: /* Introduction */

2015-12-10T18:26:23Z

Introduction

2014-09-14T16:01:27Z

2014-09-14T15:59:39Z

2012-10-03T11:46:39Z

Introduction

2011-04-21T22:20:37Z

Introduction

2011-03-17T11:33:01Z

2011-03-17T11:31:29Z

Introduction

2011-03-07T14:09:31Z

Introduction

2011-03-07T14:09:18Z

Introduction

2011-03-07T14:07:56Z

@@ Line 10: / Line 10: @@
 *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!
+#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

@@ Line 1: / Line 1: @@
 =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.
-<BR>A [[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.
+<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. <ref>tools need to be robust and function with a variety of workflows, not only the one envisioned by the developer</ref>

@@ Line 1: / Line 1: @@
 =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.
 #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>

@@ Line 11: / Line 11: @@
 #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!
 </ref>
-#I have ADD. Make your algorithm fast. <ref>Performance Requirements
+#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)

@@ Line 12: / Line 12: @@
 </ref>
 #I have ADD. Make your algorithm fast. <ref>Performance Requirements
 * instantaneous is what I really want (this is where the slider comes in)
 * under a minute is good

@@ Line 3: / Line 3: @@
 #You make it, I break it
-#Your tool does not exist until it works on my laptop with my data. <ref>Until then, it's an unconfirmed rumor.</ref>
+#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. I do not like to move the mouse or to type. <ref>User friendliness:
 *Minimize the number of clicks