Skip to content

Convert extension Welcome pages to Getting Started walkthroughs #118402

Closed
@digitarald

Description

@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 Experiment flag for welcomePage.experimental.extensionContributions #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:

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

Open Blockers

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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions