Discussion: keep the YAML editor

[grdw]

Should we keep the YAML editor as an available option to edit and create a topology alongside the current graphical editor?

[ChaelKruip]

I think so yes. This allows advanced users to make changes to a topology in a text editor and quickly generate topologies from existing ones.

[dennisquintel]

Agree

[antw]

In light of https://github.com/quintel/etmoses/issues/1464#issuecomment-250768277 I want to reopen this because I'm unconvinced of the need for this to exist. I don't think there's much benefit to it:

• A "clone topology" button is simple to implement and more user-friendly than copy/pasting YAML.
• I doubt that editing YAML is significantly faster than the new GUI.

On the other hand, maintaining state between the two UIs is clearly going to be a pain, as is nicely formatting the YAML.

@dennisschoenmakers @ChaelKruip @grdw Could we do without this for now please, and add it in later if it really proves to be necessary?

[grdw]

I sort of already implemented it (almost). 😅 I could keep it in a branch if it is really needed. I don't feel to strong for keeping the YAML editor or removing it. Ofcourse, I can imagine, adding 100 endpoints is going to be hard. Using a Ruby script to do:

require 'yaml'

chain = { name: "HV", children: [] }
100.times do |num|
   chain[:children].push({ name: "LV##{num}" });
end

puts YAML.dump(chain)

And than copy/pasting the output in the YAML editor does seem like less work than hitting the + button 100 times and changing all the names by hand. But I don't know how likely it is that there will be more topologies created similar to Lochem.

[antw]

Ofcourse, I can imagine, adding 100 endpoints is going to be hard. Using a Ruby script to do: [...] And than copy/pasting it in your browser does seem like less work than hitting the + button 100 times and changing all the names by hand...

Indeed, but is writing a script a likely course-of-action for Moses users? Even copy/pasting 100 nodes needs 8 operations: 1 node → 2 → 4 → 8 → 16 → 32 → 64 → 128, then the person has to count and delete 28 to get back to 100.

How about...

[ChaelKruip]

Could we do without this for now please, and add it in later if it really proves to be necessary?

I'm in favour of keeping the code as simple as possible but I'm a bit on the fence about scrapping the YAML interface just yet.

From a user perspective there are two things that might become (very) cumbersome in the GUI unless dedicated functionality is added:

• re-using an existing topology or existing nodes to an end-point of another topology: in YAML that is a copy paste + indent operation but in the GUI this is a lot of manual labour
• renaming all occurrences of an attribute (for example "stakeholder A -> stakeholder B"): in YAMLS a simple replace all does the job

What could be really cool to 'solve' feature 1 in a GUI is a library of existing nodes (like typical trafo's) and small topologies (like a trafo with three outgoing lines and end-points) and the ability to drag-and-connect them to the topology at hand.

Also, it would be great to have pre-defined templates (like a typical trafo of 400MW, 10.000 EUR investment cost, 100 EUR/y O&M costs etc.) which you can drag-and-apply to any node in the topology you are building.

Find-replace across the topology could also be added to the GUI at some point I can imagine...

@antw @grdw What are your ideas about such features? Should we build them into the GUI first and make the YAML redundant in one fell swoop? Or should we have a transition period where we only keep the YAML to deal with these advance features which only 20% of users will need on a regular basis?

[grdw]

Indeed, but is writing a script a likely course-of-action for Moses users?

Hmm, considering you're advanced enough to know bits of YAML. 😅

How about...

Looks nice. We might also pop up that menu if somebody does a CMD/Ctrl + click instead of adding another button.

[antw]

@antw @grdw What are your ideas about such features? Should we build them into the GUI first and make the YAML redundant in one fell swoop? Or should we have a transition period where we only keep the YAML to deal with these advance features which only 20% of users will need on a regular basis?

Or a transition period where we get rid of the YAML immediately and add new features to the GUI as needed? 😈

Also, it would be great to have pre-defined templates (like a typical trafo of 400MW, 10.000 EUR investment cost, 100 EUR/y O&M costs etc.) which you can drag-and-apply to any node in the topology you are building.

I like the idea of templates a lot; I can see how that would be very useful, especially to new visitors who don't know the details of how to build networks and just want to use some sensible real-world defaults.

In the long-term we might even allow visitors to save their own template subnets with a third "Save subnet" option?

/shrug

Find-replace across the topology could also be added to the GUI at some point I can imagine...

Well... it's annoying to have to change the capacity of 20 P2P batteries, but we wouldn't let visitors edit the technology profile JSON directly. I think we should worry about this once we know it's an issue, otherwise we might be trying to come up with a solution to a problem that doesn't exist.

[ChaelKruip]

Or a transition period where we get rid of the YAML immediately and add new features to the GUI as needed? 😈

👍

[ChaelKruip]

In the long-term we might even allow visitors to save their own template subnets with a third "Save subnet" option?

I like this idea as well!

[ChaelKruip]

Closing this issue as the consensus seems to be to ditch the YAML interface in lieu of the GUI.