The official source of product insight from the Visual Studio Engineering Team
One of the things we’ve been doing in Visual Studio 11 Developer Preview (VS11) is focusing on ways to increase developer productivity and improve the performance of VS. Through careful observation of developers using Visual Studio and through talking to developers, we learned that one of the ways we could improve developer productivity would be by reducing the number of things that developers have to pay attention to and manage. Fewer tool windows, fewer toolbars, fewer irrelevant documents in the IDE would provide developers with more time to concentrate on their own code.
We’ve taken this on board and have made a few changes to the way things work in Visual Studio that we think will result in some big productivity gains. Let’s start by taking a look at how we reduce the number of documents that a developer has to manage.
Reducing Document Overload
Developers often end up with additional documents open in the IDE as a side effect of performing some other activity such as stepping through code in the debugger, triaging search results, or foraging through files in a solution. For example, imagine I am trying to track down a bug that shows up whenever I make a call to some method. I place a breakpoint on that method then step into every method that it calls, and the methods that they call, until I finally reach the buggy code. It’s not uncommon in these situations to step through a number of different methods until finally reaching the buggy code. The following call stack shows a contrived example. I placed a breakpoint in Main and stepped through a number of intermediate methods until eventually landing on the buggy method.
Each step into an intermediate method resulted in another file being opened up in the IDE. As it turns out, these files aren’t really important to helping me debug the problem but they sit there, taking up space, and forcing me to work around them. Worse still, if I get interrupted (and who doesn’t?), when I return to my task I need to read through the files to remind myself that these files aren’t really important. All wasted effort and time.
Enter the ‘Preview Tab’. In VS11, the preview tab is a special tab that we use to display the content of files that aren’t currently open in the IDE. Each time the user takes an action that would cause a new file to be opened, we open that file up in the preview tab instead. There is only one preview tab, so we refresh the content of the preview tab on each new file that gets opened. So in the above scenario, when I stepped through the files containing IntermediateMethod1, IntermediateMethod2 and IntermediateMethod3, these files were opened in the preview tab, instead of opening up in their own dedicated files. And when we step into the BuggyMethod, that too is opened in the same preview tab.
If you’re already incredibly excited at the thought of previewing files and want to try it out all for yourself, download the Microsoft Visual Studio 11 Developer Preview from here: http://www.microsoft.com/download/en/details.aspx?id=27543). This build has the preview tab turned on by default. You’ll also be able to use the preview tab if you have the Windows 8 Developer Preview installed, but you’ll need to make a couple of changes to the registry to use the preview tab with C++ and VB files.
If you have the Windows 8 Developer Preview installed, there are a couple of things you’ll need to do if you want to experiment with previewing C++ and VB files from the Solution Explorer. Add the following registry keys to enable previewing VB and C++ files from the Solution Explorer:
// Microsoft Visual Basic Editor
// C++ Source Code editor
The end result is that instead of five files being opened in the IDE, we only have one file (the file containing the Main definition) and one file in the preview tab. For example:
The tab on the right hand side (containing the file BuggyClass.cs) is the preview tab. We place it over on the right hand side, away from the other regular tabs to indicate that it is a different kind of tab.
When a file is displayed in the preview tab, you can read the content in the file, scroll through it and copy content from the file to paste elsewhere. What if you decide that you want to keep the file around to do some work on it though? How do you prevent the file disappearing as the result of some other action that causes the preview tab to refresh with new content?
There are a couple of ways to open the content in the preview tab into a regular tab.
We don’t just use the preview tab while debugging. There are other scenarios that can result in files being opened as a side effect. In each of these scenarios we make use of the preview tab.
How the preview tab is used
Each time the user performs a goto definition, we’ll show the definition in the preview tab unless the file containing the definition is already open in the IDE
After performing a Find in Files command, selecting any of the results in the find results tool window will show that result in the preview tab, unless it is already open in the IDE. Double clicking will continue to open the result in a regular tab, just as it has always done.
Selecting a file in the Solution Explorer will open that file in the preview tab unless it is already open in the IDE. Double clicking will continue to open the the file in a regular tab, just as it has always done.
Search and relationship pivots in Solution Explorer (call hierarchy, base/derived types, find all references)
The Solution Explorer has new functionality in it that supports extensive code navigation scenarios. In each of these scenarios, if the user clicks on a browsable node in the Solution Explorer we’ll show the file containing that node in the preview tab (unless it’s already open).
This opens up the some interesting new experiences. For example, I can use the arrow keys to arrow up and down a list of results in the find results tool window to preview each result. So I can preview the full context of the search result instead of the single line of text that the find results tool window shows me. Since I don’t have to worry about tidying up opened files after previewing the list of results, I can quickly scan through the list of results to find the result I was looking for. Once I find that result, I can just hit the ‘Enter’ key or double click the result to open it as a normal tab (or click on the Open button on the preview tab as described above).
The same is true for the Solution Explorer. Now that we have integrated many more browsing experiences into the Solution Explorer (through the search capabilities and the ability to explore different relationships such as called by, derived from etc) it’s important to enable those experiences in such a way that the user doesn’t have to pay the tax of cleaning up behind them after they have explored through their code. So if you select a file or indeed any other object contained within a file from the Solution Explorer, we’ll show that file inside the preview tab (unless it is already open). That way you can navigate ‘without remorse’. If you don’t want to preview a file (say you just want to select a file so that you can change its name or you want to drag and drop the file somewhere, you can hold down the ‘Alt’ key when single clicking the file to prevent the preview from showing up).
We think that the preview tab will open up a new way of working with files. We’ve tried to implement it such that it doesn’t get in your way so that we don’t force you to change your habits. Our goal is that over time it will play a larger and larger role in the way that you search and work with files.
We’d really love to hear your feedback so please send comments our way.
User Experience Researcher (Visual Studio)
This is a fantastic idea.
I often run into the kinds of problems mentioned, when searching and debugging code, and this seems like it will solve those problems in a good way.
+1 Simple ideas such as this yield surprising results. Looking forward to using it day to day.
Have you ever considered document sets?
Switching from feature to feature, especially in the early stages of a build and with several BAs involved, is a time consuming task.
If I could group files into a set, where open, save all and close operates on the set, name the set and re-open the set later I'd see a significant productivity gain.
If the code being previewed is in a #region, will the region automatically get collapsed when the preview ends?
I find it quite irritating in VS2010 to have to re-collapse any regions that were expanded, as well as close the files when doing find, step-in etc.
Will there be an option in VS11 to hide the tabs row, like in VS9 and below? Used to help with saving screen estate, and also solved the problem with too many temporary documents -- you just didn't see them :) If you're not programming with mouse, tabs are not too much a help, while commands like Recent Files / Recent Edits / Goto Type allow to do the navigation quickly.
Mildy related, but if you could right-click and do things like Go To Definition in results from Find\Find Symbols, etc, that would be handy and help open less documents. For instance, you search on all references of a repository class in your MVC controller. Then see the call you were looking for:
C:\...\Controllers\AgreementsController.cs - (194, 37) : var agreement = repository.ReadAgreement(case.ID);
To get to the ReadAgreement method now, I click the reference to get into AgreementsController. Then right-click in AgreementsController on ReadAgreement to get to the method. If I could right-click\Go To Definition in the find symbols results, I save a step, and open one less document.
Similarly, Find All References, View Call Hierarchy, etc, would be helpful. I find the repository references since I can't remember the method name I want, then in Find Results I right-click and Find All References again on the ReadAgreement method that I was really interested in. It just gives you a quicker path to your end result without needing to open interim step documents.
Oh, and the preview sounds great! Don't want to just be nagging for more... :-)
The download page says 5.5 GB disk space needed. What in the world???
This all sounds pretty good. I always did end up with large numbers of documents open after a debugging session; and have experienced the momentary confusion you mentioned after coming back from some distraction with all those files open.
Worth noting the preview tab can be controlled from the Options dialogue, under Environment -> Tabs and Windows (at least in the current Developer Preview build.) For me, it defaulted to being off, even though I installed the standalone VS version rather than using the Windows 8 preview. Perhaps that option got blatted when I imported settings from other VS installs - though, as a new option, I wouldn't expect it to be touched. Want that on Connect?
@Keith, your idea is pretty good. Effectively, you want full Intellisense in those panes. I'd probably sling a few votes your way if you stuck that on the UserVoice site :-)
@5.5GB, the Developer Preview build doesn't seem to have any custom installation options. You get all the languages and features installed, along with huge amount of SQL Server guff and the Windows SDK. Hopefully the final version will be as customisable as in the past...
I keep telling people about this feature.
While we're on the topic, look at 1803.previewtab1.png above (where you get the method drop down in the text editor). Why is it that this drop down is missing when .js files are opened?
I like it!
I often run into this issue while debugging, where I end up having a half dozen system library headers or files open that I only needed temporarily.
Quite frequently, my tab list grows and grows until I just close all and start over. Keeping this under control would be way more productive!
Thanks very much for all the feedback. There are some good ideas here, definitely something for us to think about.
I was wondering if anyone has any feedback about times when the preview tab doesn't work so well, or gets in the way?
Steven Clarke - Visual Studio User Experience Researcher
I prefer VB.NET's GoTo Definition behavior in C# as well (open definition in object browser).
At least this behavior should be configurable.
IMHO, the object browser gives a much more in-depth view of browsed class.