Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

How can I compare, merge, and prevent conflicts between UI changes made by different members of a multi-person UI development team?

Context for this Question:

Visual diff and merge tools like Meld are useful for comparing versions of textual software code. They help people responsible for the code understand what has changed and determine if it is safe to accept changes into the final product.

I recently used Meld to merge UI changes from two front-end developers and found it very challenging. Changes were spread across multiple files (style sheets, templates, dynamic JavaScript) and it was hard to visualize how those changes would interact to present a UI in a web browser.

The task was further complicated by the fact that implementation changes don't necessarily mean that the user experience will change, since the UI may appear unchanged from an end-user perspective. For example, one can use a bold tag, strong tag, inline CSS style, a syntax like Markdown, or even JavaScript to boldface text on a website and any of those solutions may result in an equivalent UX. Yet, to textual diff & merge tools it would appear that a change had been made.

share|improve this question
    
so you want to be able to take commits A and B from a repo, then compare the visual and UX changes between each rather than the code changes? –  Toni Leigh Jul 25 at 17:26
1  
Correct, at least ideally. I'm looking for a way to handle side-by-side comparison similar to what text comparison software provides. –  Michael Hogan Jul 25 at 17:29
    
However, I don't want to ask for tool recommendations. I'm more interested in getting advice on overall approach from people who have been in this situation and found a way out of it. –  Michael Hogan Jul 25 at 17:49
    
i've not done this before, it's a new idea to me, but assuming you are familiar with distributed version control, modular css, MVC patterns and best practices within these areas I think I can suggest some ways I'd approach the problem –  Toni Leigh Jul 25 at 17:55
    
btw, KDiff is by far the best Diff program I've used, does entire directory structures as well as going to character level rather than just line, I believe it's recommended by Mercurial :-) kdiff3.sourceforge.net –  Toni Leigh Jul 25 at 18:02

4 Answers 4

up vote 1 down vote accepted

The simplest way to do this that I can think of would be to pull (and compile, possibly) the two different commits into two different development environments then compare the parts of the interface effected by the commits.

You could take this a step further and automate the process, interfacing with a commit history and triggering using batch files or similar a set of operations that pulled two different given commits and set them up for review. This would be advisable if you were doing this often and would also mean the process could be put into the hands of someone less technical.

Taking the web as an example, as you do in your question (though the principles could well be applied to other development situations) with well written, modular css and views you could set things up to compile and display just the parts of the interface effected by the commit.

Another thing you could do would be use javascript to take commit hashes and add those as classes to html snippets / views where things had changed in order to mark them as changed. i.e. look at every view that has changed between two commits and add a class to every element in those views. You could cross reference the css or javascript to see what elements are targeted by the changes in those files and feed that back in to make the visual feedback richer, i.e. 'this element had an event bound' or 'this element had a class added'. This would help you focus in on the changes that had had an effect.

Merging would be done in the usual way, in the version control, once a prefered interface was selected.

You would benefit massively if your developers to be making very good commits, i.e. atomic, contained pieces of development rather than a days work, 10.6 tasks and a message like 'changes, sorry, I'm bad'. Commit messages would need to be very well written so you could see which part of the system to target with whatever method you used and tasks would need to be carefully distributed amongst developers so they could work efficiently on one thing then commit and push.

You would need to use branching too so that sets of commits could be more easily divided into the tasks that they represent as a whole. Then compare between the branch heads or the branch heads sequentially with the master head.

There's going to be some pretty sophisticated programming involved in making this work well, it's no mean feat, good luck!

share|improve this answer
    
Thank you. For the moment, I think this is the best answer. With virtual machines it becomes slightly easier to accomplish. It still seems like there is definitely an opportunity here for a more friendly system in the future. –  Michael Hogan Sep 15 at 2:46

This is something that I have attempted to do with developers, but I find that the best way to understand the changes to the UI is to have a good system for the development of applications, which means following a standards document like the Atlassian Development Guide or Google Material Design Guide.

What I find is that if developers don't build applications based on a set of standards, then any comparison is rather meaningless in the sense that if they build to different rules and structures and end up with the same look and feel, then you will not be able to manage the code well because the variation is too great.

On the other hand, if you can get the developers to understand and follow a guide, then the differences will be minimal and you can make meaningful comparisons.

As for representing the changes, I believe that a visual representation is the best, even if some of the differences are just on an interaction and not visual level. I place version numbers next to each UI iteration, which is also a common way of illustrating how some decisions just result in very similar UI designs being tweaked too much.

share|improve this answer

I think that the following resources might be useful for solving the problem:

While the above-mentioned resources certainly don't represent the solution, I believe that they might serve as a foundation, which the solution for the problem can be built on.

share|improve this answer
    
The op is not asking about text diff but about visualising diffs in the resulting interface, ie side by side comparison of the resulting interface rather than the code –  Toni Leigh Jul 31 at 6:30
    
@ColinSharpe: I understood that. This is the reason why I emphasized in my answer's last sentence that the resources I've mentioned "don't represent the solution", but "might serve as a foundation" for the one. Therefore, I believe that my answer delivers some value, especially considering absence of the COTS solutions for the problem. –  Aleksandr Blekh Jul 31 at 7:09

For example, one can use a bold tag, strong tag, inline CSS style, a syntax like Markdown, or even JavaScript to boldface text on a website and any of those solutions may result in an equivalent UX.

This isn't true at all. It may result in an equivalent visual, but they certainly aren't the same thing. And this can cause plenty of problems...be it with JS looking for particular markup, accessibility standards, SEO optimization, etc.

Ideally, you shouldn't have to do this too much on the code-check in side. This should happen on the pre-coding side. UI development should be following some defined standards. Things such as:

  • using a framework
  • pulling from a component library/pattern library
  • obeying project markup standards

Combined with, ideally, plenty of inter-team communication.

And, perhaps the biggest of them all:

  • regular maintenance

Multi-member UI teams that span many releases inevitably will end up with inefficiencies in their front-end code. This is natural and, ideally, time is spent over various periods to go back and clean things up as a group. In an agile environment, for example, it'd be ideal to commit a few sprints a year just to code cleanup.

share|improve this answer
    
I disagree with your statement that "This isn't true at all." My point is that the visual look can be accomplished many ways. Yet, I want to use version control and diff tools to ensure a consistent approach is taken throughout an application. If the team decides to use element classes to apply styles via an application wide CSS file, then (for maintainability) it is essential to be able to tell when a code change deviates from that convention even if the page looks visually the same. –  Michael Hogan Sep 15 at 2:52
    
@MichaelHogan there's a big difference between 'equivalent visual look' and 'equivalent UX'. Yes, there are multiple ways to come up with the same visual look--no, they won't necessarily produce an equivalent UX. This is an important distinction. Your idea about using diff tools is a good thought. But it's going to be really hard to do. As there are often good reasons to make something visually the same, yet coded in a different way. And vice versa. It's all about context and, unfortunately, diff tools have no care about the context. –  DA01 Sep 15 at 5:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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