Just watched the sneak peek video:
They have desaturated IDE chrome UI so that it is mostly monochrome now (i.e. no colors in the toolbar buttons), with occasional splashes of Metro-nesque deep blue colors, and I find it the most successful Visual Studio UI redesign ever.
First, it is stylish. Second, it channels the focus on the colored source code.
Unfortunately, they seemingly haven’t changed a thing in how the source code is colored, which is pity. Source code colorizer developers seem generally to believe being solving the classic computer science problem of “how many colors do you need to paint a map” and use arbitrary well distinguishable colors. The UX aspect of colorized text is ignored. As a result, one can try to enjoy the source code mostly consisting of bold red text with some lighting blue islands in there.
Another thing I liked was a slight improvement of TFS usability for those who use Scrum. The previous TFS UI, known as Team Exporer, was looking like just some random enterprisey piece of shit. Visual Studio never gave it enough screen estate to look reasonable so that you were forced to scroll and to change the window sizes constantly and a lot of times, even I you just wanted to accomplish a very simple task. Besides, it was unbelievable overcrowded with various text boxes and drop downs, most of them being never used in any company of any size and with any process whatsoever, except of perhaps some teams inside of Microsoft.
So, now, in Visual Studio 2011, they have liberated the TFS UI and put it into a browser. Entering a new sprint item takes typing its text and hitting Enter – exactly the same amount of interaction the best tools in this area support (I mean FoxBugs). Adding tasks to the sprint item is more complicated than it has to be and is not polished enough. For example, I’ve found it funny how the presenter was himself not aware of a usability issue, routinely skipping with a quick double-tab the iteration drop-box when entering a new task (0:36:49 in the video).
In general, when I look at the new task dialog, the worst memories of the Team Explorer go through my mind, and I can’t help but ask:
- Why this warning “The field ‘Title’ cannot be empty” on the top of the form? It is wrong on so many levels:
- Reading this warning even before I had a chance to enter anything in the title field insults me. It really does.
- This message doesn’t have much value in informing the users how this form works. Users are supposed to use it several times a day, in all sort of circumstances, so that they will quickly learn how to use it and will know even more about it than the guy who has developed it. Because this guy only knows how it is supposed to work, and the users know how it really works.
- There are bazillions of web sites in the Internet having a form, and absolutely most of them (like, 99.9999%) indicate obligatory fields directly in there (by using a star, or a less bold color for optional fields). Why not follow this practice?
- Isn’t the title field actually the only one obligatory field in this form? If it is, why do they need to use a validation framework producing this very robotic, inhumane wording of the message, instead of just checking it with a single if-statement and printing a handcrafted message?
- The message is technically wrong, because, well, the Title field can in fact be empty. If anything, it must read “You probably don’t want to create a task with an empty title” and appear only after the user hits Save.
- Why having users to read anything at all? Just mark the title field red. Your users are software developers. They do really know, what it means.
- Why the title field doesn’t have a title? All other fields have one.
- Why do we need an iteration drop-box just below the title?
- Isn’t the description what is the second-important field after the title, so it must be directly below it?
- Do we want to have sprint items spanning across the sprints, or what is the other reason for the possibility to set the iteration on the task level?
- Even if we want to enter iteration on the task level, is a drop-box the best possibility? Or perhaps just a check-box “not in this iteration” would suffice to move the task to the next sprint?
- Why do we both use words iteration and sprint? Can’t we just agree once what software process we’re using and configure TFS so that it uses consistent wording everywhere?
- Status and Details are split into two columns. Sometimes you have to do it, if you have a lot of information and not enough screen real estate. But in this case, why can’t we just scrap a lot of fields? This is a form to enter a new task, not to edit existing task, right? So, for a new task, we for sure don’t need the fields State, Reason, Blocked, Activity, and History. Let’s see if we can remove even more fields.
- Backlog Priority. The same question as with the Iteration. Do we want to have tasks with a different priority that the corresponding sprint item, and why? Even if we really want, why not implementing the priority by using drag and drop just like they can do it with sprint items?
- Area. This is something I haven’t understood in TFS and still refuse to understand. I mean, why do we need to have two trees (the iteration tree and the area tree) if we can live with a single, combined tree? Well, OK, if your business is to develop a leading desktop and server operating system deployed everywhere in the world, your component and iteration structure might become so complicated that this would require splitting these two fields. But Microsoft, there are really other companies who develop software using the Microsoft Ecosystem. And most of them (like, 99.9999%) never ever develop a product that would have more than a couple of iterations and components in the same TFS repository. Besides, in the most scenarios, the person(s) assigned to the task uniquely identifies the area, because, normally, it is a good idea to clarify responsibilities in the team even before the first sprint planning starts, so that everybody knows that, say, Alice is the database gal, and Bob is the frontend guy, and Chris oversees the REST web services. So, let’s make an uneasy decision and remove the area field and see if the percentage of those who disagree can be ignored!
- The “Links” functionality seems to be implemented in the same way as in the Team Explorer – each link is an item in a list box, and you have to push a button every time you enter a link to add it to the list. Yikes. Let’s just allow users to paste links into the description field, and recognize and summarize them in a list automatically. Even Facebook can do that.
- The “Attachments” functionality has a similar issue. Just let folks to copy the image, PDF, DOC or whatever file they have and paste it into the description.
- The “Description” field. There is no rich text formatting there, is it? Why? You have to be a Byron to compose a really expressive description without usage of typographic tools and formatting.
- The buttons below the form. TFS is a product targeted for Windows developers. If there are such persons who are Mac or Linux users but still use TFS, God will surely bless them, but let’s concentrate on our core public. And in Windows, these buttons are always called “Apply”, “OK” and “Cancel”. Always. Ever.
- And last but not least, the Assigned To field. I don’t know how does it exactly work in there. In the Team Explorer, I couldn’t select several assignees. I was constantly finding myself in a situation where a task can be done by anyone of several developers, and wanted to leave it up to them. The one who cares most should pick up the task. So I ended with assigning the task to a dummy user “nobody” and communicating with the affected coworkers offline.
Gee, that was a lot of harsh critique. I’m looking for someone who can teach me how to criticize in a less aggressive way…
Anyways, here is what I would propose instead:
I push a button to create a new sprint item. A window with Microsoft Word like UI opens up.
In addition to the usual text styles, there are styles to represent sprint item title, task title, a person and so on. The current text style is preset to be sprint item title. I type the title and hit Enter. The text style changes to description. I type the description. Now, when I type “@Damian”, the window automatically recognizes it and changes the text style to person. Similarly I can enter a task title.
Generally, I communicate with my team in the same kind I would use if I was writing an E-Mail with tasks. When I hit the Save button, the following happens in the background. TFS parses each sentence. For each sentence containing text with task title style, it creates a task and assigns to it all the persons mentioned in the same sentence. The persons get notification links leading to this sprint item (not to their particular task). The tasks are automatically assigned to the same iteration the containing sprint item is assigned to.
I can right-click on a task title, and an overlay (in the same look as the overlay in Microsoft Word) appears near it, allowing me to enter the remaining work hours for it and change its state. These changes are directly represented in the text, for example by partially coloring the background of the task title, or by striking it through.
One way to reassign a task is by directly replacing the person’s name in the corresponding sentence. When I save the text, a history will be created for that change, and I can optionally enter a comment for it. I also can pass the ball by writing an additional sentence, mentioning the task and another person there. In this case, this additional person will be assigned to the task and will be notified.
If any of words can be recognized as Microsoft Exchange calender resource (eg. Meeting Room, Beamer etc), it will be underlined. If I click on it, Outlook will open with a meeting planning window. Me myself and all persons mentioned in the same sentence will be automatically added to the meeting, and the sprint item and task titles will be put into the subject.
I believe, this UI has several advantages. For the end users, it is plainly more ergonomic and allows for a more humane communication at the workplace. For the decision makers, it looks not less enterprise-ready than the original TFS interface, because it just capitalizes on (and integrates with) existing enterprise-grade tools like Word and Outlook. For Microsoft, it allows to additionally target startups and middle-sized companies still working “in startup mode” because of much less bureaucracy in the UI. And, just in case Microsoft would like to support other big companies allowing them to develop software as huge as Windows using TFS, they can still hide somewhere in the context menu the “Properties” menu item, opening the full property sheet of the corresponding task. But, frankly speaking, I would rather not do even this and allowed to access the full scope of the task object by using a command-line tool like tf.
But that’s another story.