Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the Getting Started experience #165846

Open
daviddossett opened this issue Nov 8, 2022 · 8 comments
Open

Improve the Getting Started experience #165846

daviddossett opened this issue Nov 8, 2022 · 8 comments
Assignees
Labels
feature-request Request for new features or functionality getting-started polish Cleanup and polish issue ux User experience issues
Milestone

Comments

@daviddossett
Copy link
Contributor

daviddossett commented Nov 8, 2022

Now that the dust has settled on the initial work to stand up walkthroughs and their contribution to the Get Started page, I think it's time to take a look at the experience overall with fresh eyes.

A few questions to kick off a discussion:

Do the walkthroughs...

  • Meaningfully increase retention for new users?
  • Increase productivity by showcasing features like command palette, side-by-side view, etc.?
  • Get dismissed immediately/contribute to a negative experience for experienced developers?
  • Need to pop up right after install? (vs. an opt-in model)

Some obvious quick wins in the meantime:

  • Raise overall UI quality/polish bar for walkthroughs
  • Move/add/remove walkthrough steps as needed
  • Give walkthrough and individual steps a content pass
  • Refresh theme picker thumbnails

Current state

CleanShot 2022-11-08 at 10 09 30@2x

CleanShot 2022-11-08 at 10 09 13@2x

cc @stevencl

@daviddossett daviddossett added ux User experience issues polish Cleanup and polish issue getting-started labels Nov 8, 2022
@daviddossett daviddossett changed the title Identify improvements to the Getting Started experience Improve the Getting Started experience Nov 8, 2022
@digitarald
Copy link
Contributor

Related:

#142219 for todo-model + simple heuristics causing piles of unfinished walkthroughs.
#130417 for an overhauled UI that looks nicer in narrow viewports (maybe even sidebars).

@daviddossett
Copy link
Contributor Author

daviddossett commented Nov 23, 2022

In addition to the many polish PRs referenced above, I've also started looking at the overall interaction model and presentation. Right now I'm looking at:

  • Reducing the complexity by moving away from a to do list model if possible
  • Explore variations in where walkthroughs show up (hero editor experience vs. secondary sidebar)

Here a couple of early sketches. Missing obvious details like "Skip" etc.:

Simplified editor walkthroughs

This is coming full circle in some ways but keeps walkthroughs in the editor. One trade off may be that it feels too "on rails" compared to the experience today where you can jump around.

walkthrough-in-editor.mp4

Walkthroughs in secondary sidebar

This is a more compact view. Advantages: smaller footprint that can stay open while users are doing things in the editor. Disadvantages: hard to fit some content in. Doesn't work as well as a first run experience for VS Code as a product.

walkthrough-in-editor.mp4

cc @esonnino

@stevencl
Copy link
Member

It's worth considering the different goals that people have when they first launch VS Code. Some people want to get on with their work and open a folder, clone a repo etc. For these people, the first exploration above might make it seem like it takes longer to get to their code. It might feel like they have to go through the getting started experience.

Some might want to quickly customize it and set things up the way that they want. That seems to be the most appropriate cohort for the first exploration.

Others may want to spend time getting familiar with VS Code and learning more about how to use it. It's not clear what is going to happen when clicking continue in the first exploration. What content will people see, how will they know when they have finished.

I think much the same is true for the second exploration. The narrow layout though makes it seem like this thing is itself a tool window, a core piece of UI that affords certain actions. I think some people might learn that the way to install an extension for example is to somehow use this tool window to get to the page that allows them to select a language. Certainly that was my experience using similar UI in Eclipse many years ago. Instead of providing a tutorial on how to use the product, these guides became the way to do certain activities themselves and almost made it more difficult to learn how to use the product.

With all of that though, this is definitely something we could use in user research studies.

@daviddossett
Copy link
Contributor Author

Great feedback, thanks @stevencl. I think you're right that there isn't really a one-size-fits-all solution here. As a first run experience, I think the first exploration (with improvements to make it it clearer what will happen next etc.) is better suited to a first run experience.

The second would be perhaps be suited to tutorials that require us to point to/highlight things in the editor/sidebar area. Interesting point re: feeling like a core part of the UI. That may or may not be a good thing depending on what that format was used for. There could of course be other formats. For example, we often see message bubble tours used for a similar purpose. Most people seem to dismiss those right away, but that's just one example.

Today, the walkthroughs suffer from trying to do everything, and it doesn't feel like it really fits for either scenario. Certainly opening up a full editor on the side is a super jarring experience when installing an extension.

I'll do another round of ideation here to see what might be useful to put it front of people in a study if we choose to do one.

@digitarald
Copy link
Contributor

I think the first exploration (with improvements to make it it clearer what will happen next etc.) is better suited to a first run experience.

Even that one will eventually open extension detail views when users install some of the language extensions. Seems like the editor area will always be busy eventually; either because a user opens something as they go through the walkthrough (like installing an extension) or they already have workspace/file open as they start using VS Code (codespaces and other web platforms). Really make me prefer the sidebar for all things onboarding.

@daviddossett
Copy link
Contributor Author

I recall some explorations being done in the primary sidebar. Any learnings there?

@digitarald
Copy link
Contributor

Most of that should be in #130417. Afaik it looked great. Major downside is that some extensions adopted larger blobs of content for walkthroughs; so making that fit/scroll without bleeding into the walkthrough UI is the main migration challenge.

@eamodio
Copy link
Contributor

eamodio commented Dec 7, 2022

Need to pop up right after install? (vs. an opt-in model)

Please make that happen for extensions, I'd definitely want control over having that forced upon users.

As for the layout, we (imo) definitely need better ux when narrow, but I still feel the editor area is the right place for these. The sidebars feel too constrained.

Maybe there is a more sliding panel UX for the TODO section when narrow?

While extensions can't really collect telemetry (which is something else I'd really like) to gather usage/engagement of the walkthroughs I feel like they have helped as our getting started video (though it's both on our sidebar & walkthroughs so I could be wrong) gets a lot of views.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality getting-started polish Cleanup and polish issue ux User experience issues
Projects
None yet
Development

No branches or pull requests

5 participants