UAT #2 Feedback for MANGO release 25.2.1 [8/4/25 through Friday 8/15/25]

[marjo-luc]

From Willy:

Some initial comments:

On

../mango/view/downlink/performance_reports

alternate row colors could use a bit more contrast

Units are still wrong for L-Overlap, heading is correct, numbers off by 1000, numbers are on the order of 1

KBR units look off by a factor of 10, they are on the order of 1 as well

No obvious way to download the entire table as say ascii white-space delimited.

Clicking sort on K-band RMS erases the units.

No obvious way to save plots as say png

The row that has ! for outlier could have more contrast on the outlier cell

I would choose maybe bold and slightly larger fonts on the plots; there is plenty of white space.

The units on the KBR plot show cm instead of the column heading mm. The column heading would be better than “resid_rms”, “KBR-GPS”

[stanboli]

Hi MANGO team.

Willy Bertiger provided some feedback to you already. I have copied it down below. Items in red (bold) are considered critical to support GRACE-FO operations from his point of view. This adds a bit of detail/context to what he previously supplied. Thanks, David

https://j2.jpl.nasa.gov/mango/view/downlink/performance_reports

• alternate row colors could use a bit more contrast ( Improve contrast in performance table #159 )

• Units are still wrong for L-Overlap, heading is correct, numbers off by 1000, numbers are on the order of 1 ( Fix units for L-Overlap #154 )

• KBR units look off by a factor of 10, they are on the order of 1 as well ( Fix KBR units #155 )

• No obvious way to download the entire table as say ascii white-space delimited. ( Export entity to CSV #70 )

Clicking sort on K-band RMS erases the units.

No obvious way to save plots as say png

• The row that has ! for outlier could have more contrast on the outlier cell ( Improve contrast in performance table #159 )

I would choose maybe bold and slightly larger fonts on the plots; there is plenty of white space.

• The units on the KBR plot show cm instead of the column heading mm. The column heading would be better than “resid_rms”, “KBR-GPS” ( Fix KBR units #155)

[marjo-luc]

From Meegyeong:

1. TIM1B is missing from this page; despite its 1B label, it is a 1A product. LHM1A, an intermediated product, is also missing; while not essential, it helps operators detect problems quickly. Also, the data should be displayed in two separated groups as shown in the current GRACE-FO Pass Report Table, in which Science stream and HouseKeeping stream. You don’t need to separate them as two columns. However, the OFFRED packet data - MAG1A, and HRT1A, TIM1B, TNK1A (in this order) - should appear later than the other science packet data, perhaps separated by a line.
2. As mentioned for the performance table, the auto-expanding page width is inconvenient. Could you set a fixed width instead?
3. The version is missing and should appear at the top of the page, as is essential for each analysis.

• 4. When opening of the Downlink Dashboard page, can you set the default time period to “today” and add a “yesterday” option? Alternatively, set the default to “from yesterday to today” to show both days together, as operators most often search for these two days. ( Support dynamic time ranges in the view #6 )

5. It would also be helpful to display two versions simultaneously, as operators always check both version V00 and V04. Could you add the option to create a new section showing another version for exactly the same period already selected? The version choice should be flexible, allowing any two versions to be compared on one page, with the default display set to V00 and V04.
6. The time range appears to change randomly when the cursor is moved. This should be corrected, as it is currently unstable.
7. Hovering over the red line, which indicates an unusual time gap, displays the timestamp of the gap in a popup window. Since the length of the time gap is more important than the timestamp, please display it like: “5 second time gap at 2015-06-01 22:33:44”. As mentioned, the version should be displayed at the top of the page, not within each time tag warning.
8. Regarding the time gap indicator: it matters only when the gap exceeds the default length for each data type, which differs according to version as defined in /fosds/info/rl0v/executor_def.py. The warning should appear only in such cases. Also, this default should be adjustable according to any changes in the file.

Additionally, I wanted to let you know that the missing webpages should be populated as follows:

• IPU reboot table
• KBR1A: Iono_SNR_DDMI ( Generate KBR1A & DDMI Plots #149, Set view up for parallel ops #158 )
• Missed Interrupt Tables

[marjo-luc]

From Meegyeong:

I reviewed the performance report table and have suggestions for changes:

• I like the timestamp-based sorting. Having both ascending and descending tables will be very useful. Thank you!
• I noticed that the contrast is not applied to every other line. It should be line-by-line for better distention. I love yellow, but it doesn’t seem to be the best choice in this case. Could you please select another tone, such as light purple or light blue?
• The plot in each column, whether showing KBR1B, POE1A, or GNV1B products, is unnecessary and not useful.
  In this case, we use two daily plots in our operation, generated by scripts, unless others suggest additional ones, as follows:
  For KBR-GPS Performance, each directory contains a special file for this purpose: /fosds/work/L1B/rl0x/yyyy/yyyy-mm-dd/KBR1B/range_resids.txt, which has two columns. Please link its plot with zoom controls.
  For GPS DD Clock Overlap, the script /home/wbert/bin/graceDDclkDiff.py is used. I have attached the howto_clk_dd_all script for reference.
  Daily plots suffice for these two plots. We are not use multi-day plot.
  Below are example plots for these two cases:

• Comparing different versions is necessary. I believe daily comparisons are ideal and comparing just two versions-such as V00 vs. V04 or V04 vs. V05-should be sufficient.
  If daily comparison is not convenient, block comparison could be an alternative. For example, generating performance tables for the same period (e.g., one week) for two different versions would allow us to see the differences between them
• Except for the “obs” and “arc” columns, which are integers, the other columns don’t require many digits. Limiting to one decimal place is adequate.
• Setting the table width to fit the full window is inconvenient. It would be better to have a fixed table width.
• I prefer the font used in the current GRACE-FO performance table, as the Mango performance table’s font appears too small and thin. Because the performance table is intended for large-scale viewing, it is important that the text is easily visible-even if it might seem overly detailed.

[AaronPlave]

From David:

• Might be expected behavior, but in the Products page I have noticed not all data is present when I try to load and plot from here. (example: KBR1A)
• Scrolling date ranges allows you to go very far into the past and future.  It would be nice to put limits there so scrolling doesn’t put you so far away from where there is data available.
• Performance Report Table: Suggested to have the date range in the top right be the same as what is in the downlink dashboard, where only the day is shown.
• Performance Report Table:  Suggest to add a “clear filter” button to remove any filters applied to the data, so a user can quickly get back to the original set.  Also, once a filter is applied, it would be nice to have a text box appear at the top that shows what filter(s) have been applied. ( Add "clear filter" button to performance report table #157 )
• Some datasets appear not to be available when I am trying to add a custom plot.  For instance, KBR1B and LRI1B
• I cannot seem to create my own plot of a dataset.  It seems to just not find data.  I tried ACC1A, ACT1B, GNV1B, etc.
• In the configuration examples page: I am having a hard time.  I think it is because of data not being present in the database.  The syncing between plots is not intuitive.  Right now it appears that plots are synced horizontally.  So if they are in the same horizontal line then they sync, otherwise they don’t.  It would be nice if a user could specify which plots should be synced. Use case is for looking at plots in different time ranges. ( Ability to turn on and off time sync for entities #88 )
• Plotting groundtrack on the globe appears not to work.
• Add a message to charts that indicates when no data is available (either because the time range is outside of the product's time range or no points are returned) ( Add message to chart when no data are available #156 )
• General comment:  I find the date scrolling hard to manage.  This might get better once data are loaded.  But if a product is not available for a timerange that a user specifies, you just get a blank screen and you don’t know if there is no data or the tool is broken.  I wonder if there is a way to alert the user they are looking at a date range where there is no data.  Or perhaps put limits on date availability based on data availability.  Selecting between a begin and end date on the calendar is also a bit challenging because it is one calendar that pops up for both begin and end.  Would it be possible to have 2 calendars pop up, so a user can easily see the one on the left is for the begin time and the one on the right is for the end time?  I think this would allow a better user interface.
• Product tab: I would move the Resolutions column after the “versions” column, or even after the “Fields” column.  Right now it takes up a lot of space in the middle of the page and users really don’t care about that column.