Overview

The Airborne Inventory project would like to do some user research and usability testing in late August or early September. We will have about 20 hours total to dedicate to the effort.

What we have

Some user surveys were done by the NASA team (called “ADMG”) prior to development of the product. That research gave some good background, but we still have some questions about the different types of users we will be serving and how to build features that meet their different sets of needs.

Existing documents:

ADMG's user survey results (might be access controlled?)
User activity ideas
An internal guess about our user groups
Success metrics document

What we want to gain

We are looking for support with planning our user research. @necoline typed up the user activity ideas document (above) with some ideas for how to proceed and we now want to prioritize and get another perspective on which activities to pursue.

In general, we think we should pursue our user groups in more depth, but we aren’t sure how much time to give to that vs. how much time to spend focused more on specific features.

It is worth noting that the NASA team would like to be actively engaged in this process. They have strong opinions about what we can or can’t show people and with who we should be talking to.

Timeline

The NASA team has been very clear that they don't want to show the project around too early. They worry about the politics of bad press from folks who don't fully grasp the difference between a prototype and a finished product and they want to be able to market the product strategically.

That being said, in about mid-August we plan to have the interface to the point where ADMG would be comfortable showing it to users.

Links:

The website - https://airborne-inventory.surge.sh/

cc: @developmentseed/team-impact @sethvincent

Creating a log of tests that return inconsistent results:

• explore:
  • displays a list of cards presenting the available instruments (times out trying to find the list)
• home:
  • navigates to the campaign list with the region type as filter applied (Times out trying to find [data-cy=filter-chip])

• long name? hover for description?

As we implement the new styles from the wireframes. I think we would benefit from setting up a global theme that can be broadly applied to components.

I recommend following the format from the devseed-ui theme, which unfortunately is in need of documentation (by me)

(the color palette, typographic scale, icon library, sizing and spacing, imagery, and grid system)

1. Redesign the search filter dropdown
2. Add search by time functionality to the current search/filter

• a campaign based on season of study ✔︎ (filter with 16 options)
• a deployment based on the timeline on the campaign page ?/✔︎ (timeline to step through)
• an instrument based on temporal resolution ? (could be a filter with options)
• a platform ... ?

This ticket provides a sprint by sprint overview of the project.

• remove global styles (perhaps with some exceptions)
• create foundational components:
  • title
  • headings
  • internal links
  • content text

1. How the focus areas and geophysical concepts are listed on the campaigns page

Stage 1 - This ticket

One icon per entity.

• generic instrument image
• generic platform image
• generic campaign logo image

Stage 2 - Future

One icon for campaign. One icon per parent group for Platforms. One icon per "type" (what that means TBD) for Instruments.
TODO get list of parent groups for Platforms.

2. How the measurement keywords (GCMD Phenomena) are listed on the instruments page

This is a list of arguments for 4 different tech stacks. The arguments can be seen as pro, contra or just informative, so far I just collected some thoughts.

Project requirements

• lots of dynamically rendered pages based on database requests 
(e.g. there are 300 individual campaign landing pages. most of the time user only sees 2 or 3)
• search functionality
• long lists with search results, to be filtered like an e-commerce shop (without cart/checkout) for airborne data
• linked information, similar to wikipedia

Developer Experience

Setup

Project Seed

• long term dev seeders are very familiar with it
• last updated 6 months ago, would require some maintenance to get up to date
• complex folder structure (unfamiliar for new team members)

Gatsby

• maintained by a large community
• zero configuration on project setup
• easy development, easy deployment
• easy out-of-the box routing
• improved SEO and performance
• static, builds html ahead of time

Create React App

• maintained by a large community
• zero configuration on project setup
• client side rendering
• easy development, easy deployment

Django web framework

• python!
• comes with default website and setup
• includes admin interface and authentication
• zero experience
• backend and frontend are a single entity, reduces need for many APIs
• simple architecture vs slow performance on page load

Data fetching, AJAX and APIs

Project Seed

• comes with redux and boilerplate reducers from other devseed projects

Gatsby

• constantly updating values are not good for Gatsby, there are two ways to handle updates:
  • rebuild and update entire site if there is a change (every 1 sec not viable, every 1 hour ok)
  • dynamically fetch data and render client side
• is optimized for GraphQL (which is encouraged)
• can be used with a plugin sourcing data directly from DB
• or without GraphQL at all https://www.gatsbyjs.org/docs/using-gatsby-without-graphql/

Create React App

• from the docs: fetch in component lifecycle and use hooks to update state

Django web framework

• the maintenance backend is written in Django - using it for the frontend, too allows us to skip API definition and render views directly from data

Testing

Project Seed

• no out-of-the-box test environment, no recommendations for configuration

Gatsby

• docs recommend jest, @testing-library/react and cypress

Create React App

• unit testing framework ready to go (jest)

Django web framework

• documentation recommends tox test runner

CI/CD

Project Seed

• comes with circle ci configuration and many examples around devseed projects

Gatsby

• no recommendations

Create React App

• some (limited) configuration support in docs

Django web framework

• “… since most web servers don’t natively speak Python, we need an interface to make that communication happen. Django currently supports two interfaces: WSGI and ASGI.” (from the docs)

Why Gatsby seems to be a good fit:

• comes with good Search Engine Optimization (SEO) -> I assume this can be valuable for ADMG to gain public visibility
• the database does not constantly update. Most of its content is inserted once and stays forever (e.g. an aircraft with its name and description). New data is being added by a group of 25 people max)
• easy out-of-the box routing
• create pages programmatically from data using templates (1 template for campaign, 1 for aircrafts… content filled in from database)
• comes with plugins for image optimization and many others
• can be combined with Django to leverage advantages of both, easy CRUD management with database and modern technologies (i.e. React)
• GraphQL can be used to implement the search

I don’t have prior experience with GraphQL, but other DevSeeders seem to be interested as well: https://github.com/developmentseed/dev-speak/issues/7

Why is GraphQL so cool?

from https://www.gatsbyjs.org/docs/graphql-concepts/

• Eliminate frontend data boilerplate — no need to worry about requesting & waiting for data. Just ask for the data you need with a GraphQL query and it’ll show up when you need it
• Push frontend complexity into queries — many data transformations can be done at build-time within your GraphQL queries
• It’s the perfect data querying language for the often complex/nested data dependencies of modern applications
• Improve performance by removing data bloat — GraphQL enables you to select only the data you need, not whatever an API returns

Decision tree

When should You Use Gatsby? by Ben Awad, https://www.youtube.com/watch?v=VoscwJ6MGsU

• CRA: no SEO, good choice when whole page is behind login
• Gatsby: great SEO, good for for blog, podcast, e-commerce, data updating only every hour
• next.js: good SEO, good for reddit, twitter, facebook… with frequently updating data

What next?

I would love to hear your thoughts, @rwegener2, @olafveerman, @bitner, @alukach and others. Would you be open to talk about using Gatsby and GraphQL for this project? Are there any major requirements that I missed? Any aspects I did not consider?

With Gatsby, it is very easy to set up routing (see documentation: Any component in the folder src/pages will be rendered as a page component with the file name being the url path. Files within a directory will be accessible that exact way via url (localhost:8000/<directory>/<filename>).

The current setup stems from the sitemap drafted by Major: https://projects.invisionapp.com/d/main#/console/19700708/412025771/preview

./src/pages
├── 404.js
├── about.js
├── contact.js
├── explore
│   ├── campaigns.js
│   ├── instruments.js
│   └── platforms.js
├── index.js
├── resources.js
├── campaign/<uuid>
├── ..
└── campaign/<uuid>

We might want to revisit the structure and naming.

ADMG is having conversations around which fields to import from CMR.

Gatsby hits the external APIs only during the build process, fetches all the data and with that, we create data structures that we can query with GraphQL. This happens in gatsby-node.js.

Currently, when there is a change in the API and a previously present field is now missing, the build process fails. I wonder if there are best practices or recommendations to make the node creation more resilient.

And while talking about node creation, I wonder if there is a better way to create our schema than the current approach. Right now, I am simply iterating over all the data returned from the endpoints and create nodes for each item, attaching all the keys that are given in the API response. In order to connect e.g. campaigns to the platforms that flew in the campaign, I am using their uuids to apply a filter in the GraphQL query (allPlatform(filter: { id: { in: $platforms } })).
It would be great if we could set up an actual Schema with connections between the Types, so that we can query using edges, connections, relations,...?
More info: https://graphql.org/learn/schema/, https://www.gatsbyjs.org/docs/schema-customization/ and https://www.gatsbyjs.org/docs/node-apis/#createSchemaCustomization

Overview

All the instruments available through the interface will be grouped into 8 categories. We would like icons to accompany these categories. The main place they are used right now is at the bottom of the home page, where you will see our current randomly chosen placeholder icons under "Explore Instruments".

Instrument Descriptions

From NASA

The following comes directly from the NASA group:

Descriptions of these may be updated slightly, but the names given for 1-8 are good:

1. NASA Facility Instruments
2. Aircraft-based Remote Sensors
3. Aircraft-based In-situ Sensors
4. Non-Airborne Point Sensors
   Could be ground- or ship/vessel- or buoy-based…
   Observations represent value at a single point in space/time
   Eg: Gauges, Disdrometers, Thermometers, Anemometers, Field mills, soil probes, tide gauges...
5. Non-Airborne Profiling/Remote Sensors
   Could be ground-, balloon- or ship/vessel-based…
   Eg: ground-based (or ship-based) microwave radiometer, doppler wind profilers, buoy-based profiling instruments, radiosondes-released-with-a-balloon (not dropsondes, which are released from aircraft and would be considered aircraft in-situ sensors -- Group 3)
6. Non-Airborne Weather/Cloud Radars
   Could be ground-, vehicle-, or ship/vessel-based...
   Scanning radars
7. Water-based Observing Sensors
   Sensors specific for vessel/ship- and submersible- based observations.
   Would include all types: remote, in-situ, physical samplers (nets/trawls), etc that aren’t represented by Groups 1-6.
   ocean colors, specific markers for ocean-based organisms (agal or plankton activity), etc
8. Land-based Observing Sensors
   Sensors specific for land/soil/ground-based observations.
   Would include all types: remote, in-situ, physical samplers (depth-based profiles, soil moisture), etc that aren’t represented by Groups 1-6.

My 2 cents

There is a lot happening up there but this is how I split it up in my head:

And the facility instruments are the last category. I can get some more clarification on this but they are instruments that are unique because they run on lots of campaigns and also randomly as not a part of a campaign. The NASA group were not aware initially that facility instruments would be a part of their scope.

Prior Work

Icons

These are some sample icons that have already been generated:

What works and what doesn't

The icons above I think are in the right direction in that they are simplistic representations of complex concepts. I still think they could be more tuned to some of the differences in the categories above to better distinguish between categories in a few ways:

1. It is really important to the NASA group to always remind people that this isn't satellite data. So icons similar to 8A or 7D or 4D that have depictions of satellites distract from that point.
2. One main distinction is aircraft vs. non-aircraft vs. land based vs. water based measurements. These differences should be captured in some way.
3. The other main distinction is what the output data looks like - a single point vs. a profile vs. radar. It would be helpful for these to get captured.

Designers should, of course, feel free to make their own distinctions and take liberties. These are the things that stand out from my perspective as between as being evident in clear icons.

Timeline

NASA has established a soft end-of-week deadline (8/14) and a hard end-of-next-week deadline (8/21) for the current milestone we are working toward. Any progress that can made before those milestones would be fantastic.

cc @ricardoduplos @AliceR @necoline

I noticed there is a bit of props drilling for some of the filter actions. Obviously, this works well for the size of the app thus far, but perhaps we could consider creating a filterAction context with selectors that we can apply in the components that require them

Running end to end test takes quite some time because we run the test on the build project, and have to build it every time the workflow is triggered. I would like to find a way to cache the build folder (./public).

see #166

Some pages like /about or /contact have quite some content that does not live in the inventory database. We currently maintain parts of this content in .json objects, some of it is directly written in HTML (JSX).

I would like to revisit the content structure, finding ways to make it easier to edit and maintain. Part of this initiative is also to load the json via Gatsby plugin into the GraphQL data layer, instead of direct import.

Eventually, I am thinking that we could use something like Tina CMS to provide a way for ADMG to edit the text themselves.

User Story Map: https://miro.com/app/board/o9J_kumT768=/?moveToWidget=3074457347674854571&cot=13

Backend Requirements, basic functionalities:

• user authentication ✔︎

• API to GET limited fields ✔︎

• API to POST new entities ✔︎

• API to PATCH existing entities ✔︎

API documentation: http://admg.nasa-impact.net/api/docs/

Backend Requirements, review and approval functionalities:

• a way to mark entities as approved/public

• a way to mark entities as draft/waiting for approval

• a way to store edited entities as draft next to the original as public

#185 does not have caching implemented. Introducing it could help us run the workflow faster, leading to quicker feedback iterations.
See https://docs.github.com/en/free-pro-team@latest/actions/guides/caching-dependencies-to-speed-up-workflows

Every now and then the tests fail when running on CI, triggering them again will let them pass. This shouldn't happen, false alarms reduce our sensitivity for failing tests.

How can we make our tests more stable?
I need to learn more on Best Practices.

These are notes from a 3/12 meeting to discuss the goals of the Discovery phase and how we will move from the discovery phase to collaborating with Major (company out of Portugal doing design work for this project)

Attendees
@olafveerman, @AliceR, @rwegener2

Discovery Phase Goals

• We should use this phase to synthesize user and product problems into a discovery document (Example here)
• The emphasis is on generating a product vision centered on user and product challenges (taken from MSFC documents, see Issue #1 ) that can be given to Major to guide design work

Integration with Major

• What Major will do: wireframes & user flows, and maybe 1-2 mockups of key pages if we ask for it
• We will be communicating initially through our shared github repo

We need to figure out how and configure Gatsby to its full potential in terms of SEO, manifest, helmet, meta tags, ... also going in line with existing projects (see e.g. Project Seed)

Information to Add

• repositories

Details

Notes for each of the new pieces of information.

repositories

• Description: The link to and name of the DAAC where the data is stored
• Placement: I think these are actually placed in the desired location - along the right side bar.

Part of the repository information is actually already being used. The only thing to change is that currently we are displaying the long_name only. We would like to create a link over the text of the long_name which is the url included in the notes_public section of each repository. There are campaign IDs here as well but I don't think we need to add those in unless ADMG requests it.

This issue is related to #146

Background

Building on a conversation with @rwegener2, I've put together an initial list of design needs.

Current Work

• Instrument group icons (that is if we want to reopen this topic, I don't know if we want to resurface this)
  • #77
• Updated Design System
  • #95
  • Review on typography, layout, display of images on instrument and platform pages

Future Work

• Geospatial Search Design
• Discovery (not necessary, but could be useful to have design input during this stage)
• Mock-ups
• Redesign the search filter dropdown
• DOI components
• Campaign Significant Events

Overview

ADMG has put a lot of work into curating metadata fields for a variety of science keywords. The result is that there are several sets of science keywords at different levels of specificity and different types of keywords are linked to different entities in the platform. We would like to make sure this metadata is leveraged to maximum benefit so this ticket exists to assess where those keywords are used and develop ideas for their effective use.

Background

There are 4 types of science concepts that ADMG uses in their inventory, which is also summarized here:

1. NASA Earth Science Focus Areas
2. Geophysical Concepts
3. GCMD Phenomena (also called Science Keywords or Measurement Keywords)
4. Focus Phenomena

The first three are concepts are enumerated fields (there is a set number of them) and they are linked together. The Focus Phenomena are defined by ADMG without much constraint and will vary quite widely across campaigns. This ticket is primarily focused on the first three.

The first three concepts are linked together as explained in this document from ADMG. To read it you will need to request access.

Goals

Science concepts are present in the interface in several places:

1. home page (focus areas and geophysical concept boxes which link to the search page)
2. campaign page "Focus" section
3. instruments page "Instrument Details" section

We would also like to consider adding a page or a component to a page which would allow a user to visually explore and understand the different science concepts.

The goal of this ticket is to document and organize ideas which would improve the user's experience with science concepts in the interface. Initially we would like to focus on the following tasks:

• how the focus areas and geophysical concepts are listed on the campaigns page
• how the measurement keywords are listed on the instruments page
• creating a page or a section of a page where the user can explore the relationships between the different concepts

Each of these is described in more detail below.

Tasks

1) how the focus areas and geophysical concepts are listed on the campaigns page

On the campaigns page the focus areas and geophysical concepts are listed as just a comma seperated list of strings:

How can we better display this information to help the user more easily skim what type of data is collected? One component may be to show the relationship between the focus areas and the geophysical concepts because it would help the user zoom more quickly to the large concept (the focus area) and then look more specifically at the related geophysical concepts.

2) how the measurement keywords (GCMD Phenomena) are listed on the instruments page

Measurement keywords are listed on the instruments page as a comma separated list. There are two goals to improve in this section:

1. display the hierarchy of the keywords

As can be explored in this doc keywords are organized in an hierarchy by category > topic > term > variable level 1 > variable level 2 > variable level 3. Most keywords don't get specified all the way to variable level 3. That document also shows the mapping from geophysical concept to measurement keywords.

I'm not totally sure what we are currently displaying in the interface but I think we'd like to change the display to allow users to more easily skim the keywords.

2. [maybe] relate the keywords to their associated geophysical concepts (mapping in this doc , also linked in point 1)

It may or may not also be helpful to add some small component or have as a part of visual showing how the measurement keywords are related to geophysical concepts. Or maybe it isn't. 🤷‍♀️

3) creating a page or a section of a page where the user can explore the relationships between the different concepts

The final way we may want to help the user understand the science concepts is to design a page that allows them to understand the relationship between the entities. The goals of this page (or pages or part of a page) would be:

1. Define the difference between focus areas, geophysical concepts, and GCMD phenomena
2. View the relationships between each of the science concepts
3. (maybe) browse entities by concepts or groups of concepts

If we looked into number 3 we may consider how that would tie into the search view or not. This relates to the larger goal of defining how this type of visual or interactive content would fit in the user flow.

What we have so far

Prior Brainstorming
Some brainstorming of visuals that we have already done include:
Hierarchy Visuals

Network Visuals

While these were good for brainstorming it is important to remember that the entity relationships are many to many.

Hello @necoline @rwegener2 @AliceR 👋

I was looking at this project's homepage and did a small list of suggestions for UI improvements (paddings and font body & sizes). You can find it in the attached images, hope it helps :)
If you need some more help or have any questions just let me know!

Keep up the good work!

Ps-> Do you have access to the invision original files?

[can we] place the glossary terms in ABC order instead of how they're currently displayed and possibly either use a different font or add more space between terms since this page is so text-rich?

While exploring the cypress testing issues (#33, #85) I started playing around with our CI configuration in PR #105
Some topics to further discuss and improve are:

• Caching: How to effectively cache dependencies or the build, to speed up subsequent CI runs?

• Tooling: Should we explore Github Actions over Circle CI? https://developmentseed.slack.com/archives/C025QMQE9/p1598392194088100?thread_ts=1598392165.087600&cid=C025QMQE9

• ... ?

Information to Add

• online_information

Details

Notes for each of the new pieces of information.

online_information

• Description: The single link to more information about the platform.
• Placement: To the right of the "Overview" similar to how there are links on the campaign pages

This issue is related to #146

Overview

One of the most unique things about the metadata we are working with in the Airborne Catalog is the number of interlinked metadata fields. These metadata can be very powerful and make the interface unique so we want to make sure we are leveraging them.

Relationships we aren't using

Below I make a list from Alice's investigation of the API information that we aren't using. I sort them into "want to use", "don't want to use", "to be determined".

Campaign Page

Want to Use

• notes_public
• significant_events
• nasa_missions
• repositories
• other_resources

Don't Want to Use

iops, notes_internal, gcmd_projects, nasa_led, data_volume, description_short, platform_types

Platform Page

Want to Use

• instruments
• online_information

Don't Want to Use

notes_internal, notes_public, platform_type, gcmd_platforms

Instrument Page

Want to Use

• repositories - this could be available under a header like "data is available at these DAACs"

Don't Want to Use

notes_internal, uuid, gcmd_instruments, arbitrary_characteristics, notes_public

Endpoints

Want to Use

• /significant_event
• /alias - This isn't a commonly returned field but if an entity has one we want to use it. It typically refers to an alternate name that is used for that entity.

Don't Want to Use

/change_request

To Be Determined

/gcmd_instrument, /gcmd_platform, /gcmd_project, /home_base, /iop, /nasa_mission, /platform_type

Tasks

For each of the Want to Use sections on each of the pages above there is the task of figuring out how that information would be best incorporated into the page. Some of these, like "significant event" under campaigns will definitely take some design work. Others, like "notes_public" under campaigns seem like they are probably pretty straight forward.

In order to make requests to the ADMG API, the client needs an authentication token that is sent along in the request header.

Currently, we only fetch the data once during the build process (not during client runtime). That means that we provide a token locally during build when we gather all the required data, and afterwards a user can browse the app without the need to log in.

In order to get a valid token, we manually request it from http://admg.nasa-impact.net/authenticate/token/ providing username, password, client id and client secret. These instructions are provided by ADMG:

How to get the token

• go to /authenticate/applications/register
• create a user and verify the email address by clicking on the link that shows up in the terminal where > you've done python manage.py runserver
• register the app
• Use Client Type: confidential, Authorization Grant Type: Resource owner password-based
• get the client_id and client_secret
• curl -X POST -d "grant_type=password&username=<user_name>&password=<password>" > -u"<client_id>:<client_secret>" http://domain/authenticate/token/
• You will get something like

  • {
      "access_token": "access_token", 
      "expires_in": 36000, 
      "token_type": "Bearer", 
      "scope": "read write", 
      "refresh_token": "refresh_token"
    }

• Use this access_token to hit on APIs
  • curl -H "Authorization: Bearer <your_access_token>" http://localhost:8000/your_end_point_here
• To refresh your token
  • curl -X POST -d "grant_type=refresh_token&refresh_token=<your_refresh_token>&> client_id=<your_client_id>&client_secret=<your_client_secret>" http://localhost:8000/authenticate/token

Adding login functionality

In order to implement a login feature in the web application using the ADMG authentication service, we need to build a simple login form to allow a user to enter their username and password, and a login button that on click sends the given credentials to the api:

  await fetch(
    "http://admg.nasa-impact.net/authenticate/token/",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/x-www-form-urlencoded"
      },
      body: {
        ...URLSearchParams
      },
      redirect: "follow",
    }
  )

The returned token can be stored in sessionStorage (sessionStorage.setItem('token', token)) and accessed during runtime (sessionStorage.getItem('token')).

Assumptions

• User registration and management is handled by ADMG/IMPACT
• Any security considerations are covered by ADMG/IMPACT

Remaining issues:

• The api returns a cors error when accessed via browser. fixed

Access to fetch at 'http://admg.nasa-impact.net/authenticate/token/' from origin 'http://localhost:8000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

• The api is served via http, the web page loaded over https - the request is blocked:

Mixed Content: The page at 'https://airborne-inventory.surge.sh/' was loaded over HTTPS, but requested an insecure resource 'http://admg.nasa-impact.net/authenticate/token/'. This request has been blocked; the content must be served over HTTPS.

https://github.com/developmentseed/airborne-metadata-catalog-internal/blob/develop/src/pages/explore/campaigns.js#L45

We need a scalable approach, considering that we will add ~10 filter categories, and eventuallt apply filtering to platforms and instruments as well.

Build out campaign template - funding

It looks like we don't have type checking implemented yet. Should we start using PropTypes or something of the like?

Let me know if this is something we are already doing and I've missed in this

The Update

We got a big update from ADMG this morning: Rahul is showing our interface to the head of NASA Earth Sciences. The NASA backend team got the DOIs into the database this week and they should be available in the prod database starting tomorrow. As a result, we are now a part of a push to get the DOIs into the frontend by next Tuesday (we don't know the time of the meeting right now).

Priority

In preparation for the meeting here is a prioritized list of what ADMG would love to see happen.
The DOI goal means that on the campaign pages we want:

• data products (top panel) to show a number
• collection periods (top panel) to show a number
• create a new table to show the data products

After DOIs the next priority would be:

• getting the bounding boxes at the top of the campaign page to show up correctly

Other fixes that would be nice but aren't the priority are:

• decrease the amount of spacing on the campaign page
• adding a logo at the top of the campaign page
• changes from the content doc on the headers

The Plan

Friday
Neco is going to focus on getting the bounding boxes looking good by switching to Mapbox. This may not be finished today but we can pick it back up if there is time after DOIs.

Monday
As of Monday (when the DOIs should be in the database) the new priority is the DOIs. The 4 tasks I see are the three from above, plus adjusting to the database.

• Making any adjustments necessary to the db changes
• data products (top panel) to show a number
• collection periods (top panel) to show a number
• create a new table to show the data products

@AliceR when you get on in the morning would you be able to start with the task of inspecting the database changes and making sure things are as expected? This thread in slack has a copy of what Carson expected to be the result of the updates.

After that @necoline and @AliceR I will let you two sync up and game plan. Certainly pull me in if you need help with anything.

That's all I've got

And that's it, team. It's a surprising last minute deadline but I'm looking forward to what we can accomplish in this concerted push. Having our interface demo'ed to the head of Earth Sciences is pretty big and speaks well of what the IMPACT team things of our work. Let's do what we can to make the demo fantastic. 💪 👩‍💻 💥

Per our discussion earlier, it would be good to add an .nvmrc file specifying the node version in use.

I think in past projects, we have used 10.x

Now might be a good chance to update this to node 14

https://nodejs.org/en/about/releases/

Background

The goal of this ticket is to understand the different types of instrument groups and specifications that ADMG is tracking and use that in our interface.

Between campaigns, platforms, and instruments there are the most individual instruments that users need to sort through. Their specifications are also the most technical, meaning they are the way for scientists to search for specs that will most closely relate to their data products.

Knowledge to date

There are two types of instrument groups:

1. Measurement Types (~26)
   The groups: Altimeter, Conductivity Sensor, Corer, Gauge, Imaging Radar, Magnetic/Electric, Meter/Analyzer, Multi, Photon/Optical Detector, Particle Detector, Position/Navigation, Pressure/Height, Probe, Profiler/Sounder, Radio Wave Detector, Recorder/Logger, Sampler, Scatterometer, Spectrometer/Radiometer, Temp/Humidity, Thermal/Radiation Detector, Ultraviolet, Visible/Infrared, Wind/Current, X-ray/Gamma, Other
2. Instrument Type endpoint
   The groups: list and explanation in this ticket

Before she went on leave Stephanie was working on mapping these two groups together. There isn't a clear vision for these right now.

Where they are being used right now

Right now we are filtering instruments based on measurement types because instruments don't have associated instrument types.

reduced white space, "less of a gap" between the sections

Dark websites should always use white space

Dark color schemes can make websites appear “heavy” or “oppressive”. Careful use of white space can make each element on the page easier to understand.

White space is the most common element in web design, especially against dark backgrounds and its use is essential to help highlight the main content. The more white space you have, the more space you can spare for fonts and the main content, all of which can guide the user smoothly through the site. If there are too many elements, the user’s attention will be dispersed. White space allows users to find the information they need as quickly as possible. Overall, it can improve the user experience.

https://www.nngroup.com/articles/dark-mode/

On the campaign page, the small cards for instruments in the "Platforms and Instruments" section don't give enough information for the user. These should be redesigned so they can still be quickly skimmed but so that a user doesn't have to click to an instrument page just to get a basic sense of what it does. Perhaps we add a long name or hover text?

Information to Add

• notes_public
• significant_events
• nasa_missions
• repositories
• other_resources

Details

Notes for each of the new pieces of information.

notes_public

• Description: notes that are not a campaign description but still are important for people to know
• Placement: underneath Overview section as "Additional Notes"

Examples:

• Details are extensively available for 2017 only. That's why metadata input are for 2017 year only.\nDeployment count is 2 because there is a deployment currently happening. As a result, inventory data mostly reflects 2017.
• ACE mission: Aerosol-Cloud-Ecosystems Mission, which looks like evolved into PACE (Plankton, Aerosol, Cloud, ocean and Ecosystem) Mission; overview publication is currently in "discussion"/public review phase at ESSD journal (https://doi.org/10.2514/6.2002-3405)

significant_events

• Description: A significant event is an event of scientific interest, such as a fire or a hurricane, that occurred while the campaign was taking place
• Placement: I think significant events could go well in the timeline along with deployments. They should be distinguished in some way from deployments, however.

We don't necessarily have to include all the information about the significant event in the timeline card right now. reference_file and published_list I already excluded because they either don't make sense or return null.

Examples:

      "region_description": "Atlantic",
      "reports": "Flight Reports: http://dx.doi.org/10.5067/HS3/REPORTS/DATA101",
      "description": "Hurricane Nadine - SAL interaction",
      "end_date": "2012-09-15",
      "short_name": "hs3_se_1",
      "start_date": "2012-09-11"

      "end_date": "2015-12-18",
      "region_description": "Olympic Peninsula",
      "reports": "Science Summary: https://ghrc.nsstc.nasa.gov/pub/fieldCampaigns/gpmValidation/olympex/reports/data/mission_scientist/olympex_20151212Science_summary.pdf",
      "description": "Anomalous trough conditions",
      "short_name": "olympex_se_4",
      "start_date": "2015-12-11"

nasa_missions

• Description: A satellite mission that the airborne mission supports. This isn't super common.
• Placement: Perhaps at the bottom of overview? Or maybe below Platforms & Instruments?

Examples:

• MODIS
• PACE

repositories

• Description: The link to and name of the DAAC where the data is stored
• Placement: Currently on the right side bar. We would like to change it so that "Repository Website" is a header and the link is named by the long name of the DAAC

Examples of long names (each one also has a link):

• Goddard Earth Sciences Data and Information Services Center (GES DISC)
• Land Processes DAAC (LP DAAC)

other_resources

• Description: a list of links to additional information for that campaign
• Placement: bottom of the page

Example (each campaign seems to have 2-6 links):
https://lvis.gsfc.nasa.gov/Data/Maps/Gabon2016Map.html https://www.nasa.gov/centers/armstrong/multimedia/imagegallery/C-20A/AFRC2016-0054-539.html https://www.nasa.gov/sites/default/files/atoms/files/xpress_afrisar.pdf https://earth.esa.int/documents/10174/134665/AfriSAR-Final-Report https://airbornescience.nasa.gov/sites/default/files/documents/ASP_Spring2016_nsltr_rev.pdf

This issue is related to #146

Overview

There are three types of related results that could be returned from our search - a campaign, a platform, or an instrument. When applying filters to those entities some filters apply to all three entities and some filters only apply to one. We want to design our filtering so that these differences are apparent to the user and the experience of filtering across entities is smooth. As a part of this process we would like to consider the pros and cons of displaying the three types of entities together on the same page.

Goals

• Allow the user to distinguish between universal filters (applicable to campaigns, platforms, and instruments) and specific filters (applicable to only one of those entities)
• Consider the search experience might change if the user wanted to be able to see all three types of entities on the same page
• Create a dynamically updating filtering process, where filters update based on other filters (Added based on @necoline's comment)

Current Work

One loose outline of a design that we brainstormed looks like this:

The key components are:

• Cards that have been designed to show which entity it represents
• Entity options at the top that filter results by campaign, platform, or instrument
• A filter bar that changes based on search results

3. Creating a page or a section of a page where the user can explore the relationships between the different concepts

https://invis.io/KQZFASNYPRZ#/437703316_Search_Flow-01