Sneak peek of Visual Studio 11 and .Net 4.5 (To be released, 2/29 and there&#39;s a whole new look and feel, Metro Like and Go Live too! It&#39;s almost a new VS!)

Jason Zander's WebLog - Sneak Preview of Visual Studio 11 and .NET Framework 4.5 Beta

Today we’re giving a “sneak peek” into the upcoming beta release of Visual Studio 11 and .NET Framework 4.5. Soma has announced on his blog that the beta will be released on February 29^th! We look forward to seeing what you will build with the release, and will be including a “Go Live” license with the beta, so that it can be used in production environments.

Visual Studio 11 Beta features a clean, professional developer experience. These improvements were brought about through a thoughtful reduction of the user interface, and a simplification of common developer workflows. They were also based upon insights gathered by our user experience research team. I think you will find it both easier to discover and navigate code, as well as search assets in this streamlined environment. For more information, please visit the Visual Studio team blog.

In preparation for the beta, today we’re also announcing the Visual Studio 11 Beta product lineup, which will be available for download next week. You can learn about these products on the Visual Studio product website. One new addition you will notice is Team Foundation Server Express Beta, which is free collaboration software that we’re making available for small teams. Please see Brian Harry’s blog for the complete announcement and more details on this new product.

..."

Somasegar's WebLog - The Road to Visual Studio 11 Beta and .NET 4.5 Beta

Today, I’m excited to announce that Visual Studio 11 Beta and .NET 4.5 Beta will be available in just a few days, on February 29th, 2012. These releases will be “go live,” meaning they will enable usage in production environments.

The Visual Studio Blog - Introducing the New Developer Experience

"In this blog post (and the one that will follow) we’d like to introduce a few of the broad reaching experience improvements that we’ve delivered in Visual Studio 11. We’ve worked hard on them over the last two years and believe that they will significantly improve the experience that you will have with Visual Studio.

Introduction

We know that developers often spend more of their time than they would like orienting themselves to the project and tools they are working with and, in some cases, only about 15% of their time actually writing new code. This is based on observations we’ve made in our research labs and observations that other independent researchers have made (for example, take a look at this paper). Obviously you need to spend some time orienting yourself to your code and tools, but wouldn’t it be good to spend more time adding new value to your applications? In Visual Studio 11 we’ve focused on giving you back more time by streamlining your development experience. Through thoughtful reduction in user interface complexity, and by the introduction of new experience patterns that simplify common workflows, we’ve targeted what we observed to be three major hurdles to developer efficiency.

The problem areas we targeted are:

Coping with tool overload. Visual Studio provides a large amount of information and capabilities that relate to your code. The sheer breadth and depth of capabilities that Visual Studio provides, at times, makes it challenging to find and make effective use of desired commands, options, or pieces of information.

Comprehending and navigating complex codebases and related artifacts (bugs, work items, tests etc.). Most code has a large number of dependencies and relationships with other code and content such as bugs, specs, etc. Chaining these dependencies together to make sense of code is more difficult and time-consuming than it needs to be due to the need to establish and re-establish the same context across multiple tools or tool windows.

Dealing with large numbers of documents. It is very common for developers to end up opening a large number of documents. Whether they are documents containing code, or documents containing information such as bugs or specs, these documents need to be managed by the developer. In some cases, the information contained in these documents is only needed for a short period of time. In other cases documents that are opened during common workflows such as exploring project files, looking through search results, or stepping through code while debugging are not relevant at all to the task the developer is working on. The obligation to explicitly close or manage these irrelevant or fleetingly relevant documents is an ongoing issue that detracts from your productivity.

Developer Impact

...