-
Notifications
You must be signed in to change notification settings - Fork 29.1k
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
Comments
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:
Here a couple of early sketches. Missing obvious details like "Skip" etc.: Simplified editor walkthroughsThis 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.mp4Walkthroughs in secondary sidebarThis 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.mp4cc @esonnino |
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. |
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. |
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. |
I recall some explorations being done in the primary sidebar. Any learnings there? |
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. |
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. |
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...
Some obvious quick wins in the meantime:
Current state
cc @stevencl
The text was updated successfully, but these errors were encountered: