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.

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:

And when a viewlet already has a context menu:

Clickable title

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

@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:

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’t 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

@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:

• Show elipses in every view container to make hidden views and the ability to hide views more discoverable
• 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

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.

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
• 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 #103813