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.
I have an OOT request: Could you make this blog view defaulted to "Excerpt View" instead of "Full Post View", just like IE and B8 blogs? It took ages loading blogs.msdn.com/.../visualstudio, especially with those many and long posts, combined with slow internet connection. Thanks.
@LeoDavidson, To save open documents to a named group and later go back to these documents, you can use the free Favorite Documents extension (developed by me): visualstudiogallery.msdn.microsoft.com/d4ab8421-147f-4416-8038-d5f7fdcf6a56
I just can't get over what you've done to Visual Studio. I'm so glad you are listening, the proof of the pudding will be in what you actually put out, MS do not in my opinion, have a history of listening to their users - more "here's what you're getting, and ::::YOU WILL LIKE IT:::: !". I hope this new theme is all encapsulated in a single theme class somewhere, somewhere you can revert the changes easily, and not scattered across the entire application. Still sad :sadface:, still hopeful you will see this for the error it is before release though. Fingers Crossed.
i want the winforms designer on one screen and on another the code. Will that be possible with VS11? There need to be better multi-screen support on VS!
I like the dark theme, but I really hope there's an option to turn off the unnecessary capitals in the dock tabs/titles. Why do the least important bits of text need to stand out the most?
Make a shortcurt to unpin all windows, and another shortcut to get all windows as before.
@Sergey Vlasov: Thanks! That looks like it will be very useful.
There are some good ideas, for example search everywhere is really a good thing, adding new features to the solution explorer is another good thing, but the UI please, please listen the developers comment in all blogs posts announcing the VS11 Beta and, at least, give us an option to have the UI less depressive, if not completely roll back your work to VS2010 look and feel! It would be nice if you guys open a poll on acceptance of new look so you can see how many of us really like or dislike. There is however a suggestion in uservoice site visualstudio.uservoice.com/.../2623017-add-some-color-to-visual-studio-11-beta for bring back colors. Apart from UI perspective, what about perf? Looking at the VS2010 uservoice visualstudio.uservoice.com/.../top, it seems that many of us voted for a better overall performance, so are there any improvements in VS11? @Brian_Jimdar ... you can't be serious.
I LOVE the new interface. As a designer who has to use visual studio to get work done it is great that you guys are finally creating tools that we would enjoy using. Developers may not like the new look but they'll get over it. The muted pallette allows use to focus on the content and not the chrome. Great job!!!
I approve changes and new features but the downside of this is the gray palette. Please understand that is really hard to navigate to other parts of solutions, options and menus/toolbars without significant visual differences. Yes, you can disable toolbars and so forth but for all of us that DO use them it is a nightmare not having the visual colored cues.
Please stop listening to people about colors and icons. I'm starting to wonder whether all of this public comment really has that much value...it seems like most of it is just noise. Every time I read a blog post on the a new feature the bulk of comments seem to say something along the lines of, "Please always let us use whatever new features you've worked on, but don't change anythin, and why is this taking so long? Linux on the desktop. Ron Paul 2012." Maybe comments would be more useful after the product has been released and you want feedback.
@Brian_Jimdar is correct. People who "get" design know that you guys are going in the right direction. Using Visual Studio is going to be much like using Adobe CS suites as the content will be much more prominent now!
@Robert: when I look at Solution Explorer, that is where my focus is, that is where my content is. Of course I want colors there, the same way I want colors (syntax highlighting) when I am focused on code in text-editor. By the way, you can hide/auto-h
Apple is introducing HiQ displays with ridiculously high resolutions and you guys are getting rid of color in your toolbar icons. Somebody is right. Who would you bet on? Seriously, I live in Visual Studio all day long and it is my favorite piece of SW so I have the moral authority to say STOP! Those screen shots are horrible and depressing. At least give me the choice of legacy mode if you must go this route. Is this an early April Fool joke?
to start with let me say i'm not a programer.. i'm a UI/UX guy... its very recently I shifted from Dreamweaver to VS2010 to better integrate me with my programming colleagues workflow.. and kinda have started appreciating the "VS ways" of doing things... but in no ways is VS2010 a replacement for DW, yet.. lots of quirks and missing things in the HTML/CSS/JS world of VS.. when i read about the new things coming in VS 11 especially the HTML/CSS/JS improvements i was excited and got very interested... AND then you people dropped the bomb of these two post on all of us unsuspecting VS users... another small titbit about me... i'm a WinPhone 7 user for the last year or so and I LOVE IT.. i also like the Metro things happening on the Win8 front... so without much further ado here are my thoughts on VS 11 "user interface"... i like the dark "theme" a lot and that's how my VS2010 looks like except for the icons (obviously)... to me the icons in VS 11 are not as clearly defined/identifiable/understandable as some/all of your UX guys would like you to believe.. speaking of which.. a 76 user test group to see the impact of new icons..!! really..!! if VS2010 had maybe 760 total users in the whole world then that "76 user" test group would made sense.. even at a total 7600 user-base a "76 user" group does not make sense and i'm pretty sure the total number of VS users is in millions if not 10s of millions or more... another thing i'm pretty sure of - when this "control" group (assuming it was the only group) of tester were presented with the icons to identify them, they were presented either on a big projected screen or as placards... even if they were shown on normal screens i bet they were bigger than their real world 16x16 pixels size.. only that would explain the group not showing any noticeable negative impact... the XAML icon in the solution explorer...!! they stand out like sore spots against the "In VS 11 we have transitioned to glyph style iconography throughout the product" statement... heh..!! tells me to expect such sore spots "throughout the product" i guess.. about the colors... color for humans is the biggest form of differentiation/identification... imagine our stoplights all in grey... not red, yellow and green... just grey..!! would that have worked for us..? nope.. right..? but by your UX people definition they should, after all a circle is also a type of glyph... the CAPS thing... forgetting that its aesthetically and typographically "wrong", its also very distracting in that those headings attract more attention than necessary.. that makes it "anti-Metro" as its grabbing more attention than the content.. don't know about Win8 but in WP7.x nowhere in the UI are ALL CAPS employed but "all smalls" are.. and probably in VS 11s case that would work too..!! get rid of the leading and trailing colons too... colons instead of lines.. who came up with that idea..!! by the way, the "ALL CAPS = screaming" etiquette is not just true on the internet... it is said that a good UX/UI always generates mostly positive response form the target audience which in this case is your "EXTERNAL" developer, developer, developer (sorry couldn't myself there :D )... so i would have to say your UX team was totally out of sync with its target audience... or they were not allowed to be exposed to the target audience before this point.. and judging by latest trends inside MS it's probably too late to expect any changes between beta and final release... finally be clear and courageous enough to accept that these are not "mixed feedback" concerning the UI.. mixed would have been 50/50 positive/negative at worst... but these are more like 30/70 positive/negative...