Otter Training in the Showcase application

[sdo-1A]

We are currently in the process of creating a training template for Otter training within the showcase application. Our goal is to create a training format that is as easy to use as possible for those that are going through the training and for the Otter team to maintain.

The training will contain explanations, instructions, and interactive exercises along with their solutions.

We invite you to check out the current progress of this training at the following link: https://sdo-1a.github.io/otter/#/sdk-training#0
Note: Please ignore the content of the training for now as this is currently in progress and is being updated.

Please provide us feedback or suggestions on the training format/experience.

[fpaul-1A]

Here are some improvements that I would suggest

Compact UI

When doing a module with instructions, files, code, terminal, output, preview, there are a lot of thing (plus the header and side navigation)
It would be nice to be able to display the playground section (files, code, terminal, output, preview) in full screen so it can be opened in a new window
When performing the training, I would like to have one screen with the instructions (not the code) and another with only the playground

Note

Mostly fixed now with resizable areas

Slow loading

It takes more than 1 minute to load the playground for me with the only visual feedback being Loading...
It could make people think that the app has crashed when seeing the Loading thing for so long
It would be nice to check how we can make it faster (cache? preload?...)
Also, having an estimation of the percentage of progression would help (if possible) or show that something is happening in the Output section

Note

We now have a load indicator with step label and the loading time has been highly decreased
I believe it is now acceptable

Persistence

If I am doing the training and refresh the page for some reason, I loose all my changes. That can be very frustrating.
We should put in place some kind of persistence of the code.
I've noticed that we don't loose the code when going back to a previous step which is already good.

Note

Done with #2579
We still have to add a Reset or Discard button
We also may review the way to store changes in the localStorage

[matthieu-crouzet]

For persistence I agree but I would expect a reset button

[fpaul-1A]

I was thinking about having a prompt when reloading the page asking the user if they want to restore the previous state or discard it

[matthieu-crouzet]

To not pollute the localStorage with too much data do you think we should store only the modified files ?

[fpaul-1A]

that's probably a good idea

[matthieu-crouzet]

Here are some improvements that I would suggest

Unit test

A suite of unit tests could be added for each exercise. When the editor is displayed, a background process is launched to run the suite. Once the suite is successful, a successful message could be shown to the developer and propose him to check the proposed solution or go to the next exercise.
The test suite may not be visible by the developer in the editor, so he can't watch the solution, but he must have access to the result of the test execution to understand easily what is missing to validate the exercise.

Auto-save

Should we keep the auto-save ?
I would love that the propagation of the ctrl+s event is stopped when the focus is one the text editor.
Should we keep the auto-save or let the user decide when he save the file (maybe it could be a user-preferences, saved in localstorage) ?

Note

ctrl+s event is not propagated anymore

Git diff

I would expect to see the solution in git diff mode (for files tree and file content)

Multiple files

I would like to have a list of opened files.
Like this we can open several files at the initialization