Skip to content

Home

Jump to bottom
Ian Mayo edited this page Apr 28, 2018 · 8 revisions

Documentation supporting Debrief-JS

History

The initial version of Debrief was created in 1995, for the analysis of simulated underwater engagements. From it's initial c++ implementation, it moved to Java in 2000. After updating the AWT UI to Swing, it moved to being based on Eclipse in 2005.

In 2018, consideration is being invested in what a future version of Debrief could look like, inside and out.

Shortcomings of existing implementation

  • Favours power users, at the expense of new-users. There isn't a precedent for an application like Debrief. So, there are no standard UI strategies to replicate - meaning users don't arrive with existing experience in using such an application.
  • Only delivered as desktop application. Modern computing has moved away from the desktop, with many applications accessed via web-browser or mobile.
  • Technical debt. As track/data rendering and TMA interaction have matured, the relevant code has grown much larger than the original architecture expected. The more complex areas of Debrief functionality should be refactored into independent modules (including the separation of content and presentation).
  • Challenging to render background reference data. Debrief plots some reference datasets (such as bathy). But, supporting new formats is challenging, since the GeoTools rendering must be wrapped to render in Debrief. Replacement of the Debrief rendering canvas with a capable existing component (LeafletJS/OpenLayers) should open up lots of new capabilities with minimal code.
  • Constrained to maritime domain. From the start the focus has been on the maritime domain, resulting in difficulty to conduct land-based analysis.

High level requirements

  • HTML/JS for multi-platform target
  • Low barrier to entry for new users
  • Deeply modular, to enable lightweight through to heavyweight composite applications
  • Maybe Remain agnostic to land or ocean. Maybe Include space coverage.
  • Pluggable ecosystem (see below)

UX/UI Thoughts

  • Plot-centric
  • 2D or 3D presentation
  • Maybe allow logical presentation of data - in a tree or flowchart, rather than on a map. Entities could "glow" as they're updated. This could be useful for simulation visualisation.

Data thoughts

  • Make data model extensible, so domains can independently add their own data
  • Follow existing protocols where possible (GeoJSON, WKT, etc)
  • Adopt JS units-of-measurement library, so all data travels with units

Architecture thoughts

  • Consider use of microservices, to allow some functionality to be managed independently
  • use of NodeJS may allow JS code to be run in browser, desktop or server

Pluggable ecosystem thoughts

Pluggable components could include:

  • Plot renderers
  • Background layers
  • Viewer panels
  • Extended data types
  • Custom editors for specific data-types
  • Alternate versions of main components (plot/editor, outline, time-control)
Clone this wiki locally