The initial layout algorithm uses too wide a layout in "larger" models

[kltm]

The initial layout algorithm sometimes "hides" individuals to the right. This is especially noticable in larger models where the shadow Sugiyama layout will shunt singletons off to the side.

If possible, when a new individual is created (rather than laying out a new model), the individual should be placed with the _vari function somewhere around the upper-left.

[kltm]

This was initially formulated as sometimes "hiding things to the right", but given model size and the way edges flow in models, essentially the sugiyama layout quickly starts failing from a usability perspective, sending nodes incredibly far away (breadth plus edge spacings).

There are a few options here.

• retire sugiyama for a "dumber" packing algorithm
• only use sugiyama for initial layouts, never for adding to an existing model
  • in fact, all additions could be the same point on the viewport and that would likely be fine
• nick a more context appropriate layout engine (looking at you, cytoscape)

[kltm]

A simple rule of thumb could be: if no layout info exists for /any/ individual, use an engine; otherwise let people sort it out manually. This would fall apart, however, during things like template imports, certain workbenches, etc.

Ideally, we could have a very complex and subtle system where node sets could be selected from the view or table and different group moves and compactions could be run; imported nodes could be marked and have their own algorithms run. However, practically, for the near and medium term, we need one or two best effort systems that can be globally run.

My person view right now is:

• replace sugiyama with one of the cytoscape layouts, but keep the different priorities (saved < barista < local)
• for things that need to be "fixed" add a [Compact/Fix layout] button to [Skunkworks] that will manually go through and force the selected cyotoscape layout everywhere

[kltm]

Nicely, the currently used layout algorithm is only nicking a bit from our sugiyama implementation:

{
  "nodes": [
    {
      "id": "foo",
      "x": 1, 
      "y": 1
    }
  ]
}

It should be easy to wrap other layouts in there. Now what units are these in again? Scrape a session and double check.

[kltm]

Ugh, it's pixel placement, rather than segmented. Too bad.

[kltm]

Unfortunately, it looks like some of the cytoscape.js layouts depend on asynchronous code (in their parlance "continuous"), rather than just synchronous ("discrete") algorithms. Using cytoscape, I can see why that is, but it's in pretty deep and throws a bit of a wrench into reusing the code the way I intended. (http://js.cytoscape.org/#cy.layout) This leaves a few options.

• restructure this code to be promise based, which I'd really rather not do
• jimmy out/make synchronous the parts that we want
• find a different engine to use
• write a basic engine for our use case

I'll do some experiments to see if the main ones that I want to use are going to be an issue. If so, I'd probably try for the second option first.

[kltm]

Not solved yet as of this writing: http://noctua.berkeleybop.org/editor/graph/gomodel:5745387b00001254 I would maybe add:

• a hard limit to the size of the canvas
• make it impossible for new single nodes to be too far out of the current node-defined bounding box
• have some sanity upper limit on how far out nodes can be placed during initial layout (considering nodes + edges)

@ukemi is this model one you built yourself from the ground up, or was seeding happening here?

[kltm]

I think the correct precedence and algorithm for nodes for graph editor users is:

• [ ] the current value supplied by barista (possibly non-saved by current editors)
• [ ] the current value of the hint (historical saved version)
• [ ] layout (if within reasonable delta of currently placed nodes--no rogues rule)
  • this gets a little more complicated, there are a couple of choices:
    1. the maximum range available for automatic placement in either direction should not exceed, say, (|N|/2); try to give an automated layout unless the graph is too "flat"
    2. ((size(n) * 3) + distance from origin of farthest node of the current visible; more "compact", but less opportunity for automatic layout
  • both of these can have degenerate cases, with the former being maybe better at dealing with bulk placement and the latter being better with new single individuals; it would be hard to mix these, but the addition of "b" may give a little wiggle room to the dominant "a"
• [ ] close scatter on center of current display
• [ ] close scatter on upper-left (gotta put it somewhere)

A more optimal solution in a "graph editor"-only world would be to have the centered scatter occur before automated placement, as the editor will generally be adding nodes in small batches. However, that falls apart during bulk (e.g. workbench) operations or when coming in to an automated or "form client"-generated model for the first time.

[kltm]

This will be a relatively short-term fix. Long-term fixes are some combination of: 1) much better layout engine, 2) overview thumbnail, 3) integrated pan and zoom. Irritatingly, pretty much all of these are in the closed source "Toolkit edition" of jsPlumb, while the "Community edition" rather lags behind.

[kltm]

A fun pseudo-fix for some cases could be a reel in function on edges. This would essentially bring in the nodes on an edge into the neighborhood of the pointer at the same relative angle.

[goodb]

At some point, sooner or later, some one is going to work on doing automatic layouts for GO-CAMs or graphs derived from GO-CAMs. When they do, this paper will be a nice reference for starting points https://academic.oup.com/bib/article/21/1/62/5115270

abstract The use of signalling pathway hypergraphs represented as process description diagrams is steadily becoming more pervasive in the field of biology. This makes ever more evident the necessity for an effective automated layout that can replicate high-quality manually drawn diagrams. The complexity and idiosyncrasies of these diagrams, as well as the specific tasks the end users perform with them, mean that a layout must meet many requirements beyond the simple metrics used in existing automated computational approaches. In this paper we outline these requirements, examine existing ones and describe new ones. We demonstrate state-of-the-art layout techniques enhanced with novel functionalities to meet part of the requirements. For comparatively small signalling pathways our enhanced algorithm provides results close to manually drawn layouts. In addition, we suggest technical approaches that may be suited for fulfilling the identified requirements currently not covered.

[vanaukenk]

Not actively being worked on; closing for now. May revisit with broader model visualization discussions.