Revamp the code graph

[phfaist]

The current code graph page was written pretty hastily; it consists of a patchwork of JS code using web-ready libraries to plot the graph and offers no user-friendly means of navigating the graph.

I'd like to revamp the code graph page into a proper JS Web Application with a much more robust infrastructure and with a significantly higher user experience quality.

Requirements:

• A React-based JS web application, bundled along with other JS code into the zoo site using webpack (see the jscomponents/ folder)
• I'm anticipating that the cytoscape JS library should be used to generate the code graph
• Relationships between the codes should be made visible in an intuitive fashion (e.g., arrows to parents)
• The layout should be generated automatically, and should not require additional meta-information to be input in individual EC codes.
• The input to the app is a data structure representing a collection of EC codes, with meta-information such as name, description, etc., as well as references to parents, children, and cousins.

Some ideas that might require some design decisions:

• I'd like a user-friendly experience for navigating different parts of the graph. This might include some UI controls to zoom/pan the graph, to show/hide certain types of relationships, etc.
• Perhaps at the highest zoom level, we shouldn't display individual codes, but rather, "boxes" or some other visual effect placeholder to represent a family of codes (e.g., qubit codes). Ideas are welcome for how to meaningfully represent the information in an intuitive way at different zoom levels.
• The code graph will need more information than the bare meta-information given in the input data structure. E.g., it will want to build "code families", given for instance by collecting all codes that are a descendant of a given code. I'd like for such pre-processing code to be in a separate component/library, in anticipation for possible use also in other parts of the site generation process. (For background information, I'm eyeing a move of the entire site generation code from python to javascript.)
• The app's code should be sufficiently modular and make sufficiently few hypotheses about the code structure, in that I'd like it to be possible to generate a code graphs separately on other site pages, too, with a subset of the entire EC codes database. For instance, on the page of the parent "topological code", it would be nice to be able to generate a "local graph" of all topological codes (ignoring all other codes).

Optional:

• Any further ideas to make the browsing experience better are welcome!

[trentfridey]

Hi - I can help with this since I work mostly on web apps these days.

[phfaist]

Thanks Trent, that's awesome! A good starting point might be to port my patchwork of a code in the "pretty_code_graph" folder into an actual React app and store the code next to the other js app components in the jscomponents folder (say jscomponents/eczcodegraph/). We can then build on from there to improve the code graph along the lines indicated in the first comment of this issue. I'm happy to chat if there's anything you'd like to clarify, and of course, we'd also welcome if you have ideas on your end for how to improve the presentation of the code graph and the user experience it offers.

[trentfridey]

Ok - I will try to port the pretty_code_graph folder into a React App later on tonight. Can you point me to where the EC data is piped into the current graph? I think once that is clear, I can get the data into cytoscape using a wrapper like React-cytoscape.

[phfaist]

Right now it's a big patchwork. The data is dumped into a JavaScript/JSON file at site compile time (on this line), which is included with a <script> tag (via here, through the extra_js template parameter which generates extra <script> tags in the HTML) and which is picked up in the client-side JS code here. The reason for loading the data via <script> is again a total patchwork, I didn't want to bother with async JS calls (although that would be the right way to do this). Basically this pipeline should change, too.

I think we should aim for some Python code that runs at compile-time and whose sole purpose is to generate the necessary JSON data for the code graph. The JSON data would then be loaded on the client side, preferably in an async request call à la fetch() (we could show some "loading..." message or animation while the data is loading, etc.). It's still not entirely clear to me what information about the code family tree should be computed at compile time versus JS client-side, such as:

• which domain/kingdom a code belongs to (determined by looking up parents until we hit upon a kingdom code)
• whether a code is an abstract property code (green nodes) or a concrete code (brown nodes). (I need to check again, this is either determined by whether or not it has physical/logical spaces properties set, or whether or not it has a kingdom ancestor.)
• identify codes that have lots of children (maybe call them "family heads") in order to allow the user to zoom/focus into that entire family.

I'm inclined to say for now that most of this additional information should be computed at the client side, to save bandwidth and compilation time.

Let me know if there's any additional information I missed. I think it's a promising project, and thanks a lot for your help!

[phfaist]

Also don't hesitate to hit me up if you have any questions for deciphering the existing code, I'll admit it's a bit of a mess

[trentfridey]

Yes I think the architecture of the app could use some refactoring, but I am sure that you have a better idea of what that might look like. I can try to get a front-end for the graph working with the UI enhancements that you've listed here but I am blocked by an issue in the React Cytoscape project

[phfaist]

Thanks for the update, let me know if there's anything on our end we can help with in the meantime.