I tend to prefer option 1.
In terms of implementation, it also means to stop relying on code generation, which is often a good thing.
It would also add more value to LiveData itself.
Then, we need to be cautious if we go that direction because AWM is known to be an important feature despite its limitations and a very convincing point for the adoption of XWiki.
Proposal 1 is the ideal as it proposes a “spreadshet like” data structuring experience.
However, I don’t agree with the fact that “AWMs should be created from any page”.
The fact that competitors are mixing and matching data types - plain text with structured, one structure with another structure, that structures are so seamless is, indeed, “cool” at demo level but:
it can easily get very rich / bloated / complex / hairy. The whole mixing is easy to handle when you’re the one creating it (therefore the bias of the demo / test), but when you need to consume some that has been created by someone else, the seamlessness removes explicit and it can hinder understanding of the data, impact clarity. Or maybe I am just too old. However, some of our users have my age (or more).
honestly, I’m not that sure that this is done so often (outside of a demo / test usecase) that it’s really worth the cost of doing this and the complexity of the resulting UI.
Proposal 1 obviously doesn’t have the same cost as proposal 2.
Now, about proposal number 2, I’m not sure I understand what are the specific changes from your proposal in terms of ease of use / UX (besides the design things). You’ll need to explain them to me, probably, and describe how each of them impacts the usability and why. Or maybe just describe the problems that you see in the current wizard, screen by screen?
Also, your images for the wizard are missing access to the configuration of a field, which is actually very important for some fields (the date format is configured in there, the fact that a user picker is single select or multiselect, etc.)
I agree. I’m not sure how well this UI would scale when creating complex applications with custom/complex fields. In most cases applications are not created complex, but if we replace the app wizard it will also influence the edition process of apps.
The edition of apps is difficult enough, we don’t need to display the actual entries in the table IMO, there’s enough information.
Proposal 1
How many entries would be displayed in the proposal 1?
The idea of having the more advanced parts of the application creation process in a Additional Configuration optional section is good and I believe it can be transposed in proposal 2 if we’re smart about it.
I don’t like having nested dropdowns. It’s fairly difficult to use IMO, and easily an accessibility bareer if not done very consciously. E.g. people who experience tremors might have the dropdown close on them unexpectedly too often to actually use a mouse here…
Overall IMO it’s way too dense in information. This might look better at first, but as soon as the user starts actually using it it becomes a pain.
Proposal 2
As mentionned above, I think skipping steps 3 and 4 when creating an app can be interesting. When editing, no steps would be skipped. This would be done by replacing the “Next Step” button with a “Finish” and “Advanced configuration” buttons in step 2. The “Finish” button has the primary color to accentuate it, but the “Advanced configuration” is still here for users that understand what they want well and want to do it all in one go.
Why is this info hidden when reaching the step? I’m not a fan of the layout of these blocks. When they are collapsed they look out of place, and when they are expanded they steal all the focus with color. Maybe we should have this info on a help page and have a link in the step explanation?
Same comment as above, the details about data types can be difficult to reach and keep open reliably for some users. How would this dropdown look? What information would it contain?
Note that this contains a change of the looks for the icon picker. In this picker, the user can currently select the icon theme. Is that a feature that we want to disable here?
Is it part of the proposal to overwrite what was proposed here? Should we drop this part from the current proposal or drop the previous decision?
Overall:
+1 for option 2, IMO if we improve things we can have a nicer UX than anything done with option 1. In addition, it’ll also probably require less time spent on it and introduce less bugs…
+0 for option 1, we need to be extra careful with UX when implementing option 1 if it’s picked, to make sure we’re not regressing.
Thank you for proposing all these changes!
Even though I made a lot of comments, I think it looks great overall and I hope we can get improvements to the AWM UX soon
Firstly, thank you for the proposal regarding AWM. I agree that it needs improvements. However, at this point I can’t vote which suggestion I prefer the most, because I still have a question.
In your proposal, do you take into account the current limitation where the AWM interface does not provide a “go back” option? Right now, if the user accidentally names a property incorrectly and it doesn’t comply with AWM rules, AWM will redirect user to this window
Based on the issues identified in this discussion, I’d also want to propose 2 initial proposals. In case you want to dive deep, here is the design page.
