The Recipe/Bag UI needs to be redesigned

[Arlen22]

We need to redesign the UI for bags and recipes. All suggestions are welcome, no matter how bold. We really need to rethink how we present the bag/recipe UI. I'm really not happy with where it's at right now, and all of the issues listed below highlight different parts of that frustration.

I'd even be completely happy to go with a different UI library if we need to, although that's not the root of the problem. So really, no suggestion is too bold here.

I'm not very good at designing user interfaces. I'm good at the code, but deciding how it should look is where I struggle. So since this is an open-source, volunteer project, rather than sweating it, I might as well just open it up to you all to come up with a good UI.

This is in relation to the following issues:

• Who created the Bag?? #112
• Question: How do I set up the server so that it is readable for anonymous users? #111
• Admin and User UI Should Have Different Header Colours #107
• Recipe ACL seems to inherit bag ACL setting. IMO that's wrong #106
• MWS Management UI Body Needs Colouring and Icons #105
• Why are plugins configured with recipes? #103
• New Recipe PopUp Shows a lot of Confusing Text #99
• New User - New Recipe - Has no bag to add #98
• Logged in as User. Click Recipes. URL Shows /admin/recipes #97
• http://localhost:8080/wiki/mws-docs timed out -> no redirect #96
• MWS /wiki/docs seems to be outdated #101
  • This problem is easy to fix behind the scenes, we just need to figure out the best way to add it to the UI.

Proper error pages

One of the changes we're already making is that the UI will be shown if there is a 404 or 403 error when accessing a wiki. If the response was going to be an html page, the admin UI will be shown with error information instead. This is accomplished by inserting the error response into the HTML page, not by a redirect, so the page can be reloaded to try again (if the user fixed the problem in a different tab).

Docs

Both TiddlyWiki and MWS are distributed with their docs. These docs should be easily available to the user, but not as a recipe. They should probably just be moved to their own endpoint. This is easy on the backend because the docs can be packaged as a plugin, and then we can just use the existing code to serve it. This solves the problem of keeping the docs updated.

Bag Plugins vs Recipe Templates

Remember that a bag always reads the recipes in a stack, but writing is where we have some flexibility.

Setting TW plugins on bags seems like a reasonable idea, considering that all custom plugins will also go in bags. The other option is recipe templates. We could create a recipe template feature which allows the user to insert the recipe bags at a specific spot in the stack, so the recipe would have both overlay bags, and underlay bags. Overlay tiddlers could not be edited, obviously, and underlay tiddlers still act as the default value when you delete a tiddler.

Editing tiddlers in multiple bags

I think this could be accomplished as long as we have a definite way to assign the tiddler to a specific bag. The recipe settings would need to mark the bag as writable, so you could have more than one writable bag in the recipe. The client could choose which bag to write to in that case.

[MagicJF]

The problem IMO is that Bags and Recipes model is exclusive of MWS, people don't usually think in this terms and can't abstract/transfer the functionality from other experiences.

I suggest that the UI provides accompaniment within all possible forms, to mention some:

• Informative clues:
  Enancement Display Recipes #33

• Self explanatory mnemonic icons:
  

same for ACL, which is an additional layer of cognitive load

[bobjoe12131]

Some kind of graph UI like https://tiddlymap.org/ and https://flibbles.github.io/tw5-graph/

[MagicJF]

Agree, according to Gemini graph theory allows to easily represent this kind of complex relations, a UI made of the just launched TW5-Graph sounds good.

I would not reinvent the wheel here, we can copy what works for large environments.

This style of graphs (AWS documentation) combines my previous suggestion of mnemonic icons within a clear directed property graph

Edit:
This Resource was created to solve a very similar problem

[bobjoe12131]

a visualization of a network of a user, their recipes, and those recipes' bags

edit: actually, the arrows for primary bags would be highlighted instead of the bags themselves, because if a bag is primary in one bag and secondary in another, it would conflict to have the relationship shown on the bag.

[bobjoe12131]

Using nodes, it would be easier to visualize the connections, but how would edits of basic data happen?
I would like to use HTML / wikitext UI for forms in the graph. Something that can be moved around on the screen and that still works with the other nodes.
An issue with the engines with draggable nodes (at least in tw-graph) is that they use canvas...

a visualization of editing properties of users with text boxes

---

(edit)

You start a draggable space with a few core objects: Users, Recipes, Settings, etc. You can right click on one of the objects and drill through the context menus. You could right click on Recipes and go to Recipes/By Name/mws-docs/Owner/User. Clicking User puts an object of the owner into the field. Clicking /.../Owner/Change opens an html form modal in the center of the screen. Clicking /.../Owner puts an object for that path for easy access.

---

I would also like a raw, html forms version of an interface with the server as an alternative to the UI with js.