My focus is on making software, coaching Agile/Scrum teams, and being a husband and father--definitely not on blogging--so please do not expect very frequent posts here.
I was recently looking into opening a CaringBridge web site, since I have a special needs daughter with an undiagnosed genetic syndrome. Trying to sign up, I encountered this page:
As an aside: do they even want men to sign up for this site? Pink and hearts and lowercasing and round fonts and flowers and puppies and rainbows pervade this site, on this page and other pages. But I digress.
More importantly, notice the form in the screenshot above. I was somewhat puzzled as to which options to choose. Hmm, myself or someone else. Am I creating an account for someone else, on their behalf, or am I creating an account site to benefit someone else, but it is my site? All I am prompted with is “who is it for”? I decided it was for my daughter—it is for her benefit, but not for her personally to use.
That was a pretty easy decision, but then I’m confronted with the first name/last name fields. Do I type my name or my daughter’s name? Again, the direction is ambiguous. I started typing my name, presumably because I’ve done this before on hundreds of web sites. It makes sense to me that I would perhaps type in my daughter’s name in a later step. However, a few clues told me otherwise—the fields are indented under “someone else”, and the following field is “enter your e-mail”, making me guess that the name fields are not asking “enter your name”. Also, the submit button (properly left-aligned but improperly indented) is labeled “preview site”, telling me there relaly is no step 2 (despite the 4 numbered circles listed at the top) and it would only make sense to put my daughter’s name on this field. I entered her name and was able to get the preview of my site. My guesses were right.
The design of this page forgot Jakob’s Law of the Web User Experience: people spend nearly all of their time on other web sites, not yours. It was only a small gaffe, and the page contained enough clues for me to figure it out, but how many hundreds of users had the same confusion I did?
Incidentally, we also see that we should serve your target market first (here, moms) but don’t alienate your largest secondary market (dads) in the process.
Hat tip to Kamran Ayub for the “Experience in the wild” idea. Others have done this a lot, but I was just reading a few such posts from his blog. Thanks, Kamran!
The old Team Explorer in VS2010 (right) was simple and got the job done without a lot of finesse. It really was nothing more than several aspects of TFS shoehorned into a tree view, grouped by Team Project.
Totally separately, the old Pending Changes window (below) offered some nice features, such as filtering, conflict resolution, TFS work item association, and undoing changes, as seen below.
(You only use these windows if you use any aspect of TFS; if you are avoiding TFS at any cost, you can skip the rest of this article.)
The new Team Explorer (right) has several rather major improvements. Here are the new features that I notice, with a few screenshots so you can visualize these new features.
- A new Home view summarizes everything important and provides links (rather than tree branches) to each team-related functionality.
- We now work on one Team Project at a time, changed easily by the select list next to the “Home” title. This is a great way to avoid wasting screen real estate.
- Web-style navigation is provided, with Back, forward, home, and refresh buttons.
- A feature I love is a project-global work item search, right there on the home view. So often one or two words (or a work item number) will let me find the task or story I need. No more do you need to go to the TFS Web Project Portal to search by work item number!
- The search supports several special terms—helpers for which are in the drop-down. For example, T:"Task" will limit your search to tasks only.
- A link to Pending Changes are shown with a link to the Source Control Explorer. No more drilling-down to browse Source Control—it’s right there on the home page!
- Work Items, Builds, Documents, and Settings work much like in VS2010
- There is a link to the Web Access (TFS Web Project Portal) right on the home screen.
- The Pending Changes section (below) is all new and built-in in the Team Explorer, totally replacing the old Pending Changes window.
- Again, you can change team projects right next to the “Pending Changes” title.
- A workspace select box is immediately below that.
- The Check In, Comment, and Shelve controls are easily available.
- Lesser-used actions (find shelvesets, resolve conflicts, undo all, manage workspaces) are hidden in the “Actions” select control.
- We have two separate sections of included vs. excluded changes. This is a much better paradigm than having to fiddle with checkboxes in one big list. Simple text controls are provided to manipulate these lists.
- A simplified way of adding related work items is here; the default direction is to simply drag the work items in to a drop target. This makes a lot of sense to me, as I have to look up the item anyway, and I probably have it open in a different window. If you prefer to do it in this window, you can—either by looking it up or by typing in an ID.
- Finally, specify reviewers in the notes if you are using the TFS reviewing system. If not, just collapse this section and ignore it.
- The Work Items section (below) is not substantially different than in Visual Studio 2010. A few differences:
- There is a “My Favorites” drop target for you; queries dropped here will give you a summary of the work items in that query.
- A handy “New Work Item” control at the top seems useful.
New in the Builds
- The most recent builds with their red/yellow/green status
- A drop target for My Favorite Build Defintions, also with a summary
- A quick filter/search box.
All in all, these are some very nice and unexpected feature enhancements here in the Team Explorer window. I hope they make you more productive!
I’ll be blogging just a little bit about some of the new features of Visual Studio 2012 that I notice as I use it.
Take a look at the new Test Explorer window.
This is a much simpler, robust interface than was available in Visual Studio 2010. By default, it provides you with groupings of tests by disposition (failed, skipped, passed, not run). Rather than having to open up a new window to investigate the cause of a failing test, the same info is shown on the right. Other nice touches include:
- A progress bar that turns red when something fails
- A compact display of elapsed time for each test
- Run all tests with one click when no tests have been yet run
- Run failed tests, skipped tests, or any of several common groupings from the toolbar
- The ability to right click and run a single test, multiple selected tests, or a group of tests
- Toggle “Run tests after build” so that the tests will run automatically
- Filter tests by a search term
- Tests run faster than in VS2010
- Previous test run’s results remain as greyed-out while the current test run is running
- Group test results by duration (really handy for focusing on improving the slowest tests)
- A red-yellow-green summary of all tests
- No more “Exceptions has been thrown by the target of an invocation” errors (I hope!)
These features are all new since VS2010. This new window will totally replace both the former Test Results and Test Runs windows for me. I’d expect this window to be open early and often throughout the development experience. The test Explorer is docked left by default, but I’ve moved mine to the bottom as seen in the screenshot below. Enjoy!