@BenHenning -- maybe post your mocks here at some point?

Here are the second versions of the hand-drawn mocks for the first major iteration of the collection editor. @amgowano, @seanlip , and @xtyang have all contributed ideas and/or reviewed these.

A few quick questions:

1. The explorations shown here are all in a line. How would this work if I had a branching dependency tree?
2. When you say "automatic skill generation and assignment" do you mean that each line will be regarded as a skill that is provided by the exploration on the left and required by the exploration on the right? If so, what are these skills then used for?
3. It seems a bit odd to have a left-to-right direction of progress here when in the state graph progress is made top-to-bottom.

Thanks for the feedback @jacobdavis11.

1. No branching will be supported in the initial collection editor. This functionality may be added later.
2. Yes, that's correct. The skill will probably have the name of the exploration being completed. I think skills are going to be more useful once we figure out what branching conceptually means in a collection, as well as when we extend collections beyond just organizing explorations (and move into concepts like having a review section and badges for completing parts of the collection, or even linking collections together). Much of the more powerful uses of collections are more easily possible with skills. Since this is the MVP of the editor, skills will play a backseat role, for now.
3. Is odd significantly bad in your opinion? If not, I lean toward keeping this. The exploration state graph should be vertical because it's sharing the horizontal screen real estate with the state editor, which takes up a lot of room. Also, the state graph can be completely ignored when creating an exploration, whereas this graph is the actual editor. I'm not entirely convinced whether the graph should go horizontal or vertical, but horizontal makes more sense to me initially because that better uses the screen real estate. I do not think this is a permanent orientation for collections, especially once branching is introduced.

@amgowano, can you break down the work needed to complete this task? You're tackling some of the features in #1687, but it would be great to see an enumeration of all the work that's needed. If you can, please group the items into buckets representing PRs. For instance, in #1687 you have implemented the collection node graph with deletion functionality and removed the current node list. #1687 should also include displaying the collection nodes in their play order and updating the sample collection YAML to have a linear progression. The other tasks needed to finish this can be split up into future PRs.

Thanks!

Implementation breakdown:

1. Implement a visual layout of the nodes.
   • Update the UI to display the node in a linear layout according to their play order.
   • Update the sample collection YAML file to have a linear regression.
   • Implement a delete functionality on each node.
   • Implement the shift functionality on each node.
2. Implement addition of a new node to the list.
   • Change UI to match the mock.
   • Implement addition of a new exploration.
   • Implement addition of an existing exploration by searching for them.
   • Add the ability to search for existing explorations by filtering only those that the user has created.

Hi @amgowano, any updates on this issue? Thanks!

This is currently in progress with #1687 and #1928.