diff --git a/Documentation/Doxygen/3-DeveloperManual/Concepts/DataInteractionTechnical.dox b/Documentation/Doxygen/3-DeveloperManual/Concepts/DataInteractionTechnical.dox
index aaf338b57f..81a9c4f992 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Concepts/DataInteractionTechnical.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Concepts/DataInteractionTechnical.dox
@@ -1,115 +1,119 @@
 /**
 
 \page DataInteractionTechnicalPage Interaction Concept Implementation
 
 \tableofcontents
 
 This page describes some technicalities of the implementation and the workflow, for a detailed list of tutorials see \ref FurtherReadingInteraction .
 
 \section DataInteractionTechnicalPage_Introduction Description of Interaction Concept Implementation in MITK
 
 
 \section DataInteractionTechnicalPage_DispatcherSection Dispatcher
 
 After an event is received by the mitk::Dispatcher it is given to a mitk::DataInteractor that has to decide if it can process this event.
 On a high level this is done by the mitk::EventStateMachine.
 First the state machine asks if the received event is known in the
 configuration. If it is, the matching variant name is returned. Then the state machine checks if there exists a transition
 in its current state that is triggered by this event variant. If this is the case all actions that are associated with this transition
 are queried and executed. The actions themselves are implemented on mitk::DataInteractor level. The following diagram illustrates the process:
 
 \imageMacro{sm_and_config.png,"",16}
 
 
 Each mitk::BaseRenderer creates a mitk::BindDispatcherInteractor object which encapsulates the connection between the mitk::DataStorage and
 the mitk::Dispatcher, and thereby allowing a mitk::DataInteractor to register with a mitk::Dispatcher when only knowing the mitk::DataNode.
 
 mitk::BindDispatcherInteractor creates a new mitk::Dispatcher object and registers for mitk::DataNode events at the mitk::DataStorage, as a callback function the
 dispatchers AddDataInteractor() and RemoveDataInteractor() functions are set.
 
 \dot
 digraph {
   node [shape=record, fontname=Helvetica, fontsize=10];
   a [ label="{BaseRenderer|m_BindDispatcherInteractor}"];
   b [ label="{BindDispatcherInteractor|m_Dispatcher\n m_DataStorage}" ];
   c [ label="Dispatcher" ];
   d [ label="DataStorage" ];
   a -> b;
   b -> c;
   b -> d;
 }
 \enddot
 
 This way the mitk::Dispatcher is notified about all changes regarding
 DataNodes that are shown in the mitk::BaseRenderer. When a node is added, remove or modified the mitk::Dispatcher can check if a mitk::DataInterator is set,
 and accordingly add or remove this mitk::DataInteractor from its internal list.
 
 \dot
 digraph {
-  node [shape=record, fontname=Helvetica, fontsize=10];
-  d [ label="DataInteractor" ];
-  a [ label="DataNode" ];
-  b [ label="DataStorage" ];
-  c [ label="Dispatcher" ];
+  node [shape=box fontname=Helvetica fontsize=10]
+
+  { rank=same b c a }
+  { rank=same e }
+
+  d [ label="DataInteractor" ]
+  a [ label="DataNode" ]
+  b [ label="DataStorage" ]
+  c [ label="Dispatcher" ]
   e [ label="BaseRenderer"]
-  edge [fontname=Helvetica, fontsize=10]
-  d -> a [label="SetDataInteractor(this)"];
-  a -> b [label="Modified()"];
-  b -> c [label="NodeModified(dataNode)"];
-  e -> c [label="HandleEvent(interactionEvent)"];
- { rank=same; b c a }
- { rank=same; e }
+
+  edge [fontname=Helvetica fontsize=10]
+
+  d -> a [label="SetDataInteractor(this)"]
+  a -> b [label="Modified()"]
+  b -> c [label="NodeModified(dataNode)"]
+  e -> c [label="HandleEvent(interactionEvent)"]
 }
 \enddot
 
 Events that are generated within the scope of the mitk::BaseRenderer are sent to the associated mitk::Dispatcher to be handled.
 
 
 \subsection DataInteractionTechnicalPage_DispatcherEventDistSection Event Distribution
 
  A mitk::Dispatcher can operate in different processing modes, which determine how the interactor that receives an event is chosen.
  These modes are managed and set by the mitk::Dispatcher itself.
 
 <ul>
  <li> \b Regular: \n
     DataInteractors are sorted by their layer, and distribution is stared with the top-most.
 
  <li> <b>Connected Mouse Action</b>: \n
     A connected mouse action is described by the sequence of Mouse-Press, (optionally) Mouse-Move , Mouse-Release Events.\n
       Within this sequence all events are sent to the same mitk::DataInteractor, the one which received the event from the Mouse-Press action.\n
       \b m_ConnectedMouseAction  - is set to true, when a Mouse-Down Event occurs and a DataInterator takes the event and
       \b m_SelectedInteractor is then set to this DataInteractor.\n
       \b m_ConnectedMouseAction is reset to false, after the Mouse-Release Event occurs,\n
       while it is true, the m_SelectedInteractor is the only one that receives Mouse-Events.
 
  <li> <b>Grab Input</b>:\n
       Whenever a mitk::DataInteractor performs a state change into a state that is marked by the grab input-tag, the mitk::Dispatcher switches into this mode.
       As long as it is in this mode ONLY the selected mitk::DataInteractor will receive the event. This mode is ended when the mitk::DataInteractor
       switches back to a state without a tag/ or the REGULAR-tag.\n
       \note In this mode mitk::InteractionEventObserver instances will NOT receive the events.
 
    <li> \b Prefer \b Input: \n
       Basically works as Grab Input, with the difference that if the mitk::DataInteractor is in the prefer input state but cannot process the event offered,
       it will be offered to the other interactors in the regular way.\n
       In this mode mitk::InteractionEventObserver instances ARE informed.
 
 </ul>
 \section DataInteractionTechnicalPage_StateMachineSection State Machine & Configuration
 
 A  mitk::EventStateMachine points to a \b state, which in turn references  \b transitions
 (which describe a change from one state to another) and \b actions (indicating which functions are executed when a transition is taken).
 \dot
 digraph {
   node [shape=record, fontname=Helvetica, fontsize=10];
   d [ label="{StateMachine|m_CurrentState}" ];
   a [ label="{StateMachineState|m_Transitions}" ];
   b [ label="{StateMachineTransitions|m_Actions}"];
   c [ label="{StateMachineAction}"];
   edge [fontname=Helvetica, fontsize=10]
   d -> a [label="1 : 1"];
   a -> b [label="1 : n"];
   b -> c [label="1 : n"];
 }
 \enddot
 
  */