Default Neighbourhood Layout Inadequate with SubClasses

[everbeek]

Ray submitted 4311 on GForge: The default layout for "neighborhood" is terrible if there are more than a few subclasses. For example, look at the visualization of the Snomed Procedure term. The subclasses are all laid out of top of each other when there is plenty of unused space. For the "neighborhood" I would think that the best layout would be the selected term in the middle surrounded by a circle (or several) of nodes.

A hyperbolic layout might work too.

[everbeek]

I am not sure about changing the layout from tree to a semi-circle, but I can improve it. I am looking to see why the node size is not taken it account; preventing overlap alone would improve things.

I can also consider not a circular layout, but a radial tree layout. This is in the spirit of Mark's suggestion.

[everbeek]

I have a layout now that works for two levels, but on the third level, it uses the whole circle for whatever second level nodes there are. This is not good when only one 2nd level node has its children in the 3rd level; those 3rd children have their arcs spanning across the whole layout (it puts foru nodes, for example, at the four corners of the circle).

I based the radial layout off of the tree layouts. It might be some more adjustment that does the trick, but there might be too many differences to continue from here. Sticking to this until it seems obvious I need more from scratch.

[everbeek]

The layout still needs determining level radius on the basis of the amount of ring space required for the nodes in that level, while limiting the number of arc crossovers...maybe this can be arrived at analytically?

Suppose we have three levels. Center node, a nicely filled ring around, and a third level consisting of only one 2nd level node's 4 children. Right now, this is how it looks:

But I want it to look like this:

If each ring determines how much space it needs in terms of perimeter, we then know how far away from the center the ring needs to be. Right now, the radius is determined on the basis of level alone. Looking into changes to get what I want.

I should probably commit what I have first! Doing that.

[everbeek]

I might leave this as is for December release, so that I can also do other things. It works, and isn't wrong. I can tweak it later.

[everbeek]

The layout has a tendency to be centered with y = the bottom of the view port in Firefox. This works fine in Chrome. I actually think that the view is being constrained somehow in Firefox, so this might be tricky to fix.

http://bioportal.bioontology.org/ontologies/40133/?p=terms&conceptid=MY-mot#visualization

In Chrome, the visualization view takes more vertical space than in Firefox, so this in congruent with my suspicion. How do I deal with this?

[everbeek]

The way that the size of the graph is used for the vertical and horizontal tree layouts, and for the partly related radial layout, are different, and I cannot see how the radial layout is using it "wrong". The fact that this is not really an important issue in Chrome is frustrating, but doesn't nullify the fact that Firefox is important and the layout is broken there. I have spent all morning looking at this and haven't found a solution yet.

[everbeek]

In Chrome, the displacement appears to be to the top right, by the radius of the radial layout (and the circle layout). In Firefox, the displacement is to the bottom left, and in Chrome it is less displaced, less squashed, and displaced towards the top right rather than bottom left.

The way to show these directions is to open the side panel and switch between circle and radial layout in Chrome and Firefox.

Those two layouts have (about?) the same radius in each browser, and the radial one moves where I described above. Scrollbars behave better in Chrome, but I am not sure if that means anything.

[everbeek]

The actual size of the graph view affects the radius of the layout, but doesn't directly affect it's location; it shows up at the same y-coord when I shrink the y-size, getting all scrunched up in the process, and moving leftware in both browsers. So perhaps the difference between the browsers comes down to a difference in size, when it does occur. Let's pretend that for now anyway.

When I do the circle layout with resized browser, it behaves quite correctly! Focussing on Chrome, with a shrunk browser, is the easiest way to continue, so I will do that.

What hint does this give me? I can't see the problem in the code. I have looked at the size of the graph and how that is added to the desired relative layout coordinates (in the polarToCartesian() method). Maybe...maybe the relative desired coords and the graph coords are in different spaces somehow? Does it have to do with the getTopLeftForCentreAt() method? Should I use that on the origin? Why doesn't the GWT method to get the view size reply with the shrunk view size?

[everbeek]

I think I got it! The place I added the origin offset was prior to calling the getTopLeftForCenter method; when I add that after (which sounds very reasonable) it renders properly in resized windows. Double checking the results, then cleaning up and committing.

[everbeek]

Although it fixes it in dev context with GWT compile, in a stand alone embed, it doesn't work in the stage embed (pointing at the newly deployed bioportal-integration-test). Is there caching of the BioMixer files? There's no difference there, but the GWT compiled ones are totally fixed.

I will check on Monday, and see if some cached files have been cleared.

[everbeek]

It works this Monday! Committing and deploying to live.

[everbeek]

Commented on GForge 4311 and emailed Trish.