The official source of product insight from the Visual Studio Engineering Team
UPDATE: We hear you. There’s a lot of excitement about this release and a lot of passion about colors, designs, styles and icons. Know that we are listening to all your comments here, across social media and we are working hard to make Visual Studio 11 a fast, powerful and feature-rich product. Keep the comments coming, both good and bad. We are reading them all.
As we described in our previous blog post, in Visual Studio 11 we’ve focused on helping you spend more time focusing on your code through thoughtful reduction in UI complexity and by introducing search throughout the product. In this blog post we’re going to round out the story of how we’ve allowed you to spend more time adding value to your applications by describing how we’ve simplified common workflows.
As we worked on ways to ensure developers can spend more time focusing on their code, we quickly identified the need for an improved approach to navigating code and related artifacts. Today’s IDEs surface code and artifact relationships through an array of largely independent tool windows. Within these environments developers end up having to re-establish context across multiple tool windows throughout their workday. The obligation to re-establish context across tool windows is a major source of workflow interruption and reduced developer productivity.
Switching costs are particularly pronounced for tool windows that operate over the same data. In such cases the developer not only has to spend time navigating and managing multiple tool windows, they also have to spend time ensuring that the context of each tool window is kept in sync. For example, Visual Studio 2010’s Solution Explorer and Class View both present different views and relationships over the same data (i.e., the code inside a VS solution), yet when the developer switches from one window to another, there is no easy way to keep the two in sync. If the developer is looking at the contents of a project in the Solution Explorer, the corresponding set of classes are not shown when the developer switches to the Class View.
In VS 11, we have created a relationship navigation model that places less focus on the tools, and more focus on the content that the tools provide access to. We have used this model to create new versions of both the Solution and Team Explorer. We call these new explorers, ‘hubs’.
With the Solution Explorer hub, core functionality and information from the Solution Explorer, Class View, Object Browser, Call Hierarchy, Navigate To, and Find References tool windows are now integrated into the one explorer. Thus developers can browse deep within the contents of a file without needing to switch between different tool windows. It’s worth noting that even though the information from these tool windows has been integrated into the Solution Explorer, each of the tool windows still exist. We don’t want to disrupt developers when they start using VS 11 by making them wonder where the tool windows they are used to have gone. When they start to interact with the new Solution Explorer they will become aware of the new functionality offered and will be able to adapt to the new Hub model.
Likewise, the Team Explorer has been similarly enhanced to combine views from multiple tool windows. The Team Explorer now houses multiple tool windows into ‘pages’ and provides a browser based navigation model between each page. With the new Team Explorer developers can find bugs, find pending changes, and view the differences between different versions of files all from the same tool window.
The new Solution Explorer hub in VS 11. In this example the developer has expanded the contents of the LinePaint.cs file and is browsing the class defined in the file.
As noted above the new Solution Explorer hub integrates content and relationships from the Solution Explorer, Class View, Object Browser, Call Hierarchy, Navigate To, and Find References into a single tool (for more information on the new Solution Explorer, take a look at this blog post). Developers can easily switch the relationship or pivot that they wish to browse without needing to switch to another tool window.
The current list of relationships that are exposed as pivots within the Solution Explorer Hub is:
The Solution Explorer Hub is designed to be extensible by third parties, allowing them to integrate new languages into Solution Explorer with support for browsing file contents (i.e., the ‘Contains’ relationship).
This powerful unification of relationships and views within a single browse-able information space allows the developer to browse the logical contents of a file, for example to find the class that is defined in the file. Then the developer can seamlessly follow relationships from that class such as ‘All derived types’ and ‘Base type’ which would previously only have been available from the Class View tool window in Visual Studio 2010.
By gaining access to multiple relationships from the one hub the developer doesn’t have to think about the tool window they need to use in order to browse the relationships of interest. Instead, they just access those relationships directly from the content inside the Solution and Team Explorer hubs.
In VS 11 we allow developers to create multiple instances of the Solution Explorer, with each instance capable of displaying its own unique view on their content. When developers use the Solution Explorer to browse through their code, they can make permanent any view that they consider valuable by creating another instance of Solution Explorer. The newly created instance is a duplicate of the original (i.e., the content and view is the same), allowing the developer to continue browsing in the original instance of the Solution Explorer without worrying about losing the valuable information that they browsed to. This allows them to browse through the code, find something of interest, keep it around, and continue browsing.
Furthermore, each instance of a Solution Explorer can be positioned anywhere in the available screen real estate and can be rafted together with any document window and other tool windows. This provides developers with the freedom to position their content in a way that is optimized for their task. They can establish a rich working context, where the position of documents and tool windows on the available screen real estate serves as an indicator of the task specific purpose of those documents and tool windows. For example the developer could have an instance of the Solution Explorer that shows the list of derived types for a class. They could then raft this Solution Explorer with a document window that contains the definition of the class. Now they have a view on their content that is optimized for understanding the class and its derived classes.
The developer has created multiple instances of the Solution Explorer hub and has rafted code files to each instance.
When we started designing VS 11, one of the core experiences we identified as contributing to lost developer productivity was the experience around collecting and managing relevant code files and related artefacts. While working on a task, developers often end up with large numbers of open documents in the IDE as a side effect of performing activities such as stepping through code in the debugger, triaging search results, or foraging through files in a solution.
For example, imagine a developer is trying to track down a bug that shows up whenever a call is made to some method. They place a breakpoint on that method then step into every method that it calls, and the methods that they call, until finally reaching the buggy code. It’s not uncommon in these situations to step through a number of different methods and different files until finally reaching the buggy code. The end result is that large numbers of files end up in the document/tab well, many of which were only relevant for a short period of time while the developer was stepping through the code. The developer in turn ends up spending valuable time and effort dismissing or working around these irrelevant documents.
We have observed developers adopting one of two strategies to address the problem. In one, developers prune their open document set as they work. Each time an irrelevant document is opened, the developer quickly closes it. In the other strategy, the developer allows documents to pile up to a point where the number of open documents is unmanageable. They then resort to closing all documents and reopening the relevant ones. In closing all documents they lose useful valuable context that has taken time and effort to build up.
As noted above the obligation to close or work around no longer relevant open documents is a major contributor to lost developer productivity. It disrupts developer flow and prevents them from realizing the kind of ‘fast and fluid’ development experience they desire.
In VS 11, the preview tab significantly reduces the number of files that get opened into the document well. This avoids the need to manage these documents all together and allows the developer to maintain their flow and concentrate on their work.
The preview tab achieves this by previewing every document that the developer doesn’t explicitly open (to see a demo of the preview tab and the multi instance solution explorer, watch Scott Hanselman demo these features in this video - start watching from around 27:21). Single clicking in tool windows such as Solution Explorer, Find Results etc. allows the developer to look at the file without paying the cost of opening a full tab. So the developer can triage search results for example without having to open multiple files and then close the ones they don’t need after finding the one they do. Or they can step through code in the debugger, and not have to worry about cleaning up all the files that they stepped into, once the debug session is over.
Each time the developer takes an action that would cause a file to be opened as a side effect, that file is opened in the preview tab instead. There is only one preview tab per document well, so the content of the preview tab is refreshed on each new file that gets opened. In the above debugging scenario, when stepping through all of the intermediate files until eventually reaching the buggy code, the intermediate files are opened in the preview tab instead of opening up as separate, dedicated tabs (see Figure 14 ). The end result is that instead of multiple files being opened in the IDE, only one relevant file (the file containing the buggy code) is opened.
There are no constraints to what can be done with a file when it is previewed in the preview tab. For example, developers can read the content in the file, scroll through it and copy content from the file to paste elsewhere. If that file contains content that is deemed relevant to the current task, that file can be opened in a persistent, regular tab in the following ways:
In conjunction with hubs such as the Solution Explorer, the preview tab further streamlines common workflows, such as browsing code relationships. This streamlining effect is particularly pronounced when using the keyboard as a mechanism to preview content. We strongly encourage you to try this. With the keyboard, you can use “Ctrl + ;” to quickly jump into the Solution Explorer search field and then use the arrow keys to highlight the content that you wish to preview. You can invoke the keyboard shortcut to bring up the list of pivots by typing the context menu shortcut key on your keyboard then use the arrow keys to choose a pivot, resulting in a new list of content. You can continue using the arrow keys to browse and preview this new list. In this way, you can browse and preview long code relationships without ever taking your hands off the keyboard. To see some detailed screenshots and learn more about the preview tab, read this blog post.
The developer has single clicked on LinePaint.cs in the Solution Explorer and is previewing the contents of the file in the preview tab
Removing the burden of having to manage irrelevant open documents provides a much more fast and fluid experience for the developer. But to maintain the win-win nature of that experience, it’s important that the developer can just as easily return to files and artifacts that they have previewed in the past but which they did not open into a regular document tab.
Prior to the introduction of the preview tab the developer could switch between every currently open document using the window switcher (by pressing Ctrl-Tab the developer sees a list of every open document and tool window). If they had closed the file that they wanted to return to though, they couldn’t easily switch to it. They would need to navigate to and open that file from some tool window or other command within the product. At that point the developer’s focus has now shifted to operating the tool rather than concentrating on the task they were working on, as they try to figure out how to get back to the file.
In order to maintain the developer’s focus on their task we have significantly improved the history functionality in Visual Studio 11. Instead of just showing the navigation history through the set of currently open documents, the history now shows every navigation step taken by the developer, regardless of whether or not the files navigated into are currently open.
So if a developer steps through some code then later decides that they want to review that code, they can use the history UI to do so. The history shows the list of files the developer stepped through and allows the developer to open any of the files by clicking on them. Even if the file is no longer open, the fact that the developer previously navigated into it means that they can easily return to it through the history feature.
The developer uses the history feature to browse through the list of locations in their code that they have recently visited.
The new approach to browsing relationships that we’ve introduced within Visual Studio 11, together with the new Preview Tab capability, enables you to explore your code and related artifacts far more comprehensively and smoothly than you could before while significantly streamlining and enhancing many common development experiences. You’ll be able to explore a broad set of relationships with far less need to switch between tool windows. You’ll be able to explore project and file contents, debug, search, check references, review search results etc. without seeing your workspace become crowded by fleetingly relevant or irrelevant content. In short, you’ll spend far less time getting and keeping yourself oriented to your tools and content and far more on adding value to the applications you’re working on.
Monty Hammontree – Director of User Experience, Microsoft Developer Tools Division Short Bio: Monty has been at Microsoft for ten years focusing primarily on developer tool experiences. He and his team provide product design and user research direction for the Visual Studio product family. He has 25 years of industry experience in product design and user research management.
Overall I like the preview pane, it's a great feature. The only annoyance is when you preview a file using different line endings and you get the question if you want to change them. Perhaps make the preview pane don't care about that stuff?
I approve of this blog post! Now get rid of the dead old gray look... :P Really, the Windows Phone, Windows Start Screen and Metro applications look nothing like this...
I really like the history feature. That would save me so much time.
These changes are pretty interesting, and can save some time without being intrusive. I like it. Yesterday's on the other hand... Is there going to be anything changed based on that feedback? The monochrome icons and caps lock text really are a huge negative on the environment.
These seem like great ideas, particularly the document previews and being able to open multiple solution explorers. I wonder if it'd be worth allowing the user to "pin" document tabs, so that you could then close all but the pinned ones later? Perhaps the need for those is largely gone with the excellent preview idea you've already implemented. Or if you could group and save particular documents/tabs as named groups for later. For example, I often have a few files open to do one piece of work, then I run into a bug and start fixing that in some other files, and everything gets jumbled together. Being able to save which documents I have open to a named group, then close them and work on other stuff, then later close everything and go back to my original set of documents, would be brilliant. Similarly, for files that need to be edited as a group. (I guess this can be done using macros to a degree, but that's a pain to set up and manage.) I hope that the new combined solution explorer copes sensibly with C++ code where the namespaces and/or classes may be declared and/or defined across multiple .h and .cpp files. I've found that VS2008, at least, gets confused in places due to .h files declaring classes whose definitions are spread across several .cpp files, for example. Nesting classes in a tree below files, as it sounds like you are doing in VS2012, makes me wonder how that will work with classes that are not entirely contained within one file or another. I hope that if you have multiple solution explorers then VS2012 will remember where they each were when a solution is re-loaded. That will make it easier to do work that involves changes to two projects at once (e.g. work on both a plugin DLL and the main EXE's plugin-API). In the 2nd screenshot with the panels floated as a separate window, I am disappointed to see that the weird, non-standard, non-glass, non-shadowed window borders that VS2010 introduced are still there. Surely WPF can put a standard window border around its owned windows, can it not? I find it not only ugly but at times confusing because the lack of shadow and standard borders means separate windows sometimes appear to be part of each other. But, after yesterday's revelations, this is now quite low-down on the must-fix cosmetics list, I suppose. There's some great functionality and ideas being added to VS, as well as the back-end language compiler improvements you've been making the last few years. It really is a shame that the UI it's all wrapped up in has gone in this direction, apparently to prove that WPF was suitable for real work, which I think seriously backfired and proved quite the opposite.
Kudos for inventing the History and Preview tab features. I have a similar concern as @LeoDavidson: do the pivots all work with Native C++ and C++/CLI code? (ex: Solution Navigator from the VS2010 pack will not show the contained classes in .h/.cpp files for example) If so, in a performant way (ie. faster than the VS2010 F12 symbol-lookup/breakroom-trip feature)? The oppressive gray really distracts me as you were demoing in the video - my eye keeps scanning the screen for what I'm supposed to be looking at - lost in a sea of gray.
Love the neutral gray pallette. It lets the "adminsitrative overhead" fade into background and let me focus on code. Great job.
The "pivot" concept of totally changing my view when I want a different type of data seems counter to the stated goal of minimizing context switches. Make these things part of the normal tree view so they can just be expanded in-place when needed.
I love the neutral gray pallette. Brings back fond memories of my naval days aboard a U.S. battleship. Well done, sir.
@Brian Jimdar, Good for you, I like to do that too: focus on code, whenever I get the chance. Unfortunately quite often I have to navigate around solutions with dozens of projects and thousands of files, and the monochrome icons don't help with that,
1. Search is cool, but seems slow. It either waits too long to start searching or it takes too long to find stuff. We want something snappy; we don't want to wait on it. 2. From Scott's linked video: The Navigate To option is nice, but as soon as the up/down arrow keys are used the search box looses focus (in VS2010); it shouldn't as I may want to change the search query. 3. Multiple SE is a cool feature! 4. Please bring back colored icons in SE! 5. Please have a shortcut key or something to easy "permanently" open a file. I don't want to open it from SE AND have to aim for a tiny pixel area to make it stick (i.e. what was one click in 2010 would be two clicks in 2012). 6. For MVC please have a shortcut key (F7?) to allow easy navigation between view, model, and controller. Thanks.
Wooo, I was joking when I said "why not make it worse and let the office 15 team have a go" Groan... Its a crap pile; Windows 3.1 had more style, and I'm guessing thats what you were trying to emulate with this nasty SWING UI wannabe. I just hope, as do many people, that this is an "option" like the telly-tubby crack-den styling of Windows XP was optional.
Form visuals, this is Disaster Studio Grays over grays, no clear distinction between zones. Hard to fast search and focus on desired zones. Icons with Light Theme - NIGHTMARE Why do you removed icons from tabs ? Icons are fastest way to recognize related elements, so removing them decrease speed in recognizing these element. If you want to do something with icons, then make them flat and decrease shades. Do not remove colors from icons !!! Do not use all caps fonts, because big fonts takes more space. Use small fonts and colors to make them better visible. There is no need do drasctcally save space, used for command. With today high-res displays, there are lot of space for code. Putting command into small spaces make them less visible and recognizable. VS 2010 is best looking. Make themes very similar to VS 2010.
Drab and depressing theme. :::HATE:::::, :::HATE::::: the icons! There is absolutely no way they work better or anything like as well as colored icons. Whoever thought they did is sadly mistaken. Everyone uses both color and shape to recognize them and not just shape.
Looks like a typical cross platform java app, and that's not meant as a compliment. Just bringing back the VS 2010 icons would brighten it up, not sure if it would be enough but it would be a good start.