Faglig /

IStar inspired

  • Responsibilities (RB) are boundaries (act as composition concepts)
    • RBs are positioned according to temporal/spatial nearness
    • Tasks on responsibilities (eg. scheduled) are positioned on the boundary edge
    • RBs contain involved actors (patient, dependant other actors [both are of concept actor])
    • Actors have a state which is visualized by their external representation (i.e. colour+++)
    • Actors have a location which is visualized by the concepts position/link _within_ the boundary (eg. opacity, text-label, lines etc)

Coordinate system inspired

  • Responsibilities (RB) are positioned in a 2D coordinate system with dimensions like; TimeToArrival (TTA), TimeToSchedule.
  • Other dimensions, such as importance, are visualized by visual variables (colour, shape, size+++)
  • Downside; Could be difficult to visualize many dimensions (eg. other actors relation to RB and their nearness to the RB)
  • Benefits; Could prove to have very high communication abilities (rapid overview of situation) for a small number of dimensions

Prototype

  • Mobile application or stationary?
    • Develop for both (i.e. support the computation of "i'm here - where are everyone else" and not only; "Where are everyone else - you know where I am")

Architectural strategies

Service oriented - anorectic client

  • Server-side computations only. Server provides services that returns low-level data (image or similar)
  • Benefit; End-device independent (almost any mobile/stationary wifi-enabled device can send an (http) request with their mac/ip address and display an image). Could be fairly rapid development.
  • Downside;
    • Further development of end-user device will require architectural re-design.
    • Could pose performance issues. End-user device could be laggy.

Fat client - anorectic server

  • Client computes the visualization.
  • Server provides information about; actors information, tasks information
    • Server could be eliminated in prototype
  • Benefit; Rapid development. Possibly fast for small information spaces.
  • Downside; Server should do more in real-life settings. Client could suffer performance issues. Client needs to have the spatial information base, or extract of it (could be very large in real-life).
  • Client computes the visualization.
  • Server provides information about; actors information, tasks information
    • Server could be eliminated in prototype
  • Benefit; Rapid development. Possibly fast for small information spaces.
  • Downside; Server should do more in real-life settings. Client could suffer performance issues. Client needs to have the spatial information base, or extract of it (could be very large in real-life).

Limitations and possibilities

Positioning

  • What positioning technology is going to be used
  • SONITOR
    • Requires additional device and; "device->server->client" communication and SonitorDevice and ClientDevice pairing.
    • Provides (by far) _the_ best quality of positioning data (I think...)
  • WIFI
    • Several possibilities
    • Simple; The connected base station is the position
      • Is always wrong, but sufficient?
      • Rapid development (if base stations are positioned already)
    • Advanced; Triangulation of several base stations
      • Not feasible for this project
  • One solution; Client sends a request to server with IAM info (mac-addr, ip, ++) server decides the best position based on whatever information available. Supports modifiability later.

Limitations

Positioning

  • What positioning technology is going to be used
  • SONITOR
    • Requires additional device and; "device->server->client" communication and SonitorDevice and ClientDevice pairing.
    • Provides (by far) _the_ best quality of positioning data (I think...)
  • WIFI
    • Several possibilities
    • Simple; The connected base station is the position
      • Is always wrong, but sufficient?
      • Rapid development (if base stations are positioned already)
    • Advanced; Triangulation of several base stations
      • Not feasible for this project
  • One solution; Client sends a request to server with IAM info (mac-addr, ip, ++) server decides the best position based on whatever information available. Supports modifiability later.

Temporal nearness

  • Need to model walking paths as a graph
    • Nodes being crossroads (or elevators/stairs)
      • In case of elevators/stairs additional "cost" would be added
    • Edged have a cost (i.e. the assumed time to walk it)
      • Automatic calculations (length divided by 6-8km/t)
  • Djikstra on the graph => fastest route one-many
  • Graph should be automatically be generated by building plans (architectural etc)
    • Not feasible in this project, requires heavy analysis

Requirements

  • Real-life examples and "users" for requirements elicitation
    • Through observation or manuscript (i.e. knowledge at hand)
  • If mobile device; Need mobile device with appropriate development interface (see architecture discussion)
  • User testing
    • Test persons
    • Usability lab as testing environment?
      • Possibilities for simulated run (i.e. virtual testing)



Backlinks:

Faglig /
Case (COSTT)