Redsign rule builder UI #19383
Replies: 3 comments
-
The UI is absolutely gorgeous. No notes - amazing. The flow of things is gorgeous and it is such a familiar and time tested paradigm and it makes it so clear what is going on. I love it. I don't know how you reorder steps - if I add a new column at the end and then swap that column with the first column - what happens if I move the swap step up one spot? You're going to introduce the ability to easily setup invalid rules and the trigger situations with ambiguous semantics. The way it works when you edit a rule now - the rule at that step has a list of columns available at that step - so that is going to be more stable and avoid this problem I think for the most part. I just retried this. I took some data, I sorted it, split the rows (reducing the number of columns by one), and did another sort. The sort options in the before step are not the same as the sort options in the second step when I go back and edit them. The valid options for a rule are restricted to what is valid when the rule is applied. At first glance, I guess everything under the current "rules" button will have problem but everything under the "filters" will not. If you want to make filters reorderable - that would be fine I think but the "Rules" worry me a lot. I would encourage you to not try to make things draggable and re-orderable to keep the component more stable and less error prone. If you do insist on going down that route. Are columns referenced by index or name is quickly going to become a concern we will need to care about - and the correct answer is going to explode the amount of testing we need to do I think. My guess is if I want to add a new column before some earlier step - every rule needs to have all its references adjusted in sequence which is going to be very picky and I'm not certain it is the correct choice every time. |
Beta Was this translation helpful? Give feedback.
-
I think re-ordering could help a lot in creating re-usable rulesets. Currently it can be tricky to adjust some rulesets, without rebuilding them. Regarding invalid state, it is also easy to create this with the current interface, by deleting or editing previous rules. I hope reordering can make it easier to fix invalid rulesets and also to show where they break, by marking properties which became invalid. I wouldn't want to encourage reordering as a default, and add new rules at the bottom. However I think that enabling reordering as an option can make the rule editor much more flexible. Being able to adjust previous steps easily encourages feature exploration and user experimentation, making the rule-builder easier to learn. |
Beta Was this translation helpful? Give feedback.
-
It is a solid point about deleting rules. I think the more safe and more technically correct fix would be to remove all the subsequent structure affecting steps if you remove a step - I'd be happy to implement that as an alternative to avoid the ambiguity and semantic questions this approach will create. The point about letting users explore it to understand it better doesn't click for me because you're making it more complex. Users will need to be able to explore because it isn't clear what the component should do anymore IMO - even to me. I also reviewed all the various Rule Builder issues and I found a lot of solid requested features and none of them are this. I think you're sold on your path though 😭 , I know what you do will be elegant and the static semantics and legibility will be so much clearer given your mock up. |
Beta Was this translation helpful? Give feedback.
-
I have thought about how to re-design the UI of the rule builder to be simpler to use and understand.
To achieve this, I want to remove all nested and hidden options, and have all rules editable and reordarable on a top-level in the rule builder.
Rules should be duplicable, deletable, draggable, and have re-order buttons. Controls for these can become visible on hover and inner focus.
Rules should also be insertable at any point. Additionally, column definitions should be clearly only placeable at the end of a set of rules.
To implement these requirements, I would like to use scratch-like building blocks for the rule builder. Below I added a mock up of the rule builder from the following GTN tutorial: https://training.galaxyproject.org/training-material/topics/galaxy-interface/tutorials/upload-rules-advanced/tutorial.html
I hope this gives a good rough idea of the direction I would like the rule-builder to head in.
Beta Was this translation helpful? Give feedback.
All reactions