Exercise Graph - Next steps

[neenjaw]

I'm opening this issue to explore possible next steps for refining/revising/expanding on the exercise graph. Incidentally, I may interchangeably use the terms graph, tree, DAG -- I mean to refer to this graph so the term doesn't really matter to me.

As such, the current state of the graph is:

• It builds the graph from data fetched from the config.json present in each language's folder in the exercism/v3 repo.
• Exercise slugs are unique, concept names are unique.
• Exercises may unlock 1 or more concept, and may depend on 1 or more prerequisite concept.
• Concepts may only be unlocked by one and only one exercise.
• Exercises without prerequisite exercises (either are placed in the top layer (layer index 0).
• Subsequent Exercises are then placed in layers such that it appears in the layer following its deepest prerequisite exercise
• Exercises declare what prerequisite concepts it requires, and edges are formed then between the exercise and whichever exercise unlocks that concept.
• If an exercise does not exist to unlock the concept, it is then displayed half-a layer higher than the highest exercise which depends on that concept.

The result:

---

Next steps

Representing a more complete graph

During the group call, some ideas were floated about how this graph may be expanded upon. Ideas were focused around altering the format of the config.json file to allow for incomplete or unimplemented exercises to be represented in the graph.

Exercises in different states can be easily represented with different shapes / colors.

I have a hesitation when it comes to expanding this feature is that it may promote the idea that the tree must be completed before exercises, which I believe to be putting the cart before the horse with my experience with the elixir track so far. I have tried to conceptualize the complete track (see: graph - mar 20) which I think hindered attempts to just start writing exercises -- which was by far the best method to flush out concepts more fully and create a more natural progression.

Simplifying or Untangling the Graph

The graph is noisy in its current state and I think there are at least two reasons:

• there is no attempt to untangle the graph as it is. Nodes are computed by depth, centered according to the width of the svg container, then edges drawn to connect them.
• edges shown represent the dependencies rather than the unlock progression.

Simplifying the graph

I think this is easily accomplished by only showing the exercises's closest dependencies (which then represent the unlock progression) then displaying the dependencies as an additional layer which can be hidden or visible.

An example of this:

Untangling the graph

I think there is likely only so much untangling that can be done on a graph which may have multiple source nodes, a vertical [or horizontal] orientation (to imply an progression). But one question I have is if there are any suggestions on how this graph may be displayed more compactly?

It could be compacted a lot if there was no text present, but then I think it loses a lot of value as a reference. I haven't had much success finding similar graphs and am not really a designer so some input would be really nice here.

This is what Jetbrains Academy is doing with its java curriculum map:

Table View:

Tree View:

Increasing Usability

• Making the nodes perform actions, eg. clicking an unimplemented concept takes the user to the new exercise page where they can then create an issue to implement the exercise which unlocks that concept
• Clicking the node for a completed exercise take a person to that folder in the repo

---

So what do you think are the next steps for this graph?

[ErikSchierboom]

I think this is easily accomplished by only showing the exercises's closest dependencies (which then represent the unlock progression) then displaying the dependencies as an additional layer which can be hidden or visible.

I like that idea! It would be at least a good idea to try it out I think.

[neenjaw]

I think it is one of the simpler ideas. I think most others start to re-write the drawing/positioning (which I don't have many ideas for at this time). This will just divide the set of edges to visible and not visible.

[ErikSchierboom]

I think it is one of the simpler ideas.

Indeed, but it might be a very nice improvement.

[tehsphinx]

Right now we have 2 states for nodes:

An exercise that is registered in the config.json but not implemented yet, shows as grey (implemented). It would be great if we could see the difference in the tree. It could show in yellow for example, because it is planned, but not implemented yet.

There are several ideas on how to check/indicate if an exercise is not yet implemented:

• check if the exercise folder exists
• have a todo: true in config.json
• leave the uuid: null

See also https://github.com/exercism/v3/issues/2031

[neenjaw]

style based on the uuid being null would be simpler than adding a new flag or checking the exercise folders, since this graph is build from the config.json and the schema doesn't have a todo flag in it yet.

I am not sure if this affects any of @ErikSchierboom's other dashboard tooling though.

[ErikSchierboom]

As far as I can tell, we've now used null for this right?

[neenjaw]

Yes, the exercise node now changes representation when the uuid is null.