TFS Version Control and more .. : Design

Feature Design and Simplicity- Part 3

mrod — Tue, 22 Apr 2008 00:46:43 GMT

I have gotten some emails by readers about this series so I thought to continue the momentum and talk about the next law: Time.

It is no secret that "Thin is in" with customers and that there is nothing more frustrating and at times upsetting than waiting for an application to do some task. TFS has worked a lot on server performance in order to minimize this wait time for our customers and we continually get better. Just recently, we discover a way to improve unshelve and we think we can get a pretty big boost on performance which has us really excited.

On the other hand, sometimes doing back end work is not enough to improve the perception of time and you really have to spend time on the design to make the experience better for our users. Take for example the branch visualization work that we are doing (specs will be publish soon enough for you guys to enjoy).

In Branch Visualization we try our hardest to remove all of the information we don't need and also minimize the experience to excel at the scenario the user is leveraging the visualization for. This allows us to remain very thin and reduce any wait time the user will experience. In the first phase this is not implemented but our second phase will bring those design elements in. The solution in this case was simple, take the navigation of the branches and marry it with the target selection so the user discovers the answer one at a time, to the best of approximations. That is a lot better than sending the server 20 targets, which you may not need, and waiting for the server to come back with the answers.

Here is a screenshot of what it might look like:

So always remember to optimize for time because at the end "savings in time feel like simplicity" for the end user.

- mario

Slick Design

mrod — Tue, 15 Apr 2008 15:55:23 GMT

We Program Managers are always looking for the latest technology, trends and designs that will be enable us to deliver our vision of the feature to our users in its simplest and most powerful form.

I was doing some research on tilt UI and physics UI and I came across this site, which in my opinion is one of the best implemented:

http://www.whitevoid.com/application.html

Now clearly this cannot be used to navigate your source tree, unless it is very small, but you can extract a set of design ideas from it. Let me give you some of the examples that I think make this implementation a good one:

Simplicity - there is no application junk hanging around the site, the content is the UI and nothing distracts you

Color - the background color plus highlight/ illumination centers you on the UI and since it is not static (moving elements) the navigation feel immersing. In regards to colors, I think the color and mood of a UI is one key element of a great looking application

Annotations - The orange callouts (Hot, 20) are a great simple way to get your attention while not distracting from the content. The help content that appears (zoom in, open) are also a great way to tell you what to expect from the click action.

So there you have it, a slick UI with lots of good elements that we can apply to our applications.

Feature Design and Simplicity- Part 2

mrod — Sat, 29 Mar 2008 03:27:46 GMT

Yesterday we discussed the first simplicity law: Reduce and went over one example of its use within our feature development.

Today let us talk about the second law: Organize. Organization is a word that I personally dread since I cannot seem to keep my house, my car or my office organized long enough for me to reap the rewards of its simplicity. Last year, I took the Dale Carnegie course and one of my two-minute speeches outlined a plan to get my office organized. The plan included doing something small every day, either throwing a paper out or stacking one of the books, etc. I have to admit that after four months, my office looks a lot better but I think I have one more year before it is truly there. Yes, it takes that much time to organize an 8x10 room.

In software and feature design this law is mainly about asking the question: what goes with what? One of our main organization culprits today is our context menu, which seems to grow with every release. In one hand it makes sense, we got more features, more integration points and the user always wants to have these features accessible; the context menu seems like a perfect place. On the other hand, you end up with a menu with more than 25 options that is almost the entire size of the document window.

How do we balance these two customer needs, how do we embrace simplicity through proper organization? In my opinion the answer lies in combining groups of things that go together (what goes with what?), and/or abstracting things to a higher level in order to combine items or functionality within one concept. A very recent example that combines both of these solutions is the Office Ribbon. Yes I know, you either hate or love the ribbon; but since I am in the love camp, I am going to side with “it was a great solution”, even if you cannot find the Print button at times. The ribbon provides an abstraction by using tabs that speak about the properties or actions of the document and its artifacts. The tab Insert is really an abstraction of all of the functionality that word provides you for this action and inside this tab, you find the groupings by Pages, Tables, Illustrations, etc. Essentially Insert became a first class action in the ribbon.

When applying this concept to TFS and Version Control it results in the abstraction of the branch concept in order to provide a lot more functionality around these objects, which today are just folders. The abstraction will allow users to exercise functionality that before would be scattered across the product, and hence unorganized. In the grouping front, we will be looking at our context menu and rethinking the experience in order to come up with the right groups and user interaction.

Summarizing, use abstraction and grouping effectively to organize the functionality of your design; they can be very powerful!

Feature Design and Simplicity- Part 1

mrod — Thu, 27 Mar 2008 21:35:00 GMT

As a Program Manager an integral part of our job is designing a great user experience for our customers. One of the most important factors in the design is simplifying the experience so it is ease to use and easy to implement.

As you know, simplicity is one of those things that is very easy to talk about but extremely hard to achieve. I remember spending a lot of days and nights just thinking of a way that I could bring a given feature to the customer without upsetting him because the prototype had him clicking through three modal UI screens to get the task accomplished. Ok I am exaggerating a little bit here, but seriously, look at our old conflict resolution experience and try to resolve a rename version conflict in less than three clicks, aha you can’t.

In my quest for simplicity I came across John Maeda’s Laws of Simplicity and I liked them so much that I wanted to share them with you: (http://lawsofsimplicity.com/category/laws?order=ASC ). Today I will discuss its first law Reduce, in which he states that “the easiest way to simplify a system is to remove functionality”. Wait let’s read that again, to make version control simpler I just have to cut features? Well that does not work too well for me if I want to keep my job. In fact, a big part of it is to make sure that the features our customers want make it into the product and not out of the product. Then, how do we apply this to feature development?

For me, this law is all about the last sentence and specifically the statement “When in doubt, just remove”. At the time I read this law we were designing the new resolve experience (Resolve Spec) and it gave me an opportunity to challenge myself on the features/improvements we were introducing. My approach was simple if I doubted that it provided strong value to the customer then I would remove it and try to come up with another way to integrate the feature. For example, at one time we had in the design a progress indicator that would tell you how far along you were in your conflict resolution. This works great when you are sitting down and resolving all of the conflicts at once without checking in, but the reality is customers not always work this way. They have distractions, they work in waves and at that point we were not able to provide the value we wanted to all of our customers so we just removed it. That was a good decision!

Next time you are sitting at your desk late at night trying to make the design work just follow this rule and challenge all of the functionality presented to the user in that screen. Can you cut anything out and still maintain the value? Ohhh I see some of them that are doubtful, go ahead and cut it, you will fell better at then end and your product will be yes “simpler”.

- mario