Sky: Make Wizards

[tiller-tolbus]

Through the navigation bar, a user should be able to make a node representing any software they're aware of. With promiscuous software distribution, this is a wide selection.

There are a lot of affordances that can go into making software distributions a friendly user flow. Canonized desk names, default selections, and fuzzy find search to name a few. But we can start with something simple.

There should be a %wizard role that converts a $kook into a UI for making a shrub in a given environment. To prototype this, we can start with an imp/shrub-maker in /home that works similarly to the %files prototype we previously built. Rather than creating a default node of a given type, the shrub-maker should include a %y dependency on /cod/std/src/imp and allow a drop-down of any of the available implementations. The shrub-maker should then attempt to render a UI for the retrieved $kook with the %wizard role, providing a default maker view ala Tree in plain HTML if one does not exist.

[hanfel-dovned]

I don't believe this is the correct solution. A conversion from %hoon to %wizard should succeed for all inputs, regardless of role. To implement wizards in the way you describe, conversions either need to fail if there's a mismatch between the input hoon and the role, or allow for any imp to convert to any wizard, in which case the input doesn't matter and it doesn't need to be a conversion.

[hanfel-dovned]

The %wizard imp's generality means that it needs five things in the POST requests it receives:

• name
• stud of imp
• stud (head of pail)
• vase (tail of pail)
• optional confs

But having to remember all of these and then manually encode them in a form sucks. The name should come from a standard UI element, %wizard should be able to derive the two studs from the URL context, and having to encode the complex data you're sending as a single string that then gets slopped as a vase is very unergonomic.

What a developer actually wants here is to encode their data in the request they're sending in the same way we do for things like node-task-diff. This actually is potentially an appropriate use of the conversion system! %wizard could call these con files in the same way hawk did. (Open question as to how exactly to handle confs here, though.)

This tempts us to think that the solution to the other bit of jank in %wizard—needing to poke a wizard manx into state from some imp—is also to use con files, as tiller suggests in his original idea here. This could be right, but I'd still argue that that's technically not a """conversion""". It's a hijacking of the conversion system to create a mapping from stud to static code at the time of software distribution. It turns out we want this type of mapping to happen in a few different places in our stack, which suggests that what we really need is a system that's specifically suited to that task.

Our rendering system currently creates this mapping via URL-style user input. If you want to view your shrub in a specific way, you type in the path to the code you want to view it with. This might seem like bad UX, but as @will-hanlen's Bookmarks feature reminds us, this is exactly what all of us do hundreds of times a day when we use our browser's URL bar too.

This implies that this viewmodel-switcher textbox should in fact be much more powerful, allowing the user to type in a pith to anywhere within the global namespace that contains rendering code, saving their favorites and defaults as they go. That, then, is also the solution to make wizard discovery: I can make anything in the world as long as I have the path to it, and the UI that's served to me is simply the one that lives at that path. And if this pattern is indeed useful for both viewmodels and wizards, where else is it useful, and what does its generalization look like?