While working on reworking rules to support “the new YAML” and DSL handling, I’ve gotten to the part where I need to make the Copy File Definitions button.
It turns out that it’s more complicated for rules than for Things, Items etc., so I need to make something more for rules than what exists for the others.
My first idea is to present a “sub-menu” - but as usual, F7 is my enemy. Not all options will apply to every rule, so I’ll obviously hide whatever doesn’t apply. I haven’t made any of the logic yet, but that part is fine - I know how to handle that. This is about the layout. I want to avoid using manual CSS styling if at all possible, because I want it to work without a lot of hassle with the different “themes”.
If possible, the different “YAML options” would probably be best served as another sub-menu of YAML, but I have no idea how to do that.
The considerations I have done this far are:
I went with f7-popover because it seems to be the only component that can clearly show what component it “refers to”/“is a sub-menu of”. The other component types just show up on the screen with no apparent relation to the button that triggered it.
I think there’s a need for a header of some sort, to make it clear why you’re presented with these choices. I’m not “sold” on the text being “Select format:”, but again, at this stage, the layout is the focus.
I need to somehow present formats that can’t be exported to, because I want to have a way to show the reasons why the rule can’t be exported to that format. The idea was to make the non-compatible options and red, and then open a dialog or something that shows the actual “errors” if clicked. This doesn’t really work at all as it is now, the red text does a lousy job at signaling this. It would be better, I think, if the button itself had a different color, but:
I went with list buttons instead of buttons, because F7 does this horrible capitalization of buttons after the F7/Vue3 upgrade. As bad as this is for normal buttons, it gets completely terrible for longer texts. A normal button could be “inverted” and have the button colored instead of the text, but I’ve found no such option for list buttons - yet they are needed to avoid the horrible capitalization.
All in all, I’m so “unsatisfied” with this starting point that it feels like I don’t even know what to try to “tweak” to make it better.
I’m traveling at the moment so I can’t give the most detailed help. But just looking quickly, I’d say a couble things:
instead of the block above the list, I’d probably just put a list item in the first list slot and make it one of the list group header items. That should be the easiest way to fix the ugly header at the top.
In fact, I’d probably try to sort the list and use two group headers. The first group would be titled “Supported formats” and then the second group (which could all still be red in addition to be sorted out) would be “Unsupported formats”. This is a little more work under the hood, but I think matches the clarity you are looking for.
Just for information: I’m not afraid of building “complex” logic, sorting or whatever, the thing that frustrates me to the point where I give up is trying to get a reasonable layout from F7. Their examples are mostly terrible, and I just don’t find “a catalogue of options” for solving a certain task anywhere. It feels like I just have to randomly look around at F7 examples, existing code and wherever I find anything, and hope that I stumble onto something useful. After stumbling for a while, but never onto something useful, I lose hope…
If anybody has a suggestion for somewhere in MainUI where a “similar situation” has been solved in some way, please give me a hint. Looking at how that has been done can be of great help. I’ve looked and looked, but not found anything. It seems that most “sub-options” open a new page or dialog, which I think is bad UX and requires a “back”/“close” button with all the problems that brings into the mix with the broken F7 router.
The capitalisation might be implemented in CSS, so it should be possible to override it. In case it can be done, I’ll do this globally. I also dislike the capitalisation, but never cared enough to actually look into it.
Argh, it seems that popover is useless, because it can’t handle that the size is changing. Forget the styling of the buttons in this example, just look at what it does with the arrow to the “parent element”:
It even expands outside the viewport without “caring”. It is always anchored in the top, regardless of where the “parent arrow” is, so it simply can’t be used when you need a sub-sub-menu. Argh!
That’s exactly the kind of thing I was trying to avoid, essentially another panel that “slides in” over the current page, which removes all “logical reference” to the button that triggered it. I’ve also experienced that this happens outside the visible screen, so that things don’t appear to do anything at all. It’s just what I call “a terrible UX”, but it seems like the only thing that’s “possible” with F7.
It didn’t use to be like that, and I feel like I’m being treated like “a simpleton” when presented with upper-case letters like that. It’s embarrasing and slightly insulting. But, worse, it’s completely unreadable for longer texts.
