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:

mercurial status

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

diff list

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

diff 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?

  • What tasks will user perform with the file list? Sep 3, 2013 at 19:36
  • @AlexeyKolchenko They will be able to click on each change and display the "diff" (similar to source control). Sep 4, 2013 at 8:48
  • So the main interest area is files which were changed? Then you could organize the list as foldable tree and display modified branch unfolded initially. Sep 4, 2013 at 9:30
  • Well - "changed" includes Added, Modified and Deleted. So the first "changed" file would be selected - it could be an Added file. Also, the problem with a collapsed tree is that the information isn't directly available; they have to click to open each section. Sep 4, 2013 at 11:48

3 Answers 3


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.
  • Great points. And I agree with "not making users think". What do you think about @MichaelLai's answer about the mental model of working with individual files (but still sorted by status)? Each name is clickable to figure out what changed. For added and deleted, we just display the new and old file respectively. With modified, we display a side-by-side view. Also, what about the issue of a longer grouped list? For example, if a file is in the Modified group but near the bottom, is there difficulty in having to look up the name (rather than a hint beside)? Sep 4, 2013 at 11:59
  • My experience is that the mental model is not based individual files. Users shouldn't forget the group as they will typically approach this in a top-down approach; the group doesn't change until you see the heading of another group. Like you read articles online and still remember the heading though it is out of view.
    – Izhaki
    Sep 5, 2013 at 11:19

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.

  • Thanks - what do you think of having the users learn about each state? I agree with the mental model of working individually with each file (you click on each name to get the details). Sep 4, 2013 at 11:53
  • Taking this line of thought further, what links can you make about the state of the file to what the users can or cannot do with it? You have used different letters and colours to distinguish between the groups, perhaps something different in the action/interaction can help to reinforce the association further? I think what Izhaki said about users being able to pick things up quickly is true as long as there are not too many categories. In learning processes, reinforcement is always important, and the more often you can do it early on the better.
    – Michael Lai
    Sep 4, 2013 at 22:07

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.