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.
Those gray screenshots look surprisingly good at 1:1 scale. If anything please let me tweak background colors (including VS Express!). What I miss is ability of VS to adapt itself to the type of content being edited. I keep all tool windows auto hidden. This suits me fine except for UI editing in Designer where I wish toolbox and properties stayed open. Today VS offers separate layout for debugging (maybe full screen too); this is too little. Can you extend it to have docking state remembered separately for cpp/cs files and UI designer? Another limitation: horizontal scroll bar visibility. I wish I could use it in XML files and nowhere else. Can it be enabled on per file type basis? How about changing tab step in a single file only (like in VC6)? Thanks
The productivity power tools in VS 2010 it seems has been a great testing ground for the new features in this upcoming version. One thing that I suspect is not going to be included because of the new look, but I find extremely useful, is the different tab colors per project. The grouping and clear visualization of what file I'm looking at is of great help. Also, the scrolling ability is pivotal for me. The old drop down menu of 2008 was very frustrating if I have just one too many files open and requires two clicks to navigate. I though the updated scroll bar with the map mode was very well done. It gives a good visualization as to when a reference is hidden in a collapsed section of code. I have not had a chance to try the new version but a few other things that I hope are included are: searchable add reference dialog, fix mixed tabs/spaces, moving lines up and down with Alt + arrow keys, and ctrl + click for go-to-definition. While I do think the new solution navigator/explorer is of good design, I found it a but bulkier than the old one. A possible suggestion is if the arrows to expand a class could be invisible by default but come into view on hover. It is also hopefully 99% of the time that a file only has one class so the double rows being listed are just one more expander to click to get through to the methods you are trying to find. While this belongs in the last post, I have to be yet another strong vote against the new UI look. I found the 2010 version very appealing and actually makes me enjoy starting it up in the morning. The new look and feel just reminds me of 2003 which is a nine year step backwards in my opinion. It is drab and boring, I can't tell half of the icons apart or what they do, and the titles look off-putting. While it is probably a lot of work, this may have introduced a great opportunity to provide full skin support (not just colors) to Visual Studio. I hope this wasn't TLDR, but thank you for the work you do!
When you are on stage and show VStudio's massive grey panes don't even think about saying "I'm excited to be here today". No one is going to believe you. GREY = DEPRESSION. Haven't you learned anything from Seattle's weather?????
Please give us an option to turn on colours, makes things much easier to quickly click
Great new features. I'm personally no so fussed about the themes, so long as this version performs and is stable - your content should be king here not the environment in which it is created, if you don't like something with VS theme then just make sure your app doesn't follow ...
First at all: the productivity improvements like including productivity power toys, preview tab and history button are the right way! Simplify the toolbars by hiding some buttons is also a good step - as a developer i wanna have as much as possible place for content (code, designer, ..). Most of the buttons in VS2010 are waste because the functionality behind could be triggered with "common" shortcuts. So the UI should only offer buttons which a uncommon or meaningful in processes where mouse navigation is usual. The question is: should VS be a tool for fools or professionals - and professionals should know the environment perfect and this means also to know as much as possible the shortcuts to avoid mousing. Whether i like a gray or colored UI will be showed by using the new VS. In the last few years i simplified my environment also in terms of eye catcher. Every prominent artifact pulls the eyes to it - so its consequentially to avoid this: black desktop (thanks to Stardock Fences), dark theme in VS, dimming/minimizing inactive apps, .. So the gray UI could be the right one for me. But: why you use titles in tool windows and then these titles are capitalized?? Outgoing from context in the window it should be clear, what window it is - maybe by arranging and docking the title is shown. After docking there is no need more. And the capitalized title in the current font uses place and is an unintentional eye catcher - please reduce the font and abstain from capitalization. Thanks
I kinda see what you're trying to do with the gray. What you have here is still needlessly ugly, but I agree with the *goal* of reducing chrome and clutter, and letting my code, rather than the countless toolbars stand out. You just need to actually hire a designer to make something that isn't also absurdly ugly. But the ALL-UPPERCASE seems completely random and misplaced. The only reason I can imagine for it is to emulate Metro, but Metro guidelines would never do *anything* like that. So please, just kill it. Quickly. With fire. It doesn't look like Metro, it looks like DOS filenames. It looks amateurish. The functional improvements sound very nice, however. Long overdue, of course, but they're very welcome. But the UI changes? It's everything that Microsoft UI has historically been ridiculed for: dull, ugly, inconsistent and badly-designed, with text that makes your eyes bleed (only now, it's no longer because of font rendering, but because of ALL-UPPERCASE idiocy).
I posted a comment, which, while a bit harsh, was also insightful and not a little bit funny. But, it is missing in action. Hmmm...
Excited...!!! Please, release Beta for us asap.
Couple of comments. First, Solution Navigator, Most developers for most of their files only have a single class in it. The filename is also exactly the same as the class name. It's a complete waste of space for these files to display MyClass.cs |__MyClass It is literally another layer of complexity as well as wasting space. Please fix this. Secondly, the history bring up a list - Great! Except it has the same problem the find currently has - you don't use columns! It's looks terrible and comes across as one big blog of garbage. There's 2 columns - Filename and Line of code. Put the lines of code underneath each other!
posted on the previous blog: I don't understand how you can determine with any statistical confidence when using JUST 76 participants on the icon study. I prefer the VS 2010 color icons much more, and it certainly doesn't distract me one bit from the code. Whoever made the decision to go with all gray should seriously reconsider. Please give us the OPTION of choosing colored icons. This is project management at its worst. Holy smoke. That's right all gray = smoke.
When Microsoft say "we are listening to you", I'd be more likely to believe it if the major, ancient, well-known bugs in the MSDN commenting system were fixed. If you type a comment and click the Post button, one of two things will happen: 1. The page will reload, positioning you back at the top of the page. Your comment will not have been posted, but there will also be no error message. Or: 2. The page will reload, positioning you within the comments thread, with a green box confirming that your post was actually submitted. You only get the 2nd, successful case if you type/paste your comment and click Post within a very short time of (re-)loading the page. So the workaround is to write your post out, then put it in the clipboard, refresh the page, then paste the post and click the button. This is not at all obvious, and I have not seen anything like this on any other website. It seems that blogs.msdn has a *ridiculously* low session timeout, coupled with a lack of error handling / error messages when you try to post via an expired session. This bug has existed since the "/b/" URLs were introduced, and every large comment thread on MSDN -- including this one and the previous one -- has people complaining that the posts they typed up did not make it through. Microsoft cannot possibly be unaware of this problem, given the volume of complains and given that it causes problems on every single comment thread hosted on blogs.msdn. Crazy idea: If you are going to reinvent the wheel and build your own blogging platform, maybe take the time to fix the problems people keep reporting in it? Back on topic, crazy idea 2: Microsoft clearly have lots of teams who want to create custom UIs, like the much-criticised VS2012 one here. Microsoft also own both the Windows platform itself and the APIs, IDEs, frameworks and libraries used to build most of the UIs on top of the OS. So, why don't you make all your apps draw controls using the standard APIs and move the people working on per-app custom UIs into a team where they can create new visual styles (and improvements to the theme APIs and threadbare documentation) which can be used *by the entire platform* and *at the user's choice*? You could even expand the API to allow individual apps or even individual modes/parts of apps to use different visual styles, configured by the user. Then, users who want everything to be gray, or want it to be impossible to tell between a tab control and a static label, can apply a visual style which does those things. Users who don't can use another visual style. Users who want all well-written apps to look consistent can have that, and those who want some apps to look different can have that too. As it is, modern Windows doesn't even allow users to change the colors of standard buttons, which is ridiculous. The UI is long overdue an overhaul, and the time and effort making Office and Visual Studio look completely non-standard should instead go into providing more visual options for the entire desktop OS (Office and VS included). It's good that MS finally seem to be admitting that WPF was a disaster. Maybe once the WinRT/Metro diversion is over, and you get back to spending time improving the long-neglected native desktop APIs, you might take a look at this... I will now put this comment in my clipboard, refresh the page, paste it back, and click Post. :-)
I think the new Solution Explorer is interesting, but without a simple and bare Solution Explorer without all the extra features you talk about here I think it will actually make matters worse for my normal usage of the Solution Explorer. Adding more and more to the Solution Explorer does not yield a better experience. I wish you would have stayed with the Solution Navigator (power tool) for the integrated, many tools in one solution and kept the simple and FAST solution explorer as it was. No doubt the solution explorer will be slower more cluttered than before. So please keep the distinction between solution explorer and solution navigator in tact and let solution explorer be as simple as possible.
The UI looks to be following down the route that Blend took. After having used Blend alongside VS for the past few years, I'm comfortable saying it doesn't grow on you or become more pleasing to use with time, it remains just as awkward to quickly scan for the tab or section you want on the UI as it is on day one. Switching to Silver & Monochrome may appease some in the Design camp, but it removes one of the key quick hints your brain uses to navigate around a complex UI. This isn't a step forwards for UI - If I'm forced to spend the next 3-4 years working on a washed out monochrome UI I'm not going to be impressed. Many of the other UI features people are raving about seem to be taken from a series of popular VS2010 extensions. It's nice that the UI will have some of them directly, but not particularly ground breaking I'm afraid.
I hate the ugly Color Scheme of VS10 but you showed me, that you can much more ugly. For me were the color changes between office 2007 an 2010 a breakthrough. I love office 2010, it is clear, simple and well-conceived. That’s light not yours. Fix it or let us fix that for ourselves.