Convert extension Welcome pages to Getting Started walkthroughs

[digitarald]

To further refine #118055, we need to convert some existing welcome pages (aka: anything that extensions pop up on a fresh install) to use the proposed getting started API. We expect that this migration can a) make start pages more contextual and timely, and b) provide organic discovery for extension content.

Each extension can roughly follow these steps:

1. Walkthrough content draft. Easier to collaborate and iterate on the overall journey and detailed copy.
2. Ship walkthrough declarations to release. Until VS Code enables extension walkthroughs, these will not be visible to users but will be ready for usertesting & experiment steps.
3. Test E2E scenarios
   • New and returning user in VS Code
   • Remote & Codespaces
4. In parallel:
   1. Usertesting each walkthrough. Ask participants to enable workbench.welcomePage.experimental.extensionContributions on Insiders before guiding them through the usual language/extension setup.
   2. A/B experiment each walkthrough. Use the flags provided by #122966 to enable walkthroughs to run independent experiments for each extension walkthrough. If an extension has custom welcome page, the same flags need to be used to disable those.
      • Independent of experiments on each walkthrough VS Code can run experiments on when to show walkthroughs and other tweaks to the experience.

Progress

To start with, we are looking into extensions that have been coming up during usertesting:

• [x] Python (Start page)
  • [x] First conversations: Ongoing work on an updated Welcome page that.
  • [x] Shared UX template
  • [x] Prototype the current Welcome content in Getting Started
  • [x] Land walkthrough in Insiders: Blocked by providing a when clause for python detection.
  • [x] Shipped
  • [x] Test E2E scenario (vscode new and returning user, remote, codespaces)
  • [x] Usertesting
  • [x] Experiment
  • [x] Done
• [x] Java (Getting started, Welcome, Extension guide)
  • [x] First prototype completed
  • [x] Shipped
  • [x] Usertesting
  • [x] Experiment
  • [x] Done
• [x] C++ (no welcome page)
  • [x] Kick-off meeting
  • [x] Draft content proposal
  • [x] Shipped
  • [x] Test E2E scenario (vscode new and returning user, remote, codespaces)
  • [x] Usertesting
  • [x] Experiment
  • [x] Done
• [x] WSL (Welcome page on hold)
  • [x] Draft content
  • [x] Shipped
  • [x] Usertesting
  • [x] Experiment
  • [ ] Done
• [ ] TypeScript
  • [ ] Prototype content
  • [ ] Shipped
  • [ ] Test E2E scenario (vscode new and returning user, remote, codespaces)
  • [ ] Usertesting
  • [ ] Experiment
  • [ ] Done
• [ ] 💪 Live Share
  • [ ] Prototype content
  • [ ] Shipped
  • [ ] Usertesting
  • [ ] Experiment
  • [ ] Done
• [x] 💪 Docker (Start page running as experiment right now)
  • [x] Draft content
  • [x] Shipped
  • [x] Usertesting
  • [x] Experiment
  • [x] Done
• [x] 🛑 ~Azure~
• [x] 🛑 ~.NET (ongoing work)~
  • [x] Kick-off meeting

Open Blockers

• https://github.com/microsoft/vscode/issues/119725
• https://github.com/microsoft/vscode/issues/119709

Learnings

• Opening files, build-in pages and projects without yanking users out of getting started
  • Commands and flows that open new tabs need to be opened side-by-side with getting started.
  • New projects currently open a new window. Could either open in current window (if empty) or with getting started restored.
• Most extension Welcome pages offer focus on the multiple ways to get started: Open folder, Open file, New file, New file type x (from template), Create project (from wizard), etc
  • How do we expose in Getting Started, which follows a serial content pattern
  • Contribute those entry points in Welcome page and Explorer

[digitarald]

Demo for the Java extension (pull request) as example:

https://user-images.githubusercontent.com/8599/113540150-55ac8480-9594-11eb-8ba9-7f3f10b2283a.mp4

[sean-mcmanus]

@digitarald With our C/C++ extension we're seeing "when": "isWindows" giving results for the local machine when we need the remote machines. Should we file a VS Code bug or is there a different "when" clause we should be using (I don't know where the valid values for the "when" are documented, update: I found it at https://code.visualstudio.com/api/references/when-clause-contexts, and I don't see any means to check the remote OS).

    "walkthroughs": [
      {
...
        "steps": [
          {
            "when": "isMac",
...

UPDATE: I filed issue https://github.com/microsoft/vscode/issues/123824 .

[luabud]

cc @kimadeline

[digitarald]

Experiments should be wrapped up in the coming days, wrapping this work up with an analysis.

[digitarald]

As most extensions shipped walkthroughs, breaking this down into smaller follow up items.