Features to improve user experience

[j-atkins]

After various discussions with @ammedd and @VeckoTheGecko recently, I think there are a few features which could be useful for improving the user experience (in addition to the animate idea in progress in #173!). Especially for if and when virtualship is used by people with less scientific/coding experience.

A few which come to mind:

1. I know there's been previous discussion about the init/expedition schedule creation procedure and minimising how much students have to manually input to .xslx files to minimise potential for user error arising from that. However, I've also heard that students don't find manually entering details to the .yaml file intuitive. Is it worth revisiting this? Could we make some kind of simple tool where the .xslx export from MFP is read in, a simple form is launched where per sampling site there are tick boxes for the different instruments, dates and times entered in a little calendar, and then the completed form is automatically written to another .xslx/csv to be used by virtualship init? Rather than manually typing these details in the .yaml?

2. Some kind of visual cue that the measurements are running in virtualship run. Progress bars are a bit tricky because some measurements are quick (e.g. CTDs) and I imagine a progress bar would just do big % jumps if there were only a few deployments. I understand that's the reason for only having the Parcels verbose_progress = True for the adcp and drifter instruments, which take longer (i.e. Providing verbose progress for drifters and argo floats #133), and not all instruments. I think even just printing a dynamic/rotating loading symbol at the end of the "Simulating {instrument}" log line could be good. Maybe it's just me but I think it's a nice touch to assure that things are underway!

3. A new spin off repo which houses some virtualship post-expedition post-processing tools, e.g. makes a nice dashboard of simple plots for the different instruments and sites. Could be used as a quick visualisation tool for the expedition's data or a starting point for further analysis.

Let me know what you think or if you think there are other user experience features which could be added in the near-medium term future!

[erikvansebille]

Thanks for opening this discussion, @j-atkins. These are all three very good and relevant points!

Some first reflections:

• Point 2 (the verbose output) appears to be the simplest to implement, I guess? So you can go ahead with that if you want
• Point 3 (the post-processing) could also help with integration testing. It would/could provide a way to validate that the output of the virtualship is what we expect? Perhaps, therefore, put it in the same repository as the virtual ship itself? @VeckoTheGecko, what do you think?
• Point 1 (the yaml file) is a bit trickier. It's true that students have difficulty editing the yaml files, so if we can provide any support to make the transition from NMF to virtualship simpler, we should do it. How feasible is it to change the NMF site, I wonder? Could we ask the NMF developers to help us by also providing instruments and dates, along with the coordinates? Or is that far too complex to ask?

[j-atkins]

Thanks for the reflections @erikvansebille!

Re: point 1 (the yaml file), I've had a very quick go at mocking up a simple GUI schedule builder (with a lot of AI help). I've attached some screenshots below.

The way I have this GUI currently working and/or how I envisage the process is:

1. The student plans their expedition on MFP and exports the .xslx file with the lat/lon coordinates of their sampling stations, as they already do.
2. Launch the GUI where the first page has a dropdown of all .xslx files in the directory and the student can select their MFP export (see screenshot 1).
3. The next page has a box per sampling station with the option to tick which instruments they want to use at each and the date/time from drop down menus (see screenshot 2).
4. Upon clicking "submit" the choices are written to a new .xslx file, which effectively just adds new "Instrument" and "Time" columns for each sampling station.
5. The new .xslx file is used with virtualship init --from-mfp instead of the export directly from MFP (some small changes to mfp_to_yaml() will be required in src/virtualship/utils.py)

It's not too hard to make changes to this kind of thing and the tool could probably be made quite flexible with enough checks to make sure the choices are all valid etc.

[erikvansebille]

Wow, this is a nice mock-up already, @j-atkins! Well done!

Yes, I can imagine that such a tool might be very useful for the students. Especially when you add a button "Use same date as previous", which will ease the process of deploying multiple instruments at the same station?

One open question then is if we can copy the schedule validation to this tool, so that students get direct feedback when their schedule is non-valid (e.g. because the time between stations is too short). Or would that overly complicate the tool?

[j-atkins]

Yes good idea, adding a "use same date as previous" would definitely ease the process.

I'm sure there's some way of linking the schedule validation to the tool. There's definitely scope to add error pop ups so I imagine one could be made conditional on the validation. I'll look into it!

[VeckoTheGecko]

Hey! Sorry for the relatively late chime in here.

1. ... However, I've also heard that students don't find manually entering details to the .yaml file intuitive. Is it worth revisiting this? Could we make some kind of simple tool where the .xslx export from MFP is read in, a simple form is launched where per sampling site there are tick boxes for the different instruments, dates and times entered in a little calendar, and then the completed form is automatically written to another .xslx/csv to be used by virtualship init? Rather than manually typing these details in the .yaml?

I definitely agree that we can make the YAML more intuitive - though I think we should clarify/scout our options here. Some thoughts:

• "I've also heard that students don't find manually entering details to the .yaml file intuitive" is there more info here? Which part did they find confusing?
  • Was it the editing of the yaml files? (How are students currently editing files? Were they using VScode, Jupyter Lab? Or something like their native file explorer where opening a YAML file they need to "choose an app"?)
  • Was it the concept of YAML that was confusing?
  • Was it the patching of the YAML created by --from-mfp (given the context of your message, this is probably the most likely)

Since the YAML configs are the core way that users define how to run VirtualShip (and the fact that VirtualShip is a command line simulator at the moment), I think it would be best to provide students with help to make creating valid configs easier, as opposed to creating a GUI wrapper on top that acts as a layer in between (that adds a lot of extra code/dependencies to maintain, as well as de-coupling (a "valid config" would be implicitly defined in the reading of the config part of the code as well as the GUI part of the code)).

Helping students write configs could take the form of better error messages, virtualship check .... which enumerates all the problems with the config file.

3. A new spin off repo which houses some virtualship post-expedition post-processing tools, e.g. makes a nice dashboard of simple plots for the different instruments and sites. Could be used as a quick visualisation tool for the expedition's data or a starting point for further analysis.

• Point 3 (the post-processing) could also help with integration testing. It would/could provide a way to validate that the output of the virtualship is what we expect? Perhaps, therefore, put it in the same repository as the virtual ship itself? @VeckoTheGecko, what do you think?

Its a bit difficult to comment since I don't know exactly what post-processing tooling would be needed for analysing these outputs. Could you elaborate here @j-atkins ?
Re. including them in this repo, if they don't add dependencies and it helps with testing then I think some tooling for this can be included here.

To close, I think we can really benefit from creating a design document to clearly define the scope/direction of Virtual Ship. Just posted #187 .

[j-atkins]

Thanks for the comments @VeckoTheGecko!

• "I've also heard that students don't find manually entering details to the .yaml file intuitive" is there more info here? Which part did they find confusing?

Admittedly I've only indirectly heard this feedback informally after chatting with a TA on the course. Therefore, those who've actually been involved in VirtualShip's implementation so far are more qualified to comment than me! From what I gathered though it was about not really knowing what a YAML is and also it not being intuitive to go into the files themselves to manipulate them. That was what sparked my interest in developing a simple GUI wrapper...something that gives simple selection options and automates the writing of the YAML.

I also see the GUI for the scheduling building part as a bit of a future-proofing idea if VirtualShip is to be used by those with less experience than Masters students (in fact I think there are plans for VirtualShip to be used in a Bachelors course as soon as November, is that right @ammedd & @erikvansebille?). With that in mind, your suggestion in #187 to design some of these development directions sounds useful for getting everyone on the same page...

Perhaps tomorrow in the office I can show you @VeckoTheGecko what I've mocked up already...

Its a bit difficult to comment since I don't know exactly what post-processing tooling would be needed for analysing these outputs. Could you elaborate here @j-atkins ? Re. including them in this repo, if they don't add dependencies and it helps with testing then I think some tooling for this can be included here.

I just think it would be nice to be able to call something which produces one or more basic plots per instrument (e.g. depth profiles for CTDs), perhaps in an interactive framework with toggles and sliders to be able to switch between sampling sites and/or time. It would simply be plotting the VirtualShip raw output data for the different instruments, no statistical analysis or derived variables. Using something like hvplot/xarray, for example. Again this is motivated by a scenario where future users may not be so proficient with xarray to quickly eyeball their VirtualShip output.

To close, I think we can really benefit from creating a design document to clearly define the scope/direction of Virtual Ship. Just posted #187 .

Thanks for this!