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)