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.
Wow this looks terrible.
Looks like we're getting increased productivity out of VS11 and this is a step in the right direction regardless of what it looks like. Am wondering, I have Interfaces all over the place and I'm wondering if Go To Definition (F12) can take me to the method that is being used rather than the Interface?
It needs a splash of color! I like the metro-inspired look and feel but the overall impression from a distance is very dull and "battleship gray." It reminds me too much of Eclipse, ewwww. I would love to see some striking Bing imagery or some bold Win8 colors somewhere in there. It doesn't have to be gaudy; a little color goes a long way.
I would also just add that anything you can do to improve performance will make the whole experience better. Going from older versions to VS2010 was a great experience except that everything seemed to take longer. That was the main complaint my team had.
The features look great, I think we all hope to see an increase in performance. As far as the theme goes, I love it but I hate it :)
Are they going to add the 2007 style ribbon? It is nice ^^ :) I looks great, but do something about the dead grey theme/color. That was all!
come on guys, black text on a white background, please (or visa versa). NOT hsl(0,0,11) on hsl(210,0,90), please. that's just not enough contrast for text that I'm going to be reading for about 1/4 of my life. if anything's going to hurt my ability to focus on the content, it's going to be me continuously cursing your names for causing me to squint in order to satisfy some need to try the latest UI fad on my work environment. no hire. seriously.
I also miss the colours, this new version looks dim, depressing and old. If any design changes are to be made, I think Visual Studio should conform a little more to the new Metro styling. Obviously it can't get there quite yet, but I think more steps should be taken in that direction. Above all though, please bring the color back, those pictures look like a color filter was applied to the code for the purpose of this presentation. I have never had trouble focusing on the code with previous versions of Visual Studio, and this look just makes me feel gloomy :(
I am, however, a fan of the all caps fonts. It makes them stand out and clearly highlight different sections, which I felt I had a little trouble with in previous versions. The more I look at them and think about it, the more I like the all caps fonts for section headers, and I would even like to see them used a little more, as it fits the Metro style of simplicity.
The new features, such as enhanced Solution Explorer, preview tab, and Quick Launch, are great. But we've seen them before in previous blog posts and the developer preview. However, the new IDE theme is horrific IMO. The soulless icons are awful, the all-caps text is difficult to read, and the lack of icons on pane tabs will make it harder for me to identify them. The colon-lines look amateurish, and the uniform grey looks like 60s concrete block architecture. VS2010 (and VS11 dev preview) had a nice feel to them - if you're spending all day working in one application, you want something pleasant to look at. Here, I prefer the dark theme to the light one, but even that's too high-contrast to be uncomfortable for me. I appreciate that some others may like the new theme; but what I'd ask for at this stage is for you to just reinstate the VS2010 theme - icons, lines, colour and all. Leo - you're not wrong. I reported the timeout issue ages ago and had a little conversation with the blog team about it, but it doesn't seem to have been fixed. Like you, I've developed a habit of copying my posts to the clipboard before submitting :-) Even today, I signed in with the link at top-right, put my password in, only to find when the page came back that I wasn't actually signed in at all. Pressing it again worked, without requiring my password this time. But now the comments were chopped into pages, with no obvious way of showing them all at once. Looked in the settings, but didn't see anything that appeared to control that; pressed "back" in my browser only to be told the blog page had expired. Had to re-visit my shortcut to this blog and navigate back to the post. I think the Windows Live ID/MSDN infrastructure is probably the buggiest web service I've ever used - but as Microsoft-focussed developers, we're stuck with it. (As expected, I hit the timeout and scrolled down to notice my comment hadn't been posted...)
Do the 40 active developers used in testing this souless UI constitute even 0.00001 of real programmers? Hint: 10's of millions / 40... Bonus Question: How many of the 40 are actually "designers" and not really developers? Sorry designer guys, but your brains work differently. Having input from designers for a programmer's tool is like getting input from a chef for the design of a farmer's tractor.
Great blog - with lots of history /background. lots of improvement, but as Andrew mentioned time-outs are still frequent and there are np indications to them being addressed.
Great Blog - with lot of background / history. lot of improvement but as Andrew says time-outs are still an issue which seems there is no mention of addressing soon.
I guess there will be no XP version? Why? Just so you can get users onto Win 7? Can't see any technical reason... We are stuck on XP due to our dinosaur-like corporate inertia. Disappointing. As for the UI, time will tell, will have to use it before passing judgement. It sure looks ugly. I liked the comment by #LeoDavidson about building all this UI stuff into the OS and letting it decide look and feel via themes, rather than every app reinventing the wheel.