New interface for Topology edit and new form

[grdw]

I'd like to propose a change in the new and edit form of the Topology. I see a lot of Airbrake messages coming from people naively editing the Topology and accidentally destroying their LES. Also the current interface excpects that people know YAML..

Second iteration

I went to the drawing board and showed @ChaelKruip and he and I returned to an idea I had back in november. The idea in a broad sense is to 'draw' the topology:

Draw space:                                  | Info about node:
                                             |
                                             |  | name:       [ HV Network         ]
                   O + - - - - - - - - - - - - <| attribute:  [                    ]
                                             |  | attribute:  [                    ]

One node always remains 'in focus'; meaning the one node which information is shown and can be edited.

Adding a new node Idea 1 In the example above the user is able to draw a node by dragging a line outward from the first node to a certain position. This is giving the user a lot of freedom. Also by knowing that there will be a map in the nearby future I actually like this 'freedom' a lot. In the example however the nodes are animating all over the place, this is something we should not support.

Pro's

• Intuitive
• Freedom of drawing for user
• Adding one node can be done with precision

Con's

• Adding 100 nodes becomes a tedious job compared to the YAML approach

Idea 2 We could also when hovering/focussing over/on a node add another bulb/'add/+' button (like here) to be able to drag a new node out of. This way moving a node can be just done by dragging without having to press Ctrl/Cmd. Also the 'add/+' button will be able to take two event handlers:

addButton
    .on('click', function () {
        // Move the new node directly under the node
    })
    .on('dragend', function () {
        // Set the node on the position where the user left it.
    })

What if someone clicks the addButton 3x?

First time:       | Second time:    | Third time:
O +                  O +               O +
|                   / \              / | \
O                  O   O            O  O  O

It should automatically space out the nodes under the 'clicked' node. What if someone accidentally drags his node over his own node? Well, than he can drag it back.

Moving a node Moving a node I would do by hitting the Ctrl/Cmd button (depending on which idea is suitable for adding a node) + dragging the node. Clicking on a node will put the node in 'focus' in essence giving it a different glow + showing the information form.

Removing a node First off the most obvious choice here is to be able to click a node and hit the DEL/Backspace key. This is similar to the example above. This removes all nodes and children under that node (I think that when you have children under a node it should alert with "Do you really want to remove your children?" or something a bit more parent-friendly.

Technical

There is one global class called GraphEditor. This serves purely as an interface between the other components. When you're at the new form the GraphEditor will take a default hierarchical data.

var GraphEditor = (function () {
    'use strict';

    function addNode() {
        // Draw a node <circle/>
        this.graphData.add(this, { <Form data/> });
    }

    function removeNode() {
        // Remove a node <circle/>
        this.graphData.delete(this);
    }

    function updateNode() {
        this.graphData.update(this, { <Form data/> });
    }

    function showForm() {
    }

    GraphEditor.prototype = {
        initialize: function (data) {
            // Draw the node structure from data
            // - node (click -> showForm())
            // - addButton (click -> addNode())
        },

        updateHiddenForm: function () {
            $("textarea.graph").text(HierarchyTransfomer.toHierarchy(this.graphData.data));
        }
    }

    function GraphEditor(data) {
        this.flatData  = HierarchyTransfomer.fromHierarch(data);
        this.graphData = new GraphData(this.flatData);
    }

    return GraphEditor;
}());

In the class above there are two components visible the GraphData being one of them. I don't want to flood the DOM with lots of data- elements (like the TechnologiesForm). Instead I want to keep the data in the Javascript window somewhere or as a mere part of the GraphData instance. This is a sort of CRUD like interface:

var GraphData = (function () {
    'use strict';

    GraphData.prototype = {
        add: function (domEl, data) {
            var newId = "N" + new Date().getTime();
            this.data[newId] = $.extend(data, parent_id: domEl.getAttribute('data-id'));
        },

        update: function (domEl) {
        },

        remove: function (domEl) {
        }        
    }

    function GraphData(data) {
         this.data = data;
    }

    return GraphData;
}());

This module should be able to take hierarchal data like:

{ 
   name: "HV",
   children: [ { name: "MV" } ] 
}

to:

{  
  "<identifier-hv>":   { name: "HV" },
   "<identifier-mv>":  { name: "MV", parent: "<identifier-hv>" }
}

and the other way around.

var HierarchyTransformer = (function () {
    'use strict';

    return {
        fromHierarchy: function (data) {},
        toHierarchy: function (data) {}
    }
} ());

Questions:

• Should dragging and clicking be allowed to add a new node?

---

First iteration

New form

The new form will start out like this:

name:           [          ]
permissions:    O private  O public
graph:
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| name:                  [  HV network  ]       |
| stakeholder:           [            v ]       |
| capacity:              [              ]       |
| technical lifetime:    [              ]     [+] <-- will add a new row

Adding a new row:

name:           [          ]
permissions:    O private  O public
graph:
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| name:                  [  HV network  ]       |
| stakeholder:           [            v ]       |
| capacity:              [              ]       |
| technical lifetime:    [              ]     [+] 
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| name:                  [              ]       |
| stakeholder:           [            v ]       |
| capacity:              [              ]       |
| technical lifetime:    [              ]  [>][+]
                                            ^------------ That button will "move" nest the component under the HV Network.

Visually this is:
---------------

O HV Network  O <Unnamed node>

Nesting a node:

name:           [          ]
permissions:    O private  O public
graph:
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| name:                  [  HV network  ]       |
| stakeholder:           [            v ]       |
| capacity:              [              ]       |
| technical lifetime:    [              ]     [+]
   _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
  | name:                  [              ]       |
  | stakeholder:           [            v ]       |
  | capacity:              [              ]       |
  | technical lifetime:    [              ]  [<][+]
                                              ^------------ That button will "move" the component on the same level as HV Network

Visually this is:
---------------

O HV Network  
|
O <Unnamed node>

Edit form

The edit form will work similar as the new form except for the [>] and [<] buttons and addition buttons. Also it should not be possible to edit the name of the nodes. These form elements should be disabled or just displayed as bold pieces of text.

[ChaelKruip]

Also see

https://github.com/quintel/etmoses/issues/1192 https://github.com/quintel/etmoses/issues/780 https://github.com/quintel/etmoses/issues/596

[grdw]

I would like some opinions about the Second Iteration from @dennisschoenmakers @antw

[antw]

I would like some opinions about the Second Iteration from @dennisschoenmakers @antw

I like the direction; a graphical approach would be hugely better than what we have today. I have a slight preference for Adding a new node: idea 2 since explicit (+) buttons are quite intuitive, whereas "click a node and drag" is not obvious and might have to be explained to new visitors.

Moving a node I would do by hitting the Ctrl/Cmd button (depending on which idea is suitable for adding a node) + dragging the node. Clicking on a node will put the node in 'focus' in essence giving it a different glow + showing the information form.

It sounds like you want to allow visitors to position the nodes themselves instead of them being auto-arranged into a tree? I like this too, but I have one concern: for large networks this is going to become a nightmarish mess of nodes and edges all over the screen. If we do this I'd like for there to be an "Auto-arrange" button which automatically moves all the nodes into a tree display like we have now.

This module should be able to take hierarchal data like: [...] to:

{  
  "<identifier-hv>":   { name: "HV" },
  "<identifier-mv>":  { name: "MV", parent: "<identifier-hv>" }
}

Might I suggest using UUIDs for the identifiers? Practically no chance of collisions and in the longer-term I'd like to adds UUIDs to technologies as well (since being able to identify individual technologies with a unique ID will make it easier to show inline validation messages).

Anyway, this is a big :+1: from me.

[dennisquintel]

I would like some opinions about the Second Iteration from @dennisschoenmakers @antw

Do I understand correctly, that the first iteration has been surpassed by the second iteration?

I like the direction; a graphical approach would be hugely better than what we have today. I have a slight preference for Adding a new node: idea 2 since explicit (+) buttons are quite intuitive, whereas "click a node and drag" is not obvious and might have to be explained to new visitors.

Agree (how could I not?) with @antw.

[...] but I have one concern: for large networks this is going to become a nightmarish mess of nodes and edges all over the screen.

I was also thinking about this. The current approach works well with small trees, but for large trees this is going to be a disaster.

Perhaps we could keep the visual approach, we're all in favor of that, but steal from the folder and file trees that have been created in various operating systems?

[ChaelKruip]

Perhaps we could keep the visual approach, we're all in favor of that, but steal from the folder and file trees that have been created in various operating systems?

👍 Especially if we support the option of hiding/folding parts of the tree (as we currently do) which is the staple of such directory trees as well.

[grdw]

Perhaps we could keep the visual approach, we're all in favor of that, but steal from the folder and file trees that have been created in various operating systems?

Wich parts should we steal? (The collapsing part or the way it's positioned?); considering the point made by anthony was about the 'free' positioning; I guess it's positioning.

To explain the roots of that idea; the free positioning came forth from the idea of a map of Holland where you could drag the components to. I think the free positioning idea should be reconsidered once we're actually doing something useful with the GIS data and maps. For now automatically positioning the nodes, once added, makes more sense in my opinion.

[ChaelKruip]

I think the free positioning idea should be reconsidered once we're actually doing something useful with the GIS data and maps.

Hopefully this will be quite soon so it would be wise to keep this in mind when designing this.

[grdw]

I moved all details into separate issues. An overview issue has been created here: #1434. Please keep everything on topic. 😄

I'll close this issue.