900612 ESP -- SURF Center : 2007_09_05
This page last changed on Dec 02, 2014 by kgomes.

Minutes from ESP GUI Demo and Question and Answer Session

The purpose of this meeting is to show the progress to date on the ESP Data Management/Planning GUI and to use this demonstration to foster information gathering that can be used to both direct development and answer development questions.

This is the list of all possible consumable resources:

  1. Instruments:
    1. Darlene
    2. GIGI
    3. NEO
  2. Lists of phases, protocols
    1. HAB
      1. SH1
      2. lyfil
      3. SH2
      4. WCR
    2. DA
      1. DA1
      2. Dalyfil
      3. DA2
    3. BAC
      1. SH1
      2. lyfil
      3. SH2
      4. WCR
    4. invert
      1. SH1
      2. lyfil
      3. SH2
      4. WCR
    5. BACAR
      1. WCR
    6. QC
      1. WCR
  3. Details for phases:
    1. Max duration
  4. Details for protocols:
    1. Duration
    2. Delay to sample
  5. Consumable Types:
    1. Fix
    2. AgMeOH
    3. ab1
    4. ab2
    5. Lysis
    6. Dilutent
    7. Sig1
    8. Sig2
    9. Sig3
    10. Con 1:5000
    11. Sub 1
    12. Sub 2
    13. Wash
    14. CSR Flush
    15. CSV Flush
    16. PSR Flush
    17. Kill
    18. Waste
    19. Power
  6. Bags/Containers/Storage:
    1. How big are the capacities for the above consumables?
  7. Protocol Makeup
    1. For each of the phase/protocol combination, what consumables to they use and how much (i.e. recipes)
Agenda
  1. Introduction/Recap
  2. Demonstrate GUI to date
    1. How to start it. Click here: http://predator.shore.mbari.org/esp_gui/launch.jnlp
    2. Should work on Java 1.5+
    3. Right now you will need to be connected to MBARI intranet (that will change to local laptop installation)
    4. Upper left is list of instruments and their associated deployment. Default start is to have all displayed.
      1. Display selection tree functionality
    5. Year selection drives the overview calendar displayed below.
    6. The overview calendar always shows all deployments
    7. Click on overview calendar to select month of interest.
      1. This drives main calendar.
Questions to Answer

For GUI:

  1. Default is to have no deployments displayed. Is that OK, or should have they all show up to begin with?
  2. Should I show all deployments on the overview calendar?
  3. Should consumables be decreasing meters and turn red on low?
  4. How much detail (zoom) do you want to see?
  5. Where do you want to edit phases/deployment (table/popup/etc.)?
    For Mission Scripts:
  6. What is 'startTube' and how is it determined?
  7. What are the 'rules' around script construction?
New Requests From Meeting
  1. Link the colors of the instruments to the deployments
  2. Have the deployments disappear on the overall calendar as well as the main calendar
  3. Clean up the view on the overview calendar so they don't look so busy (remove protocols and phases)
  4. Darlene is no longer with us, just GG (or GiGi) and Neo. But there should be three new instruments coming on line.
  5. In the details pane, there was a desire to put the sample volume right next to the protocol name.
  6. When you select a protocol line in the details pane, a tab should be available to show the contextual data (CTD, ISUS) for the time span of when the sample volume was drawn
  7. There was a desire to have the CTD data displayed like the tide data is displayed and some way to turn on/off view of it
  8. Look into the possibility of using jruby to generate the mission script so the generation could be done outside of the planning application and changed there instead of inside the planning app.
    1. As a side note, you need to know the start tube in order to generate the mission script and the start tube will not be known till after the instrument is loaded. Question, can't we tell the user how to best load the instrument based on the deployment configuration?
  9. There was a bit of discussion on the consumables view and how to use it in the planning phase. I think the following was the resulting desire:
    1. When creating a new plan (deployment), the consumables should simply show how much of each consumable is being predicted (ml, watts, waste generation)
    2. Then at some point, the instrument will be 'loaded' and the view should be changed/enable that shows the amount of consumables are available (maybe also show how much is predicted to be consumed). A full load will show all progress bars as 100% (display will show appropriate units like ml or watts) and then the bars will decrease as the log file is read and the actual amounts consumed are known.
    3. There was also a desire to know how many of the different phases could be configured with the current state of the instrument. This speaks to the 'interrupted deployment scenario' where the instrument would be recovered and could be reconfigured (but no consumables added). For example, if the instrument was recovered and it was half way through its consumption, the user could ask the application how many of the different phases could be run. This would entail changing the pucks around, but the consumables would be left alone. There was some talk about that just simply constituting a new 'deployment' since a new mission script would be created anyway.
Comments

Brian Schlining We have the database modeled to support ESP from planning through analysis. My take though is that we should create discrete applications for the different phases of the ESP deployment lifecycle (Plan, manage, analyze). There are a lot of like to have features so we should manage the user expectations and tell them what is possible to do in the short amount of time that we have.. We're currently focusing on the planning/script generation phase, which I think is appropriate. Everything else should be deferred until we get a solid planning app put together....just my 2 cents.
Document generated by Confluence on Feb 03, 2026 14:16