Should the state of each change be beside the file name or should files be grouped by state?

Question

I am working on an application that is similar to a source control tool in that we have a view to display the state of each change in a changeset. For example, with Mercurial, I can get the state of each changed file (displayed by a single character and color). By default, Mercurial also groups changes by status:

Here is the mockup we've made similar to Mercurial (each state character would have the name displayed in a tooltip):

Is this "better" than just grouping each file by status?

The users of our application are mostly non-technical. They most likely have never seen this type of "change state" interface before.

The advantages to using the abbreviations:

1. Less vertical space used.
2. Repetition of the state.
3. Once learned, there is almost instant recognition (similar to how programmers are trained with source control).

The disadvantage to the abbreviations:

1. The letters by themselves aren't entirely descriptive (one user we tested with said that M and D were not obvious).
2. Tooltip is required for discovery.

Has anyone created a similar interface for non-technical users?

Answer 1

What a fantastic question! As a git user, I couldn't help smiling when I saw your grouping proposal, thinking: "How come no one has thought of this before? This is soooo much better".

You have done a great job arguing the options. I'd like to challenge this thought of yours:

• Once learned, there is almost instant recognition:
  • There is instant recognition in the grouping option without learning.
  • Even with learning, you can't call the recognition instant, because first the brain has to recognise the 'A' and then link it to the word 'Add'. So it's a two-steps process rather than the one-step 'Add'. It's like saying that web designers see blue when they see 0000FF.
  • From a UX perspective you can start an argument with the words "Once learned" if there is also a slower option for "without learning". A menu item for save and the keyboard shortcut for the same command is an example. But if you have ever used VIM, you know how bad the experience can be before you have learnt how to use the application. Don't make users think; don't force them to learn.

Then in addition:

• The whole reason we are here is to enhance the user experience. One of the key question in evaluating interfaces is "Would this be clear to the user?". The M, A, and D provide a clear cut answer: "No". Imagine save buttons being labelled "S" and save as labelled "SA". It's all encoded stuff.
• From a visual design perspective, there is a bit of an issue with the status letters being in such close proximity to the file name. This can be extra confusing if file names has spaces in them.
• As a git user, I can tell you that when you look at this status report, your thinking is never "Has file X changes?", but rather "What has changed?". So there's extra rationale to sort these by status groups rather than alphabetically.

Answer 2

I think if the mental model for the user is to work with individual files, then perhaps the first option is easier because they can get the exact information at one glance (i.e. it is in one row), whereas in the second option they have to find the group first and then find the file (because of the physical separation of the two bits of information). If the mental model is to work with entire groups, then it makes sense for the second option because once the group has been identified then they can just work with all the files in the group.

Unless there are a large number of states, it shouldn't be a problem for the user to adapt to either design. But rather than asking the UX professionals, it is better to ask the users what they think (or just observe how they perform the task) and be prepared to make changes rather then design and forget.

Answer 3

I think the real question you should be asking is what the default grouping should be. From what you've described here, I see no reason why grouping shouldn't something a user can change to suit their preferred style.

Something to consider is the experience of the users. As they become familiar with the application, they will be become more expert, and start to look for ways to optimize their work. This is where a changeable grouping can become quite handy. The "group by status" option gives a clear indication of what follows, and is easy to understand for the novice user, while the "inline status" option will read faster to the experienced user. Once a user is comfortable with the application, they can switch (or not) at their leisure. They should be able to save their settings, so that they don't have to click a button or whatever every time they use the application.

However, regarding the "inline status" option, I think a better way to represent the statuses would be symbolic, rather than alphabetical. A '+' and '-' are universal symbols for addition and subtraction, and do not require learning new symbol mapping. Using these provides a natural map to our world, and makes adoption smoother and simpler. You might use a '~' for modified records, but whatever you choose, you've eliminated the extra load on the user by exploiting cultural constraints. It may seem as though you've only eliminated 2/3 of it (+, -), and for a handful of users, that will be true. However, for the majority of users, they will initially associate the modified symbol with "not + or -" rather than the symbol chosen, thus eliminating the need to learn it. After some use, they will "learn" the symbol itself with use.

However you do the inline statuses, include a legend. It may seem obvious one way or another, but make that information available, just in case its needed.

So to summarize, default to grouping by status. Give a option that is clearly visible to change the grouping style and allow this setting to persist for individual users. Use symbolic representations (+, -, ~) for your inline statuses, rather than alphabetic, and include a legend describing them.