Faglig /

Master

Information basis

List of relevant information that is useful to visualize. This information form the model of the visualization. Important aspects are the "hierarchical" structure (i.e. drive granularity), relation among concepts and actors, Availability of information (i.e. "reasonability").

At a later stage it would be beneficial to model this in a formal model (i.e. data model or similar) at least high-level.

Operating Rooms

  • High level state of OR
    • In use / not in use ( including temporal dimension)
  • Position of OR (believe topology is most important)
    • Relative position (i.e. OR1 is to the left of OR2)
    • Absolute position (i.e. coordinates)
      • Can compute relative positions
  • Progress of operation
    • State (Need to define a set of states important for visual relations)
      • Preferably an aggregate that comes from a rule-engine
        • Rule Base; Translate sensor information to semantics ("knowledge database")
        • Rule engine; Decide a state based on semantics from Rule Base
    • Process/flow
      • Predefined - BUT ALSO ALLOW UNDEFINED! (i.e. process model is "history" of operation)
  • Teams
    • Actors (incl. non-human -> equipment)
      • Roles
      • Dependency relative to process/flow of operation
  • Temporal attributes
    • Scheduling (i.e. future)
      • Flag data-set as "future" and add timestamp
    • History (i.e. past)
      • Flag data-set as "past" - timestamp already stored

Visual languages

Propositions for distinctly different visual languages (i.e. visualization methods) that could be evaluated (i.e. tested)

Tag Cloud metaphor

  • Almost; "conceptual model for regular human beings"
  • Dimensions
    • Positioning of concepts
      • Preserve topology, i.e. TextBox1 and TextBox2 positions are correct according to geographical topology ("position") (think metro map)
    • Explore Bertin's Variables for the different attributes
      • Fonts are _only_ parameter (use CSS definitions to elicit)
        • Font-color, font-size, font-orientation, font-texture, font-style (italics, bold, underline, strikethrough), font-type (serif, sans serif....)
        • Explore different shapes for fonts (i.e. circular, rectangular...)
    • Incorporate zones (london subway map)
      • Walking distance, "infection" zones, different buildings etc
  • IDEA; Incorporate actors as "dots" with colour indicating teams (or similar)

Traditional floor plans

  • Highly traditional layout
  • Floor plans with traditional "map techniques"
    • Colour -> state
    • Circles -> actors
    • ++
  • Believed to be "bad" but useful for comparison
  • Non-traditional ideas
    • Rooms shaped with distinct shapes (i.e. stars, clouds etc) and colours
      • Idea; shapes are more easily perceived

Traditional floor plans with embedded conceptual models

  • Floor plans (as described earlier) with conceptual information
    • Conceptual information
      • Relation -> arrows/links
      • Relationship between actors and teams (composed bubbles (I*))
  • Believed to be bad. Useful for comparison

"Traditional" conceptual models

  • Concepts (actors, teams, rooms etc) are bubbles/boxes
  • Relationship are different arrows between boxes
  • Composition (i.e. team/actor/role) following I*/UML or similar
  • Layout;
    • Concepts can be positioned with absolute/relative positions
    • Can be a "cloud" of several process models (i.e. instances of process models) positioned by absolute/relative positions.

Interaction concerns

  • What interaction (if any) should be incorporated?
  • Zooming could be beneficial for some of the approaches
    • Exponential increase of complexity with developing prototype
    • HIGH increase in complexity of cognitive processing
    • Information communicated could possibly be better
    • Enables for different LOD (level of detail)
  • Interactive models are not covered (i.e. NO input from visualization - Read-only)
    • Rational; Changed from other systems/gadgets etc.
    • Cause; Complexity/Time consume for developing prototype and testing
  • Navigation in visual model could be beneficial
    • Panning (... well ...) should be possible to avoid use of panning.
    • "Clicking" to display more information relative to "the click"
      • For instance in separate window / popup or similar
      • Is feasible, but reckon not in first version of prototype

Context sensitivity

  • Need to filter out relevant information for the actor/role that is watching
    • Fully automatic -> Sonitor chip/RFID/WebCam in front of display provides abilities to "know" which actor/role that is watching. (Assuming that this is possible)



Backlinks:

Faglig /
Case (COSTT)