<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="pattern.xsl"?>
<pattern id="">
  <name>Controller</name>
  <relatedPatterns>
    <relatedPattern ref="">
	<patternLink>Mapping</patternLink>
    </relatedPattern>
  </relatedPatterns>
  <!-- The diagram is a graphic representation of the pattern.-->
  <diagram>
  	<web>
	 <img src="DiagramCont.gif" width="400"  />
	</web>
  <latex>
    <img src="DiagramCont.pdf" width="400"  />
    </latex>
  </diagram>
  <what>
    <paragraph> 
      Control (a part of) a model through a simple separate model.
    </paragraph>
  </what>
  <when>
    <paragraph> 
      The essence of parametric modeling is the parameter---a variable
      that influences other parts of the design. Understanding how
      parameters affect a design is a crucial part of the modeling
      process. Use this pattern when you want to interact with your
      model in a clear and simple way, OR you want to convey to others
      how you intend a model to be changed. <em>Remember, in the future
      you may well be such another person if you have forgotten the
      model structure!</em>
    </paragraph>
  </when>
  <why>
    <paragraph>
      Isolating manipulations to a simple place away from the complex
      detail of a model means that you can change the model more
      easily. Using a logic for control that is different from the way
      the model is defined means that you can use the most appropriate
      interaction metaphor.  Changing a collection of objects through
      a single interface simplifies the interaction task.
    </paragraph>
    <paragraph>
      As models grow, so does the need for a carefully considered set
      of <patternName>Controllers</patternName>. In particularly complex models, you may well
      design and implement a separate control panel that collects all
      of the <patternName>Controllers</patternName> into a single place in the interface.
    </paragraph>
  </why>
  <how>
    <paragraph>
      A <patternName>Controller</patternName> can do either or both of
      the following: it can abstract an aspect of a model into a clear and
      simple device or it can transform an aspect of a model into a different
      form.
    </paragraph>
    <paragraph>
      The key concept in a <patternName>Controller</patternName> is
      separation. You build a separate model whose outputs link to the
      inputs of your main model.  The separate model is the
      <patternName>Controller</patternName>. It should express, simply
      and clearly, the way you intend to change the model.
    </paragraph>
    <paragraph>
      <patternName>Controllers</patternName> can abstract or transform
      and they can do both at the same time.  An abstracting
      <patternName>Controller</patternName> is a simple version of the
      main model that suppresses unneeded detail.  Parameters on lines
      and curves are very simple case of a
      <patternName>Controller</patternName>: they abstract a location
      on a curve into a single number.  The layout of controls on a
      properly designed stovetop directly abstracts the layout of the
      burners. In contrast, the vast majority of stovetop controls
      fail to do this well.
    </paragraph>
    <paragraph>
      A transforming <patternName>Controller</patternName> changes the
      way you interact with a model. For example, polar coordinates
      transform Cartesian coordinates <latex>\index{coordinates!Cartesian}</latex> into a different set of inputs.
      A rotating knob on a stovetop transforms the amount of energy
      delivered into an angle<latex>\index{angle}</latex>.
    </paragraph>
    <paragraph>
      As one property changes in your model, one or more parts change;
      you can connect these changing properties through a
      <patternName>Controller</patternName>.  Then, you can simply
      change the <patternName>Controller</patternName> and see the
      result in your model. <patternName>Controllers</patternName> are
      thus independent---they have minimal connection to the model
      they control and are easily connected and disconnected as
      needed. This separation is the hallmark of a
      <patternName>Controller</patternName>: every well-designed
      <patternName>Controller</patternName> will have a symbolic model
      that shows only one or a scant few links<latex>\index{link}</latex> between it and the
      model it controls.
    </paragraph>
  </how>
  <samples>

    <sample id=" ">
      <name>Vertical Line</name>
      <when>
	<paragraph> 
	  Control the position of a
	  vertical line<latex>\index{line}</latex> on a curve<latex>\index{curve}</latex> with a
	  <patternName>Controller</patternName>.
	</paragraph>
      </when>
      <how>
	<paragraph> 
	  Curves<latex>\index{curve}</latex> and
	  surfaces<latex>\index{surface}</latex> are complex
	  objects. Their parametric structure is typically hidden from
	  the interface -- a point<latex>\index{point}</latex> may move quickly in one part of a
	  curve and slowly in another as its parameter
	  changes. Further, curves and surfaces are usually part of a
	  design. There may be many other objects around them that
	  make it difficult to directly interact with their parametric
	  points. Controlling a point on a curve through a parametric
	  point on a line<latex>\index{line}</latex> addresses both of these issues. You can see
	  the relative parameterization of a curve point by examining
	  its controlling point. Further, the controlling point can be
	  in any position, near to or far from the model.
	</paragraph>
	<paragraph>
	  In this model, a single vertical line takes its position
	  from a parametric point on the curve <math>pOnCrv</math>.
	  The <patternName>Controller</patternName> is a line 
	  and a parametric point on it. Making the parameter of the
	  <math>pOnCrv</math> dependent on the point in the
	  <patternName>Controller</patternName> transfers control from
	  the curve to a straight line.
	</paragraph>
	<paragraph>
	  This is a very simple sample, but it demonstrates the
	  essential idea of separation of control and model. 
	</paragraph>
      </how>
      <file href="Samples/ContVerticalLine/ContVerticalLine.gct" />
      <animation src="Samples/ContVerticalLine/AnimationVerticalLine.swf"/>
    </sample>


    <sample id=" ">
      <name>Line Length</name>
      <when>
	<paragraph>
	  Change the length of a vertical line<latex>\index{line}</latex> with a slider.
	</paragraph>
      </when>
      <how>
	<paragraph>
	  This is a very simple sample of the
	  <patternName>Controller</patternName>, but one that
	  transforms a length in one direction to a length in
	  another. Start with a vertical line and a horizontal
	  <patternName>Controller</patternName> line. Connect the
	  length of the vertical line to the parameter of the point<latex>\index{point}</latex> on
	  the <patternName>Controller</patternName> line. Moving the
	  point in the <patternName>Controller</patternName> alters
	  the length of the vertical line.<latex>\vspace{12pt}</latex>
	</paragraph>
      </how>
      <file href="Samples/ContLineLength/ContLineLength.gct" />
      <animation src="Samples/ContLineLength/AnimationLineLength.swf"/>
    </sample>

    <latex>\renewcommand{\sampleNewPage}[0]{false}</latex>
    <sample id=" ">
      <name>Multiple Circles</name>
      <when>
	<paragraph>
	  Change the number of concentric circles with a slider.
	</paragraph>      
      </when>
      <how>
	<paragraph>
	  The quantities controlled can be continuous (a real number)
	  or discrete (an integer or member of a sequence or set). In
	  this sample, a slider controls the numbers of concentric
	  circles. The parametic point on the slider connects to the
	  creation method of the circle<latex>\index{circle}</latex>. In this sample, the number of
	  the circles is determined by the parameter of the point on
	  the slider. As the parameter of the point<latex>\index{point}</latex> changes from
	  <math>0</math> to <math>1</math>, the number of circles will
	  change from <math>m</math> (in this case <math>m=0</math>)
	  to a predetermined number <math>n</math>. This
	  <patternName>Controller</patternName> requires a mapping<latex>\index{mapping}</latex>
	  between <math>0-1</math> and <math>1-n</math>. The actual
	  math is simple: the number of circles for a given parameter
	  <math>t</math> is <math>\afFunc{Floor}{t/(n-m)}</math>. This
	  idea of mapping though is so general that it has its own
	  pattern: the <patternLink>Mapping</patternLink> pattern.
	</paragraph>
	<paragraph>
	  Controlling a discrete variable with a continuous slider can
	  be visually dissonant: the slider seems smooth yet the
	  result changes in steps. A typical solution is to mark the
	  slider at the locations at which the number of discrete
	  objects changes.
	</paragraph>
      </how>
      <file href="Samples/ContCircles/ContCircles.gct" />
      <animation src="Samples/ContCircles/AnimationCircles.swf"/>
    </sample>

    <sample id=" ">
      <name>Cone Radii</name>
      <when> 
	<paragraph>
	  Change the radii of a cone<latex>\index{cone}</latex> with a pair of concentric circles<latex>\index{circle}</latex>.
	</paragraph>
      </when>
      <how>
	<paragraph>
	  A single <patternName>Controller</patternName> can control multiple
	  aspects of a design. Of course, this poses a design problem in and of
	  itself. The <patternName>Controller</patternName> must visually cohere
	  with the object being controlled. In this sample, the aim is to
	  control the top and bottom radii of a cone. The <patternName>Controller</patternName> maps from
	  cocentric, coplanar circles to the cone's top and bottom surfaces. The <patternName>Controller's</patternName>
	  circles are controlled by points on their boundary. Two links from the
	  radii of the <patternName>Controller's</patternName> circles to the
	  cone radii connect the <patternName>Controller</patternName> to the
	  model.  The
	  <patternName>Controller</patternName> circles provide a
	  visual reminder of the real objects being controlled: the
	  top and bottom of the cone. 
	</paragraph>
	<paragraph>
	  Most of the time, the relative size of the circles when compared with
	  the cone suffices to distinguish the link between aspects of the
	  <patternName>Controller</patternName> and model. Even in this simple
	  case, such geometric coincidence may not suffice, for example, when
	  viewing in perspective or when the two radii are very close. Other
	  codes, such as colour (careful here!), text, line weight or graphic
	  labels, might be useful.
	</paragraph>
      </how>
      <file href="Samples/ContCone/ContCone.gct" />
      <diagram>
	<img src="Samples/ContCone/ContConeDiagram.pdf"   />      
      </diagram>
      <animation src="Samples/ContCone/AnimationCone.swf"/>
    </sample>

    <sample id=" ">
      <name>Equalizer</name>
      <when>
	<paragraph>
	  Adjust the height of multiple cylinders<latex>\index{cylinder}</latex> with a equalizer.
	</paragraph>
      </when>
      <how>
	<paragraph>
	  In this sample, the <patternName>Controller</patternName> takes
	  advantage of a roughly linear arrangement of objects in the model by
	  using the well-known design for a sound equalizer. The equalizer is a
	  row of sliders, each interactively independent of the others. This
	  design puts the controlled dimensions into visual proximity and thus
	  reveals their relative sizes, which might well be obscured in the
	  model due to location, size and perspective effects. 
	</paragraph>
	<paragraph>
	  This <patternName>Controller</patternName> misses an
	  important aspect of the design of a physical sound equalizer. With
	  such a device an operator can use his or her entire hand to
	  simultaneously control several dimensions and to achieve a smooth
	  curve across dimensions. The computer mouse, with its relentless
	  one-thing-at-a-time design impoverishes the potential interactivity of
	  the <patternName>Controller</patternName>.  Some of this could be
	  recovered by using a <patternLink>Reactor</patternLink> or
	  <patternLink>Selector</patternLink> pattern as part of the
	  <patternName>Controller</patternName> itself.
	</paragraph>
      </how>
      <file href="Samples/ContEqualizer/ContEqualizer.gct" />
      <diagram>
	<img src="Samples/ContEqualizer/ContEqualizerDiagram.pdf"   />
      </diagram>
      <animation src="Samples/ContEqualizer/AnimationEqualizer.swf"/>
    </sample>

    <sample id=" ">
      <name>Parallel Lines</name>
      <when>
	<paragraph>
	  Adjust the length and position of a line parallel to a
	  reference line<latex>\index{line}</latex>.
	</paragraph>
      </when>
      <how>
	<paragraph>
	  In this sample, a single control parameter affects multiple model
	  parameters. It is the converse of the samples above, in which multiple independent
	  controls comprise the <patternName>Controller</patternName>. In the
	  model, a reference line establishes the direction and maximum length
	  of the result line.  The
	  <patternName>Controller</patternName> comprises a single
	  line carrying a parametric point<latex>\index{point}</latex>. The direction and length
	  of the <patternName>Controller</patternName> line determines
	  the direction and length of a <em>guide</em> line that
	  orginates at one end of the reference line. A parametric
	  point on the guide line gets its parameter from the
	  <patternName>Controller</patternName> and is the start point
	  for the result. The result line gets its direction from the
	  reference and its length from the <patternName>Controller</patternName>.
	</paragraph>
	<paragraph>
	  If you move the <patternName>Controller</patternName>
	  parametric point, both the length of the result and its
	  distance from the reference change. If you move the
	  <patternName>Controller</patternName> line, the guideline
	  moves to remain parallel.
	</paragraph>
	<paragraph>
	  This <patternName>Controller</patternName> combines mutiple
	  controls (line length, direction and parametric distance) to
	  control multiple aspects of its result (distance, radial
	  position, and length). It also controls multiple aspects of
	  the result with a single control: both length and distance
	  of the result line are a function of parametric
	  distance. Sometimes, such <em>interdependence</em> is
	  intentional. More often though, it can confuse: the result
	  of the <patternName>Controller</patternName> becomes opaque with increasing complexity
	  in it relation to the model. Don Norman <latex>\cite{NORMAN1988}</latex>
	  is highly critical of such linked controls.  Be warned: good
	  <patternName>Controllers</patternName> can be hard to write.
	</paragraph>
      </how>
      <file href="Samples/ContParallelLines/ContParallelLines.gct" />
      <animation src="Samples/ContParallelLines/AnimationParallelLines.swf"/>
    </sample>

    <sample id=" ">
      <name>Right Triangle</name>
      <when>
	<paragraph>
	  Create different right triangles with the same base.
	</paragraph>
      </when>
      <how>
	<paragraph>
	  The right triangle<latex>\index{triangle}</latex> is a fascinating and useful geometric object. Some
	  of its instances have Pythagorean triples as dimensions; its
	  hypoteneuse is the diameter of its circumscribed circle; it combines
	  to form rectangles; and the sum of its two non-right angles is <math
	  latex="90^\circ">90 degrees</math>. Each of these could be the base
	  for a <patternName>Controller</patternName> design.
	</paragraph>
	<paragraph>
	  This <patternName>Controller</patternName> uses the last of the above
	  features, by using a half-circle to express the <math latex="180^{\circ}">180 degree</math> triangle angle sum. The base of the
	  half-circle  gives the direction and length of the resulting triangle
	  base. Rays between the circle<latex>\index{circle}</latex> centre and two points on the circle
	  represent the direction of the sides of the triangle. If these two
	  points move freely on the half-circle, they specify an arbitrary
	  triangle. Presume that the half-circle has a <math>0-1</math>
	  parameter domain. If the parameter <math>t</math> of one of these
	  points is constrained to the domain <math>0.0-0.5</math> and the
	  other to the domain <math>t+0.5</math>, the generated triangle will
	  always be right-angled. Further, all right angled triangles can be
	  reached. 
	</paragraph>
	<paragraph>
	  This <patternName>Controller</patternName> reveals that right-angled
	  triangles are two-parameter objects: the hypoteneuse length
	  and one angle suffice to uniquely determine the triangle up to
	  a rigid body motion. It does visually invert both the angle and
	  side when compared with the result. In reading across both
	  <patternName>Controller</patternName> and model, you encounter the
	  angles and lengths in reverse order. Some visual coherence has been
	  traded for geometric insight.
	</paragraph>
      </how>
      <file href="Samples/ContTriangle/ContTriangle.gct" />
      <latex>
      	    \begin{bodyNote}
 	      \pbOneCol
	        {\input{\GCFigsPath/Patterns/ControllerRightTriangleDiagram0.tex}}
      	    \end{bodyNote}
      </latex>
      <web>
      <diagram>
	<img src="Samples/ContTriangle/ContTriangleDiagram.jpg"   />      
      </diagram>
      </web>
      <animation src="Samples/ContTriangle/AnimationTriangle.swf"/>
    </sample>

    <sample id=" ">
      <name>Hyperboloid of One Sheet</name>
      <when>
	<paragraph>
	  Abstract the geometry of a hyperboloid<latex>\index{hyperboloid}</latex> of one sheet to a plane<latex>\index{plane}</latex>.
	</paragraph>
      </when>
      <how>
	<paragraph>
	  A <em>hyperboloid of one sheet</em> is a ruled surface<latex>\index{surface!ruled}</latex>, that
	  is, it can be formed from a sequence of straight
	  lines<latex>\index{line}</latex>. Further, it is doubly ruled: two such sequences can
	  be combined into a lattice, making the form structurally
	  efficient. Conceptually, a hyperboloid can be defined by
	  twisting two parallel circles that have their centres on a
	  common normal line.
	</paragraph>
	<paragraph>
	  The hyperboloid's independent parameters are the radii of
	  the two circles and the twist of one circle<latex>\index{circle}</latex> relative to the
	  other. Starting with the
	  <patternName>Controller</patternName> from the
	  <name>Cone</name> sample, add a twist control to one circle.
	</paragraph>
	<paragraph>
	  Of course, the <patternName>Controller</patternName> has geometric limits, ranging from
	  but not including <math>-180</math> to <math>180</math>
	  degrees. A twist of <math>180</math> degrees turns the
	  hyperboloid into a cone. Two surfaces with twist parameter
	  <math>a</math> and <math>-a</math> are geometrically the
	  same but logically distinct. The difference is that the two
	  sets of generating lines are transposed. If one set carries
	  information distinct from the other, the resulting design
	  will differ as well.
	</paragraph>
      </how>
      <file href="Samples/ContTwistedLines/ContTwistedLines.gct" />
      <latex>
	     \setlength{\storedWidth}{\currentWidth}
             \setlength{\currentWidth}{\currentWidth*\real{0.8}}
             \hfill</latex>
      <diagram>
	<img src="Samples/ContTwistedLines/ContTwistedLinesDiagram.pdf" />
      </diagram>
      <latex>
             \hfill
             \setlength{\currentWidth}{\storedWidth}
      </latex>
      <animation src="Samples/ContTwistedLines/AnimationTwistedLines.swf"/>
    </sample>
    
    <sample id=" ">
      <name>Azimuth Altitude</name>
      <when>
	<paragraph>
	  Control a direction by its <em>azimuth</em> and <em>altitude</em>.
	</paragraph>
      </when>
      <how>
	<paragraph>
	  The <em>azimuth</em> of a point<latex>\index{point}</latex> with respect to a
	  reference is the horizontal angle from a reference
	  direction. The <em>altitude</em> is the vertical angle<latex>\index{angle}</latex>
	  from the horizontal plane. As controls, azimuth
	  and altitude are independent: they specify
	  clearly separate changes to a point. Of course,
	  azimuth and altitude relate to two
	  of the dimensions of a <em>spherical</em> coordinate system
	  <em>(azimuth, zenith</em> and <em>radius</em>), with
	  <math latex="\afVar{zenith} = 90 - \afVar{altitude}">zenith = 90 - altitude</math>.
	</paragraph>
	<paragraph> 
	  An <patternName>Azimuth Altitude Controller</patternName>
	  comprises two concentric circles<latex>\index{circle}</latex> with equal radii: one
	  horizontal and one vertical. A parametric point on the
	  horizontal cricle determines both azimuth of
	  <math>t*360</math> degrees and the vertical plane on which
	  the altitude circle lies. A parametric point on the altitude
	  circle determines the altitude. The <patternName>Controller</patternName>
	  is easily programmed to report the angles it produces.
	</paragraph>
	<paragraph> 
	  In this sample, the model is simple: a pyramid with apex
	  controlled by a line of fixed length and direction given by
	  the <patternName>Controller</patternName>. Four points make the base of the
	  pyramid. The start point of the controlling line is the
	  intersection of the base diagonals. The direction is that of
	  the <patternName>Azimuth Altitude Controller</patternName>
	  and the distance from start to end is a predetermined value,
	  set outside of the <patternName>Controller</patternName>.
	</paragraph> 
      </how>
      <file href="Samples/ContAzimuthAltitude/ContAzimuthAltitude.gct"/> 

      <latex>
	\setlength{\storedWidth}{\currentWidth}
        \setlength{\currentWidth}{\currentWidth*\real{0.8}}
	\hfill
      </latex>
      <diagram>
	<img src="Samples/ContAzimuthAltitude/ContAzi.pdf"/>
      </diagram>
      <latex>
	\hfill
      \setlength{\currentWidth}{\storedWidth}
      </latex>

      <animation src="Samples/ContAzimuthAltitude/AnimationAzimuthAltitude.swf"/>
    </sample> 
  </samples> 
</pattern>


