Date

Attendees

Goals

  • Discuss "required nodes"
  • Discuss "related nodes"
  • Ensure we have a plan or good idea for handling the echoforms performance issues detailed in EDSC-1596.
  • Discuss read-only fields within an echoform to develop plan for EDSC-1690

Discussion items

  • Related nodes
    • C1236303848-NSIDC_ECS
      • If you choose GeoTiff, some parameters are not available (not relevant)
    • Relevant nodes?
    • Every time you check something, we re-draw the tree
      • Key question: Will selecting something (anything) in the parameter tree ever result in another node in the tree being required/not available?
        • If no, we would not need to re-draw the tree upon every mouse click
      • If we ignore a click event for some period of time we could limit the number of events/re-draws that are fired.
    • We default the tree to everything being selected.
      • In general, users want everything. Previous selections are saved.
  • Simplification
    • What if we turned off simplification?

Documentation Notes

From Tim Goff:

The ECHO forms specification document.  This is years out of date and only covers the echo forms core functionality and doesn't cover things like the tree widget which is both a newer feature and an extension to the spec:https://cdn.earthdata.nasa.gov/conduit/upload/1478/ECHO_Forms_Specification_0.pdf

The ECHO forms schema, which can be used to validate forms can be found at https://api.echo.nasa.gov/legacy-services/wsdl/EchoForms.xsd, and is documented at https://api.echo.nasa.gov/legacy-services/echoforms/index.html.  This schema includes new extensions such as the tree widget.  

The echo forms plugin itself is implemented at https://github.com/nasa/edsc-echoforms, and the README there includes info on compiling and using the plugin.  

The most useful thing within the echo forms repo for users of the echo forms plugin (i.e. providers and SDPS) is the forms demo page.  This page, at `demo/index.html` within the repo can be opened in a browser and will allow you to paste in a form and test it out.  It also provides a sample form which attempts to show many of the features of echo-forms.  This can be an invaluable resource when trying to implement a form and see what it looks like to the end user.  The output is not skinned exactly the way it will appear in EDSC, but is functionally the same.

Action items

  • user-c2913 follow up on the EDO issues related to form modifications and default selections. (EDO-1063 and EDO-1064).
  • David Auty answer the following: Will selecting something (anything) in the parameter tree ever result in another node in the tree being required/not available?
  • Ryan Abbott to look into an alternate to current tree viewer.
  • Amy Steiker to confirm the assumption that users want or don't want everything as a default. The answer to this could help initial loading times.
  • Amy Steiker consult with NSIDC team to discuss updating spatial subsetting fields to be read only and adding verbiage to the form communicating what users are doing when using that option.

8 Comments

  1. Frank Schaffer

    user-c2913, regarding your action item for EDO.  My assumption is that you were going to confirm coordination is not needed between EDO and EDSC for those Issues.  I thnk that is still fine, but please be aware, it's posible it may need coordination between EDO and the team that would make updates to the DAAC's DataAccess GUI.  user-01f8a would be somewhat familiar with previous DataAccess GUI updates, although I don't know what team that potential work would fall under.

  2. Amy Steiker

    user-c2913 Regarding parameters being selected vs deselected on default, we recommend a top level checkbox or radio button next to Band Subsetting. That box should be deselected on default. If users choose Band Subsetting, then the form should load with parameters deselected, since they have already chosen to subset and the additive workflow makes more sense in that case rather than subtractive. 

    1. user-c2913

      In this case, if a user does not select "band subsetting", I assume that means they want everything, yeah?

      1. Amy Steiker

        Yeah, that's what our thinking is.

  3. Amy Steiker

    Regarding the EDSC-1690 mitigation, we discussed either disallowing the bounds to be larger than the CMR filtering bounds, or making it entirely read-only. The former option would not necessarily solve the problem of spatial mismatch between filtered granules and subset request. Ultimately we feel that the granules should be re-filtered by CMR upon submission in the backend, however we understand that this will be addressed under DURT- 121. For the mitigation, the coordinates can remain read-only in the form as long as there is clear wording describing the reason for the behavior. For example: "Bounding coordinates for spatial subsetting must match the rectangle entered to filter granules on the previous map page. If you wish to modify these coordinates, please go back to the previous page and select the rectangle option under the spatial filter icon." This would help describe the filter vs. spatial workflow, even though it could be a pain point since they will have to move back a step. 

    1. user-c2913

      Ok, so just to be clear I want to make sure that we all understand that the paragraph/help text would need to be added to the actual form itself (ie, not by the EDSC dev team). I agree that it's not the best UX, but it's the best we can do to mitigate the issue quickly.

      1. Amy Steiker

        Sure, that makes sense to me. 

  4. David Auty

    Re: Will selecting something (anything) in the parameter tree ever result in another node in the tree being required/not available?

    It is difficult to be absolute in providing this answer.  Here are several considerations

    • This relates to how science variables are inter-related within the data files.  The question could be - Are there any cases where including one variable group should imply including another variable group?
      • I have heard scientists and user-services suggest that such a constraint should be imposed.
    • This is also a question of priorities and workload - Is this a significant requirement for proper behavior?
      • I remain pretty confident we have never implemented such a behavior.
      • It implies a complexity of configuration and setup within the form that I suspect would only vary rarely be exercised, if at all.
    • My opinion - In balancing performance vs. features, this is one feature that is not important enough to support at the cost of poor performance.