Every few weeks I received a mail asking for the current status of the project, whether it’s completely dead or whether certain enhancements can be made. There were also various (legitimate) complaints about the missing documentation of the project.

Hence I thought I should continue to work on the project at least if time allows it. Here I would like to give an overview about the next development steps and the reasons for this. I’m afraid, I can’t give a time estimation as I’m not working on this project on a regular basis.

Well, the next steps will be:

1. Finish the refactoring to become independent of the UI (support at least AWT/Sing and SWT)
2. Get rid of the graph data structure and algorithms; replace it by JgraphT
3. Tidy up the existing graph layout algorithms
4. Tidy up the example applications and add new examples
5. Enhance the Javadoc
6. Relaunch the website, including a better documentation

As you can see, I start with the parts which are more fun to me and end up with the (usually boring, but necessary) documentation.

Independence of the UI framework

The existing Hypergraph code consists of three parts: packages related to the graph structure, a package for the hyperbolic geometry and a package for the visualisation of the hyperbolic graphs and hyperbolic trees in a JPanel. At first sight, this sounds like a reasonable architecture, but if you look at the code in detail, you will find that this is not the case, here some examples:

• The colour attribute for edges and vertices are stored using java.awt.Colour. If you use this graph in frameworks which don’t use java.awt.Colour, this causes a problem.
• The projector which is responsible for projecting the hyperbolic plane to the screen coordinates depends on JComponent
• The animator which is responsible for smoothly translating the hyperbolic plane uses javax.swing.Timer.

If the code shall be used by different UI frameworks, these dependencies have to be resolved, which is the first aim. Large parts are already done and committed to the SWT branch, but there is still something to do.

Replacement of the Graph API by JGraphT

When I started in 2002/2003, I decided to write my own graph API. By now, there are some established projects written in Java which offer the functionality I need and I decided to use JGraphT.

The advantage is that I don’t need to worry about the (correct) implementation of any algorithms or data structure – there is no need to reinvent the wheel.

There are disadvantes though: I have to rewrite any code that depend on the existing graph data structure, which is quite a lot by the nature of the project. Also there doesn’t seem to be any reader for GraphML or GraphXML files, so need to implement them.

Tidying up the layout algorithms

The most striking issue with the hyperbolic layout algorithms is the poor quality of the code. I have to confess that I can’t read the code at all…

But there are some other deficiencies: the layout algorithms are graph layout algorithms. Well, that sounds tautologic, but for example the force directed layout is actually a generic multi dimensional scaling algorithm which could also be applied to other data than graphs. It will be interesting to see whether hyperbolic geometry can also be used for other visualisation besides hyperbolic trees and graphs.

This will happen more or less at the same time as the introduction of JGraphT as this is related.

Tidying up the example applications

Similar to the layout algorithms, the code quality of the applications is quite poor – the programs are a mixture of examples and proof of concept. Even the main applet to show hyperbolic trees should be tidied up.

I haven’t thought yet about which examples and which actual applications I should include in the distribution. If you have any proposals or if you would like to have an example for a specific concept in Hypergraph, please add a comment.

Enhancement of  the Javadoc and relaunching the website

The need to enhance the Javadoc should be obvious to anybody who has worked with the code. The same applies to the website: it’s not complete at all.

Currently, it’s difficult or at least not comfortable to add new content to the website due to the way the html files are generated and deployed.

As I have also spent some time working with CouchDB, I might decide to use CouchDB as a storage and web server and create some mixture of blog and wiki for the new website.

Conclusion

As you can see, there is a lot to do and I hope to provide a new release soon which covers at least the first two issues. I will also try to write about how the issues are resolved, i.e. describe the new architecture of Hypergraph.

As a last remark, let me mention that I’m not very glad about the project’s name Hypergraph. When I created the project, I thought this is a nice combination of hyperbolic geometry and graphs. However, I completely ignored that hypergraph is actually a fixed notion in graph theory which can lead to confusion. I wonder whether there is some other name which hints at the main focus of the project: data visualisation using hyperbolic geometry. If you have any ideas, please add a comment.

The application is using Ruby on Rails with a Mysql database in the background. Apart of the public part of the application, there is an admin interface which allows Peter to update the data. Since I worked on this project only sporadically in my spare time, two challenges proved to be more complicated than expected:

1. Versioning of changes:
   We tried to make changes of the data transparent to the user. It should be visible to the user, when information has been changed, for example when a composition has been published, or other data is corrected. Hence there is some change history.
   However, not all changes should be mentioned – simple corrections of typos etc. should be ignored.
   Finally, the versions must span several tables as there are a lot one-to-many or many-to-many relations.
2. Synchronisation:
   Most of the research is done offline, for example in libraries or when travelling. Therefore there exist two installations, both being “productive”: the official homepage plus an offline installation which is used during the research.

Both problems can be solved, but there is no “out-of-the box” solution. There will be some detail about how to solve these two issues in a Rails application in following posts.

In the previous design, I used the WP Simile Timeline plugin to show the timeline of the blog entries. This was a vertical timeline located in the left sidebar. The problem was that vertical timelines are pretty complicated to design and the simile timeline doesn’t really support a vertical layout. Therefore I chose to change to a horizontal blog timeline as part of the redesign. At the same time I realized that the timeline doesn’t fit to the overall design.

Hence I wrote my own timeline implementation using jQuery and embedded it in the new layout. Each small vertical tick in the header corresponds to a blog entry. If you hover over it, the link to the blog entry is shown.

Currently there are only few features:

1. RSS feed: the timeline implementation reads the RSS feed of the site an creates the div elements for the timeline.
2. Custom creation of events:  create a div and call a simple javascript method to add an event.
3. Design completely using CSS: it is very difficult to change the theme of the simile timeline. The timeline above can be adjusted using very simple CSS.

But of course, it still can (and needs) to be enhanced.

To be honest, I don’t think that this would be a good idea. On this page I use the Cumulus plugin by Roy Tanck. This plugin does a good job in visualizing the tags in your blog by distributing the tags on a 3D sphere. It’s easy to use, easy to understand – so if you are looking for some appealing visualisation of your tags, use this plugin and you’re done.

But why don’t I write a wordpress plugin for Hypergraph? First of all I currently don’t have the time . But apart of that, I don’t think it’s fit for purpose. Hypergraph, like other tools that show trees/graphs using hyperbolic geometry, is strong when there is some exponentially growing graph structure in the background. For example the organisational structure of a company or a class hierarchy are suitable.

However,  this is not the case for blogs: tags are used to loosely group blog entries which are somehow related, but even if we enforce a graph structure based on tags (which I don’t really propose), it won’t work. Of course one could link all entries with the same tag(s). Of course I haven’t conducted something like a field study to analyse a significant amount of blogs in the wild, but I assume that this will just create a lot of clutter, but won’t give additional meaning. Plugins like the mentioned Cumulus plugin circumvent this problem: they show the tags and not the articles, hence reducing the number of entities to show. They also don’t link the tags – even thought this would be some interesting challenge.

This leaves us with two open questions: Is it possible to cluster tags such that some similarity of tags can be established? If this can be done, would this give benefit to the visitor of a blog or another site?

Ideas and comments are of course most welcome.

But thanks to XSLT, there is a simple solution: Bitten is able to include test and coverage reports from xml files. And since checkstyle generates a xml file for the results, it was straight-forward to translate the checkstyle xml file to a xml file for bitten. The only problem is that bitten only knows the two mentioned types of reports, so I decided to use the test report. 

And this is the (extremely simple) stylesheet:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

  <xsl:template match="file">
    <xsl:choose>
      <xsl:when test="count(error) = 0">
        <test status="success" fixture="{@name}" name="No checkstyle errors" file="{@name}" />
      </xsl:when>
      <xsl:otherwise>
        <xsl:for-each select="error">
          <test status="error" fixture="{../@name}" name="{@message}" file="{../@name}" />
        </xsl:for-each>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>

  <xsl:template match="checkstyle">
    <report category="test">
      <xsl:apply-templates/>
    </report>
  </xsl:template>   

</xsl:stylesheet>

Translating the checkstyle xml report using this stylesheet allows you to treat checkstyle results in the same way as unit test failures.

But there is one slight problem: the file names in the checkstyle xml are absolute file names. Hence also the file names in the bitten build summary are absolute. In my setup this means having something like “/tmp/bittenFpQXrh/build_Trunk_22″ in front of the name, which doesn’t look good and it also breaks the link to the source code. The simple solution was to remove the path name from the checkstyle report using the following ant task:

<replace file=“${dir.reports}/checkstyle_report.xml” token=“${basedir}” value=“”/>

Maybe it would be nice not to link the checkstyle results to the source code, but rather to the html reports which give more information about the details of the problem.

Please see on of the antdiff build status pages as an example (click on “Test results” in the checkstyle section).

The basic idea is to have a program on one single page / in one single graphic, which shows the overall structure and density of the program part you are looking at. Bradford Pailey adds an overlay that shows the actual execution path on top of the code.

I wonder whether this idea, which is currently art rather than a programming tool,  can actually be implemented as part of an IDE plugin (I’m thinking of Eclipse as I’m working with Eclipse 99% of my time). 

The code is of course already available in any IDE and profiling data could be obtained from the Eclipse Test and Performance Platform or other profiling tools.

However, it’s not yet clear to me how the interaction between the different classes and packages can be covered. The graphic by Bradford Pailey shows a program that consists of one file only – at least that’s what it looks like.