What makes an effective UI for displaying versioning of structured hierarchical data

Question

Traditional version control system are displaying versioning information by grouping Projects->Folders->Files with Tree view on the left and details view on the right, then you will click on each item to look at revision history for that configuration history.

Assuming that I have all the historical versioning information available for a project from Object-oriented model perspective (e.g. classes -> methods -> parameters and etc), what do you think will be the most effective way to present such information in UI so that you can easily navigate and access the snapshot view of the project and also the historical versioning information? Put yourself in the position that you are using a tool like this everyday in your job like you are currently using SVN, SS, Perforce or any VCS system, what will contribute to the usability, productivity and effectiveness of the tool.

I personally find the classical way for display folders and files like above are very restrictive and less effective for displaying deep nested logical models. Assuming that this is a greenfield project and not restricted by specific technology, how do you think I should best approach this?

I am looking for idea and input here to add values to my research project. Feel free to make any suggestions that you think is valuable. Thanks again for anyone that shares their thoughts.

EDITED: To give more info, an average configuration item, take a method will be nested in about 6 levels (project->assembly->module->namespace->type->method, and more levels to navigate to child items within it) and this is consistently the case, not like in folder-file structure where you occasionally in some project has deep nested structure. When you have that many levels, tree pane becomes unusable to navigate. IMHO, Tree pane also less effective in this scenario to present overall structure of the system.

Answer 1

Rather than trying to select one presentation scheme for fitting n levels of informations in a GUI, why not let the user choose the right level of details he/she wants or needs?

Perspectives

Eclipse is one example (not the only one) allowing for the user to define perspectives.

Within the workbench the Perspective feature is used to control the visibility of items in the model and the user interface.
It controls what you see in the model (which project, folder or files) and what you see in the user interface (which actions or views).
These controls make it possible to navigate through and modify the workspace in a way which suits the user task.

Perspectives can easily be adapted for any kind of hierarchical information display.

Information filtering per task

Another effective way to display complex informations is to propose an effective filtering mechanism, based on the current task.
Each time the user switch to a new task, the various information trees display just the relevant information.

See Mylyn for instance:

Mylyn makes tasks a first class part of the IDE, integrates rich and offline editing for ALM tools, and monitors your programming activity to create a "task context" that focuses your workspace and automatically links all relevant artifacts to the task-at-hand.
This puts the information you need at your fingertips and improves productivity by reducing information overload, facilitating multitasking and easing the sharing of expertise.

Again, that can be applied to any kind of informations.

Answer 2

How about a variation on a stem and leaf plot?

http://en.wikipedia.org/wiki/Stemplot

This is a concept from statistics, but you could augment the traditional tree structure adding a list of versions to the right of each file in the tree. With proper alignment, I think this might be a visually expressive and usable solution. Something like this:

* Root Directory
    * Sub Directory A
        * File A.A     | 1 2 3
        * File A.B     | 1 2
    * File A           | 1 2 3 4 5 6 7 8 9
    * File B           | 1 2 3 4 5

The stem and leaf plot gives a visual indication of how many times a file has been revised along with quick access to viewing (editing, etc) and versions.

It is likely this would be just one view on the data. You would still be encumbered by the nested structure, but if you have to live with that, perhaps this would help.

Answer 3

If you are nesting 6 levels, you're probably artificially mixing multiple concerns. See below for the 5D model. It looks like you should be using namespace-class-method as the basic navigation model. You are at least mixing code structure with its organisation on disk (files and folders) and the mapping to variants. Smalltalk IDEs like Pharo provide a set of code browsers making navigation easy along a few dimensions, and provide a browser construction kit Glamour to make your own for other navigation dimensions.

You'll want to take a look at the work done by Richard Wettel. Something similar to Codecity. Using OpenGL to create a 3- and 4D (time) display of the development history of a project. It is part of the research in software reengineering MOOSE.

For your research you might want to use the 5 dimensional model for this:

• version (wanting to change)
• status (life cycle: creating, testing, deploying, retiring)
• view (requirement, code, test, documentation)
• hierarchy (module, class, method)
• variant (largely similar, describing the differences, product families)

Most systems only handle a few of these dimensions. To handle all five, you have to describe (fix) your development process. If you do, you can describe the use cases you want to support in your UI. If not, you need a 5-dimensional flexible display engine. That will not be as easy to use.

The reference:

Managing design data: the five dimensions of CAD frameworks, configuration management, and product data management.
van den Hamer, P. Lepoeter, K.
Philips Res., Eindhoven;

This paper appears in: Proceedings of the IEEE
Publication Date: Jan 1996
Volume: 84, Issue: 1
On page(s): 42-56
ISSN: 0018-9219
References Cited: 26
CODEN: IEEPAD
INSPEC Accession Number: 5175049
Digital Object Identifier: 10.1109/5.476025
Current Version Published: 2002-08-06

Answer 4

Hmm, I would start with silo, vertical cylinders, for each branch: dev, release, will have one or more here. You should visually place versions that were historically committed that silo in it. Between those versions you would have any number of other changes that eventually loop back.

Along each loop there are commit points outside of the silo with x number of changes. Visualize them logically flattened as fruit hanging down, it will be a bit of a muddled mess from the high level but the texture, color, pattern, size of the fruit would give you a sense of what happened. Also hovering over the fruit will provide whatever comments were made with the commit.

Then click on the stem of the fruit and here you flip the view around into several styles, but rather than navigating the hierarchy to the change, use the change to navigate the hierarchy. Big space on the left with little hiearchy space on the right. Hovering over changes will zip around the hierarchy. Click the change and the hierarchy is frozen and then you can click the hierarchy and you go to the silo view again but this time with the file/function/whatever being the only thing shown.

---EDIT--- Here is a sketch of kind of what I was thinking. My idea is based on using Mercurial as a source control repository. For me at least it would be more interesting to get a sense of the sorts of changes made in each revision, an idea which may not mesh with what you were shooting for. By looking at the sorts of changes the repository should be able to characterize and quantify what was changed, something more essential I think than what files were changed. The little dots would just be code changed within the method itself or possibly additions of private methods to a class. When you zoom in on a fruit it will fill the space and the trunks will disappear or fade to a dim watermark or some such.

Hope this crude sketch conveys my idea a bit better. alt text http://img704.imageshack.us/img704/9034/img0507h.jpg

Answer 5

If you want to be able to quickly find where the code has been modified, you could use a graphical representation, going to the tree-like representation (such as the one presented by mcliedtk) only when selecting an element that is suffisantly low-level (namespace, or type).

for each element, from the lower level to the upper one, calculate a % of modification :

• for a method or attribute : 100% if created/modified/deleted, 0% otherwise
• for a class : mean of all included elements (method or attribute), or 100% if created/deleted
• same thing for higher elements (100% if created/deleted, mean of components otherwise).

now you have to have to get a representation that is show the hierarchical structure.
you can (for exemple) use a radial one : the project is at the center (ie a circle). assembly are presented as a ring around, with each assebly taking the same space. a third level ring represent the modules, each module taking the same space for its assembly (ie if ther is 4 assembly, each one get 90°, and if an assembly has 3 module, each module get 1/3 of those 90°), and so on. each element get a color mapped from its % of modification (0% = green = no modification, >85% = red = heavey modification)

An exemple could be like http://www.neoformix.com/2006/BB_TopicRadialTreemapImages.png or http://www.datavisualization.ch/wp-content/uploads/2009/04/stacked_wedge_01.png

On the pro-side, you can quikly see where modification occured, and at which level.
on the minus side, this gives modification since a reference date, and a file modified once or twice is the same as a file modified 10 time. You may also have to add tooltips to facilitate navigation, as 6 level may quickly become unreadalble (but then you can display only the 4 of 5 higher levels...)

Regards
Guillaume