Comparing and merging user interface revisions from multiple people

Question

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.

Answer 1

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!

Answer 2

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.

Answer 3

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

• JavaScript Diff Algorithm by John Resig, creator of jQuery JavaScript library: http://ejohn.org/projects/javascript-diff-algorithm

• Slightly different version of the above implementation: https://github.com/ndarville/jsdiff

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.

Answer 4

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.