Vscode: Improve first run experience

Created on 27 May 2020  路  18Comments  路  Source: microsoft/vscode

This issue to explore how we might improve the (default) first run experience from the file explorer (and other areas).

Current Experience

Desktop

Today, when you install VS Code for the first time and open a file you are greeted with a series of views in the explorer:

  1. Open Editors
  2. Folders
  3. Outline
  4. Timeline
  5. NPM Scripts

image

Proposal

We can consolidate some of the features that have overlap in other areas:

  1. Hide Open Editors in favor of Editor Tabs
  2. Folders - Keep Visible
  3. Hide Outline in favor of Breadcrumbs + Go To Symbols in Editor
  4. Timeline - Keep Collapsed
  5. Hide NPM Scripts in favor of adding an action ~in the editor toolbar~ via codelenses in the package.json file to surface it

image

Other Ideas

In addition to this proposal, we also discussed the following options that would require more engineering effort:

  • Once we add a secondary sidebar, we could move file specific views onto it (outline, timeline, etc.)
  • For Codespaces: hide the remote explorer and surface port forward through the remote picker
  • For the GitHub extension: combine the PR and Issues view into the SCM view since they are all git related features
  • Make the sidebar headers clickable to surface the view options (right-click menu to toggle views)
  • Add an action from the Go To Symbols in Editor quick pick that toggles the outline view
under-discussion ux

All 18 comments

Outline is not a Breadcrumbs alternative. Those are two highly important distinctive features. It's shouldn't be anywhere hidden by default. #49923 shows how many users not just need Outline on screen, but also completely dedicated, so always on screen and maximized as possible.

So instead of 3 it's better to revert #93764. It has poor usability.

1 is also has huge popularity and very important.

Also assignign to myself since I will have time this and next week to look into this.
To start I suggest that we do the following from your items above: "Make hidden views more discoverable".
That I think is good to have independent of this work and is a good first step so we can hide views more aggressivly by default.
For that I like from the above the following:

  • Make the sidebar headers clickable to surface the view options (right-click menu to toggle views). Also use pointer icon for it.

Ideas from @misolori and me which we discussed on Slack:

  • Have an additional action in each view container Title area clicking on it would show all views
  • Make the View main menu have submenus. So instead of Explorer, it would be a submenu Explorer > Folders, Open Editors, Timeline...

Here are two ideas for how to improve the discoverability.

Global view menu

This would add an ellipsis icon to all global viewlets and surface the view menu. This is the same menu you get when you right-click in the sidebar.

image

This means that we would need to account for when a viewlet only has a single view and the view actions are collapsed with the title:

image

And when a viewlet already has a context menu:

image

Clickable title

This would make the title on all views clickable and surface the same menu.

image

@misolori great work, love it. Especialy the first since it makes it very discoverable. The only nit pick, when a viewlet already has a context menu: I would do it
Views >
Extension actions

So do not put the Extension actions in a submenu. But the Views should still be the first entry.

fyi @sbatten @sandy081 @bpasero even though I think this will be discussed in today's UX call.

I like moving them to ... action and also liked @isidorn suggestion to only move view actions as sub menu when the viewlet has ... actions already.

@isidorn got it, so then the context menu would look like this:

image

Feedback from our ux sync:

  • ellipsis options makes the most sense
  • ellipsis is supposed to be used for overflow, which we only use in the activity bar and panel
  • if we think we'd want to bring this pattern to other areas where you can toggle views (like the panel and activity bar) then we'd need a different icon/pattern
  • we can do this only for the sidebar since we're solving the discoverability there
  • extensions would need to update its context menu items since "Show..." actions are query filter and could be confusing with toggling views (@sandy081 to follow up)
  • showing the same list in the global view menu doesn鈥檛 make sense since that is used for navigation + keyboard shortcut references as opposed to toggling views

Great feedback, all makes sense.
I can look into adding the elipses for each view in the sidebar so we have something to start.
Though I do agree that it would not work well for the panel since we already have elipses there and double elipses or mixing the views and containers would be confusing.
So I suggest that we maybe try to have a solution which would scale well to other views -> thus let just use a different icon.
Maybe something resambling mulitple views. @misolori do you want to sketch up some icons when you find the time?

So I don't think we're going to find a good icon for "views" since that is a pretty hard concept to show and we already have similar icons that represent view:



I still think we should stick with using the ellipsis since we also use this for both overflow and showing actions (view context menus and editor ellipsis). Here's how I think we can use the pattern in both:

  • Use the same pattern as before, when there is no overflow we show all view options
  • When there is overflow, we group view toggles in view menu
  • The ellipsis icon would always be visible

image

@misolori I like this suggestion a lot for the panel.
So let's go with the elipses. I can look into the implementation.

For the first run experience I think a good first steps for this milestone are the following:

  • [x] Show elipses in every view container to make hidden views and the ability to hide views more discoverable
  • [x] Have Open Editors collapsed by default
  • [ ] Move NPM Scripts into an extension @egamma

We'll see how these changes are accepted by the community and then next milestone we can

  • [ ] Show elipses for hidden views also in Panel
  • [ ] Think about the Timeline view @eamodio
  • [ ] Think about hiding OUTLINE and OPEN EDITORS only for new users @jrieken and @isidorn We will probably not do this, but we should think about it

Let me know if this makes sense to you @misolori

Think about hiding OUTLINE only for new users @jrieken and @isidorn We will probably not do this, but we should think about it

Don't think about it. It's unproductive. It's one of most important feature and fundamentally basic feature of IDE.

I have pushed an initial version of the elipses in the title area
Try it out with VS Code insiders from tomorrow and let me know what you think.

Screenshot 2020-06-22 at 16 33 49

So for this milestone we only need to move the npm script to an extension.

I see that we have created an issue for moving the npm scripts view out to an extension.
Since that issue tackles that, and we have done in this issue what we planned for this milestone I am moving this out to July for the other 3 remaining action items from above:

  • [ ] Show elipses for hidden views also in Panel
  • [ ] Think about the Timeline view
  • [x] Think about hiding OUTLINE and OPEN EDITORS only for new users. We will probably not do this, but we should think about it

I see we have hidden the npm scripts view by default which is great.
We will not hide the OUTLINE and OPEN EDITORS views due to their popularity.
I am discusing with Eric if we should hide the Timeline view by default.

As for the panel, we could render ... in the left most area of the actions and if there is not enough room to render all the panels we would add another section to the ... effectively merging the panels and views in one context menu. I think this could work nicely, but nothing for July, thus moving out to On-Deck.

@isidorn I made the changes to hide the Timeline view when there are no (excluded) registered providers -- this should help the first-run experience at least when the Timeline view wouldn't be useful.

@eamodio thanks for doing that. I just tried it out and it works nicely.
Since we have done most of the things planned in this item I am closing it and for ... in the panel I have created this follow up item https://github.com/microsoft/vscode/issues/103813

Was this page helpful?
0 / 5 - 0 ratings

Related issues

biij5698 picture biij5698  路  3Comments

chrisdias picture chrisdias  路  3Comments

trstringer picture trstringer  路  3Comments

sirius1024 picture sirius1024  路  3Comments

villiv picture villiv  路  3Comments