dbux-practice Design Ideas + Planning

## Design Consideration

* [ ] the UI should be intuitive to use and _fast_
* [ ] How to manage and store all bug status?
* [ ] How to let users review their user patch?

## More Specific Ideas

* [ ] after solving an exercise, allow user to review correct solution with bug location and corrected version
* Maybe link to a relevant video or repository of solutions?
* Maybe also allow user to see the solution, if they were not able to solve it?
* [ ] [future-work] allow people to submit solution videos, which we can review and add to an ever expanding list of solutions
* [x] Ask for `open workspace` before actually install it
* [ ] #595

## Problems/Discovers

### UI control instruction problems

* Tell users `where to get started`
* maybe using the existing tutorial system?
* How to tell users using `alt+mouse` to pan in `CallGraph`
* add a `tips` in the corner of `CallGraph`?
* add a `grab/pad` button to toolbar?
* recommendation for dialog buttons e.g. `open workspace dialog` -> `Add To Current Workspace**(recommand)**`
* Currently the interface is a little bit complicated
* Since `practice` is a different concept with `debug`, maybe we can move the practice views into new container?

### Lack of clear introduction of bugs

* Chapter introduction
* Before starting challenge the experiment, there is no clear introduction that helps users understand the problem.
* During/Before the activating process, show an introduction about the experiment, which should includes:
* **description**: the expected behavior, the actually behavior
* **background knowledge**: keywords, external links, etc. e.g. `what is an "options" request` for `express#1`
* **label/keyword**: the most important concepts of this bug, so we can classify/filter the bugs by these labels
* **preview of error message**: in the console output, dbux log is massed with program log, a clear error message here helps users quickly understand the error.
* **entry point**: The `Go to program entry point` button should take user to correct file and **lines** including the failed test.
* Ask for opening the introduction view after `start practice`

* After the experiment is complete, show a detailed explanation, which includes:
* The official solution
* The reason we mark the bug location
* How to find the bug using dbux **as soon as possible**

### Unrelated `ContextNode` from node_modules staining CallGraphView

* set default `PackageWhitelist` to ' '

## Performance Optimization

* [ ] maybe don't `npmInstall()` every time?
* only when switching to an exercise that was not previously selected in that folder
* add some sort of "Re-install" button for exercise (available outside and inside the session), to manually fix up a bug (rather than having to delete the whole project)?
* [ ] fix the "cold start very slow problem"
* cold start of a project (or sometimes even of individual bugs) is extra slow because it needs to cache all (or many) files
* -> add an extra warning for first run?
* -> show visual indicator in `ExerciseList` if an exercise already has "warmed up" and the cache folder exists
* -> research webpack caching options (we currently can only cache if `webpack` is not involved)
* that causes some mocha (or other testing-related) timeout to hit
* -> make sure, timeouts are more generous?

## General TODOs

* [ ] change Pathways log: only store relevant application data (that the user interacted with), not the entire application
* have to design the data collection process and find out
* [ ] fix `ProjectsManager.startPractice` bug - currently it tries to (but will always fail to `loadPracticeSession`) because `sessionId` is re-generated
* currently we assume that sessions could not be restart after it is stopped, thus we wont need to reload the session
* if we want to load stopped sessions, we need to provide some way to clear apps in it

## Survey Design
* [ ] consider a config option to opt in/out of surveys, just like VSCode's own `typescript.surveys.enabled` (undocumented)