Roslyn: Visual Studio 15 RC - Context menu bloat?

[eyalsk]

Is there any reason why the context menus of the editor are so bloated? is it for accessibility? discoverability? honest question here!

The Code Editor and Project and Solution context menus have many items that don't make sense and when you have extensions installed and many other things you find yourself in a really unpleasant place so you have to customize it and I wonder if there's any plans to shrink them down?

One possible solution is to have one group on the context menu dedicated to extensions and then have one sub-menu per extension where this is enforced by Visual Studio for all the stuff related to it, currently there's an anarchy of vendors and items are just scattered throughout the context menus.

In addition, I think that some items are just there for the sake of it and not for a _reason_ like in the Code Editor, here are few examples:

1. Cut/Copy/Paste - Most people would probably use keyboard shortcuts as opposed to clicking.
2. Outlining, Snippet - Same as above.
3. Snippet - Same as above.
4. Source Control - Command-line or same as above.

Now, like I wrote above I'm not sure if these were added for accessibility or discoverability but maybe you can ask the user how he wants it or by default have only refactoring stuff and navigation stuff like Peek Definition, Go To Definition and Go To Implementation.

Maybe you can offer different experience to the user like Typist, Clicker, Blind, Deaf.. sorry I'm not good with names but this isn't meant to be a joke but just a way to improve the experience for each kind of user, finally you can let the user select how he wants the experience to be, I'm not sure what's the best approach to take here but either way I'm not really using the context menu as I prefer the keyboard but when I do I'd really want to see only refactoring stuff and navigation stuff there.

[CyrusNajmabadi]

paging @kuhlenh

Most people would probably

We've actually done a bunch of work for VS2017 to trim things down. What we have not done though is simply 'guess' at what is useful or what people are actually using. We've instead taken the actual data for how people use the product to help pare things down.

[jmarolf]

@kuhlenh can give a more detailed answer here. We have been trying to reduce the number of items from the context menu and making the overall experience better. Unfortunately the VS extensibility model does not allow us to restrict where an extension places an item. Perhaps you could take that up with the extension author?

[CyrusNajmabadi]

Also, the design of vS makes it so that nearly everything (including Roslyn) is an extension.

[eyalsk]

@CyrusNajmabadi

We've actually done a bunch of work for VS2017 to trim things down. What we have not done though is simply 'guess' at what is useful or what people are actually using. We've instead taken the actual data for how people use the product to help pare things down.

Okay, fair enough, I didn't mean to imply that you didn't do your research or anything, in fact, I'm sure you did but just saying that users like me, i.e., people that like shortcuts and like the command-line more than clicking stuff wouldn't want to see the items I mentioned in their context menu but then again that's just an assumption based on my experience and some friends so I thought that if we feel about it that way then there are probably more people that feel the same about it as we do.

I'm using the context menu for things that I don't use often and/or I don't want to assign a key for them.

Also, the design of vS makes it so that nearly everything (including Roslyn) is an extension.

Yeah, I know but I thought it would be possible to have all 3rd-party extensions in different sub-menus to reduce the clutter, I didn't mean to put everything in sub-menus.

[eyalsk]

@jmarolf

@kuhlenh can give a more detailed answer here. We have been trying to reduce the number of items from the context menu and making the overall experience better. Unfortunately the VS extensibility model does not allow us to restrict where an extension places an item.

I think that one of the issues here and maybe this is the actual problem is the Customize window itself.

Today, if you go to this window you have the Commands tab where you are presented with 3 radio buttons and a drop-down lists and then you have to select what you want to customize.

The issue with this is that extensions can register commands in many places and you can't just have an option to delete them globally or delete them all from an individual toolbar or menu, you have to delete one command at a time from each place and this can be a daunting task.

I think that a better approach would be to show a list of extensions and have a fine-grained control over them where you can go to a specific extension and have a list of all the toolbars and menus that are available to it and then decide whether you want the extension to show up on a specific toolbar or menu or even what items to show up on each, I'm not sure whether this is even feasible but it's just an idea.

Another issue with the Customize window is that you can't search anything because there's no search feature so it's pretty _cumbersome_.

_I'm fully aware that something like this wouldn't be within the time frame of VS15 but maybe later at some point, the question is whether you thought about it? or have any plans to revamp the Customize window?_

Perhaps you could take that up with the extension author?

I can certainly suggest JetBrains to have an option to group their commands into a sub-menu but I'd have to go through each vendor and ask them to do the same.

[Pilchie]

@kuhlenh Can you share some of the work behind the new context menu?

[eyalsk]

@Pilchie I'm working on a console application, didn't choose the Azure workload at all because we're not using it atm and yet the option "Publish as Azure WebJob" is showing up in the context menu of "Project and Solution" where I think it shouldn't.

[kuhlenh]

Hi all --

Glad we agree that the editor context menu is very important and essential to many developers' everyday workflows! To give some insight into our design choices, we established that commands that belong in the editor context menu:

• Are dependent on cursor location
• Are in the "top-level" (i.e., not nested) if they are used by a considerable number of users multiple times in a session
• ~ Do not have another way to perform the command other than in the editor context menu

Given these, we looked at usage data to determine what did and didn't belong. We altered the order of commands to move more frequently used commands (e.g., navigation) closer to the top. We added keyboard shortcuts to the most commonly used commands so that mouse-users/new users can more easily learn keyboard shortcuts.

Here is a before/after:

Note: work on the context menu is still in-progress...some commands need only to appear if tests are present, for example. Others should disappear if you are actively debugging versus in debug "break" mode.

To address the comment on Copy/Paste -- As a fellow keyboard shortcut user myself, it is hard to imagine that there are some developers who rely completely on their mouse for navigation, code fixes, copy/paste, etc. However, there is more than enough data to show that a significant portion of the VS developer base is mouse-dependent (even with copy/paste). That said, there is definitely an opportunity to cater to "power users" of VS and it's something we're looking into...my colleague Justin is working on something with his hot keys extension, for instance.

[eyalsk]

@kuhlenh

my colleague Justin is working on something with his hot keys extension, for instance.

That's cool, I'll check it out.

Can you say anything about commands that show up regardless to the chosen workloads? like I've described above?

[CyrusNajmabadi]

each command must be handled on a case by case basis. The appropriate team needs to be involved and things can be improved. I would honestly recommend opening specific bugs for each item so that they all can be appropriately tracked. Note that i'm not a fan of Roslyn hosting these bugs. But as i think VSFeedback is a pretty terrible system, we might as well use here (especially as this is an area @kuhlenh has been heavily involved in driving).

[eyalsk]

@CyrusNajmabadi Can't you create a repo that is dedicated to Visual Studio issues? I have many suggestions that I can't really post here and I think that the benefit would be that users would get the ability to post both bugs, suggestions or whatever in a single place instead of sending them to UserVoice for suggestions and another place when they have problems.

[CyrusNajmabadi]

Can't you

You meaning @cyrusnajmabadi? No :)

I would like it if the appropriate VS groups did this. But i'm not in control of any of that. Just a lowly language guy over here :)

and I think that the benefit would be that users would get the ability to post both bugs, suggestions or whatever in a single place instead of sending them to UserVoice for suggestions and another place when they have problems.

Sounds eminently sensible.

[eyalsk]

@CyrusNajmabadi

You meaning @cyrusnajmabadi? No :)

Might be a _peon_ but awesome nonetheless. 😉

I would like it if the appropriate VS groups did this. But i'm not in control of any of that. Just a lowly language guy over here :)

Okay, I hope that some of the guys that are in charge of this will think about it and _maybe_ give it a go.

Thanks!

[Pilchie]

I think this discussion is done for now. We'll be continuing to look at telemetry to refine the context menu though.

[magol]

Even if you are doing a much needed c ledning of the menu, I still think it is too long and too difficult to navigate.
Have you considered using something else? eg Ribon

[eyalsk]

@magol I really hate the Ribbon control. 😆

In fact if I could I'd remove many things from Visual Studio in terms of bars and context menus but that's just me.

_I can customize it to some extent but it takes time so I just live with it._

[magol]

I don't say that ribbon is the best solution, It is only one solution.
I can not give any good suggestiva, but it must be many way to Solveig it that is much beter then how it is today.

[jmarolf]

I think we need to have the best defaults we can, and then try and make the customization experience better. Today the its too difficult to change what shows up on the context menu.

[eyalsk]

@jmarolf It's not only the context menu but the toolbar too, the Customize dialog really needs a revamp, it was nice if we had something similar to FireFox Customize tab at least in terms of concept.

[jmarolf]

@eyalsk I agree, context menu it the topic of this thread, but we would want to change the customization dialog for all options if we got the time to do it.

[magol]

It is not realistic in the short term to do something radically different.
It is a good compromise to expand the customization options for menus and toolbars.

[eyalsk]

@magol They are doing something already, cutting down the amount of items but what I'm suggesting is actually long-term goal for _maybe_ VS vNext or an update for VS 2017. :)