You’ve seen snippets of the new Team Explorer in previous posts I’ve done on version control improvements. In this post, I’m going to focus on the new Team Explorer experience, talk a bit more about what overall changes we’ve made and why.
You’ll recall that the Team Explorer window in TFS 2010 and before is a pretty standard tree control – it looks a bit like the solution explorer. For a long time now, we’ve felt that the model that everything we wanted to do in Team Explorer would have to fit into a tree was overly constraining. When I built the Team Members Power Tools a couple of years ago, I very much wanted to have a richer way to show people, including pictures, etc. – but the Team Explorer window didn’t support it, so I just added another tree node. As we started looking at some of the TFS 11 features we wanted to create, like code review, it became clear that we needed a new approach. An alternative, of course, is to just keep adding new tool widows for everything. The problem is that we already have quite a lot of them and we get feedback that people are overwhelmed with them.
We decided to experiment with a new kind of tool window. I tool window that is, in essence, a frame that houses many other tool windows (or pages, we call them) and provides a browser inspired navigational model around them. We felt this would give reasonably easy access to the breadth of functionality while not polluting the IDE with 10 more tool windows.
As we entered the design, there were other problems we wanted to tackle as well. They include, but are not limited to…
- Move to modeless experiences in more places. All the modal dialogs we had for presenting information was creating ugly stacked UI.
- Move to more async experiences and have a common way to display progress/cancelation.
- Improve startup/connect speed by not populating all the Team Explorer info (documents, reports, work items, builds, …) on startup, but rather loading them on demand.
- Streamline common scenarios.
- Give Team Explorer a fresher look.
- Provide much richer extensibility.
- Enable a more scenario oriented organization rather than the artifact classification we’ve had for a while.
To refresh your memory, here’s a picture of what the Team Explorer looks like in TFS 2010:
Meet the Home Page
The new Team Explorer in TFS 11 uses page navigation to provide a lot more functionality in a single tool window. The “root” of the page navigation is the Home page and is quickly accessible via the “little house” button on the tool bar. It contains links to most of the pages and links to the most common actions associated with those pages. You’ll also see forward and back buttons to navigate through the stack of pages you’ve visited and a search box you can use to search for work items.
The search box work similar to search in Outlook or Team Web Access (in 2010). In this example, I’m searching for work items with the word "Create" in the title or description that are currently assigned to me. The drop down on the search box gives you some options to filter by specific fields. You can double click on a work item to open it, or you can use the "Open as Query" link to open your search as a full work item query where you can further refine your criteria, export your results to excel, etc. The search feature only supports work items for now, but we’re hoping to expand on that in the future.
Managing Your Work
In TFS 2010, your workflow might have gone something like this:
- Open a solution
- Make some changes
- Find the work items (if any) associated with your changes
- Enter a comment describing the changes you made
- Check-in your changes
In TFS 11, we’re tuning that flow a bit. The "My Work" page gives you a place to review the work that’s currently assigned to you and keeps track of what you are working on.
Once you’ve decided what to get started on, you can use a context menu on the work item (drag and drop will be enabled in the Beta release) to mark them as "in progress."
Those two work items are now "in progress." Since you haven’t made any changes yet, you see a "Finish" link rather than a "Check In" link. In the Developer Preview, all that happens when you do this is that the work items are associated with your pending changes. For Beta, this gesture will also transition these work items to the next logical state in their workflow. For example, if you’re using the Scrum template, it would transition them from "To Do" to "In Progress" and that change would also be reflected on the web-based task board. Of course, you can also remove work items from the "In Progress" section using a context menu (for Beta, this would revert them back to their previous state).
Once you make some changes to your solution, you’ll see some different links.
When you have pending changes, you have the following options:
- Check in those changes,
- Request a code review of those changes, or
- Suspend those changes and your associated context to a shelveset
Let’s start with the last option first. You’re probably already familiar with Shelvesets which let you move a set of changes to the server and (optionally) undo them from your local workspace. It’s a really useful feature for setting work aside, migrating it to another machine or handing it off to a teammate. We’re building on that functionality for the Suspend feature so that is also includes your Visual Studio context (open solution, tool windows, bookmarks, breakpoints, etc.). Capturing all of your IDE state so that you can return exactly back to how you were can significantly decrease the cost of interruptions.
When you click Suspend, an in-line panel appears where you can describe your work before you actually Suspend it. If you’re concerned that the edit box is smaller than you’d like for this task, you’ll be pleased to know that it’ll expand horizontally with the tool window and it’ll expand vertically to accommodate your content (up to three lines at this width). When you click suspend, your changes will be moved to a shelveset (and undone from your workspace). You’ll see your suspended work in the Suspended section as shown here:
If you expand the newly suspended work, you’ll see the work items you were working on as well as a summary of the change you made:
The View Changes link will navigate to a Shelveset Details page where you can review the changes, the associated work items, etc.
Another awesome new feature of the work items in the new Team Explorer (particularly in the My Work page) is an “unread” indicator. If there is a work item assigned to you and it has changed since the last time you looked at it or is new – it will be bolded. This makes is really easy for me to stay abreast of any changes or comments on my work. I’ll show an example in the code review section below.
For the purposes of this walkthrough, let’s request a code review of our suspended work. If we click on the More link, we’ll get a pop-up menu where we can request code review for our changes.
On the New Code Review page, you can specify a reviewer, give your request a title, assign an area path, and enter an initial comment to let your reviewer(s) know what feedback you’re looking for. If you want to omit some of the files from your code review request, you can click the View Changes link to exclude them. When you’re finished, you can click Submit Request to create your new code review request and it will show up on your My Work page in the Code Reviews & Requests section. This is where you can check on the status of your request and navigate to the code review details to see what feedback you’ve received.
If your reviewer(s) have configured their project alerts to receive email, they’ll receive a notification mail. In all cases, they’ll see the incoming code review request in the My Work page like this:
Double clicking on the incoming code review request navigates to the Code Review page where the Reviewer can see the details of the request:
From here, the reviewer can decide to accept the review request by clicking the Accept button. Alternatively, they can choose to decline the review. If you want to hand the review off to someone else, you can simply expand the Reviewers section, add a the appropriate reviewer, then Decline the review request. You might also want to add a comment to the review to let the requestor know why you’re handing the review off to someone else.
Reviewers can add comments to the review itself, to files included in the review set, or to blocks of text within those files. As described earlier, the comment edit boxes will expand vertically to accommodate the comment.
When the reviewer is finished commenting on the changes, they’ll click the Send Comments link to publish their comments. You’ll notice that the new comments here are shown in bold. When the reviewer is finished with the review, they can click the Finish button. Sending comments happens immediately and is available for others to comment on right away. You can actually even use this pretty much like an interactive IM conversation if both parties are online at the same time.
When finishing, you have some options to succinctly communicate the outcome of the review to the Requestor. If you’ve added at least one comment, then "With Comments" is the default choice. Alternatively, you can let the Requestor know that their changes "look good" and that you’re fine with them being checked in. The "needs work" outcome is a way to let the Requestor know that you’d like them to address your feedback before checking in. Of course, you can also communicate your precise intentions with comments in the review.
Once the Reviewer "finishes" the review, it will be removed from the Code Reviews & Requests section of the My Work page. For the Beta release, the Reviewer will have an easy way to bring up a list of recently finished reviews in case they want to follow-up on some aspect of the review. If you expect the Requestor to follow up with you regarding the feedback you’ve provided, you can leave the Review unfinished.
Once the Reviewer sends comments on or finishes the review, it will appear as unread (bold) in the My Work page:
The Requestor sees that the Reviewer has finished the code review and has provided some feedback.
Before addressing the Reviewer’s feedback, the Requestor will Resume the suspended work. The Resume command is available on the context menu for the suspended work. For our Beta release, you’ll also be able to simply drag the suspended work to the In Progress section to resume your work on it.
Resuming the suspended work will unshelve the changes to your workspace and restore your task context (the solution, open files, etc.) in Visual Studio. After addressing the Reviewer’s feedback, the Requestor will close the review and, in this case, indicate that it’s complete.
Now you’re ready to check in your changes. Clicking the Check In link takes you to the Pending Changes page (see Wrapping up TFS 11 Version Control improvements for more details on the Pending Changes page). After checking in, you’ll see a confirmation along with a link to your committed changeset:
We’ve added a lot of richness to builds in the new Team Explorer that wasn’t there before. We’ve broad forward some of the features from the Build Explorer so that you don’t have to open it for the common cases (like seeing the status of the build you recently kicked off). It doesn’t completely replace the Build Explorer, but it should definitely reduce the need to go to that window. We’ve also gotten a lot of feedback on managing large numbers of Build definitions. One of the top User Voice suggestions for TFS is to add “build folder” for organizing build definitions. We haven’t yet (and we’re not sure we will). We’re trying some other approaches that we think might serve as well and not introduce one more organizational hierarchy into the product. See more below…
The My Builds section shows builds that you’ve queued or triggered (e.g. continuous integration or gated check-in builds). The context menu for builds in this section offers the following commands:
The Requeue command is new. As you might guess, it lets you re-queue a particular build with the same build process parameters, etc. as the build you’ve selected. It’s useful in cases where the build has failed due to some environmental issue.
The All Build Definitions section gives you a list with, you guessed it, all of your build definitions (well, the first 100 actually). You can use the filter box to filter the list down to the one you’re looking for. It’s a quick and easy way to find the build definition you are looking for without having to navigate a large list. Further, you can identify a list of “favorite” build definitions. These are the build definitions you use more frequently and are always at your finger tips.
For your favorite build definitions, you’ll see the status of the most recent build along with the build history visualized as a color-coded histogram. Like the Build Summary view in TFS 2010, you can click on a bar in the histogram to navigate to the details for that particular build. Note that your favorite build definitions are tracked on the server, so you’ll see the same list from any machine you connect to your project collection from (including Web Access).
The Work Items page in the Developer Preview looks fairly similar to the work items node in the previous version. Maybe the biggest change is that now some actions are links in the page rather than having to use context menus for everything.
There are more capabilities coming in the Beta release (including server-side favorites).
We’ve worked hard to move long-running tasks to background threads wherever possible. There are still some cases where, due to interactions with the Visual Studio UI, we need to perform those tasks on the foreground thread, however. We’ve continue to improve performance since the branch for the Developer Preview was locked down and you’ll see those improvements in the Beta release.
In TFS 2010, the extensibility of Team Explorer was pretty limited. You could add a set of nodes to the tree control, provide a context menu for them and handle activation (double click) events. In TFS 11, Team Explorer has a much richer extensibility model. You can extend it the following ways:
- Add whole new pages to the navigation structure
- Add a new section to an existing page
- Add a top-level link to the Home page
- Add a secondary link beneath an existing top-level item in the Home page
In your custom Team Explorer page, we recommend that you organize your content into sections using our framework. But, you have complete control over the content and behavior of your page. Stay tuned for a future post on writing a new Team Explorer extension.