revolution
revolution copied to clipboard
modxcms
Confusing UI in Extended User Fields
bobray created Redmine issue ID 10518
It's certainly obvious once you figure it out, but it took me three tries to make it work. It's not clear at first what you're supposed to do. The fact that there are blank entry fields on the right suggests that you can create a new field there, but you can't. The best, solution, IMO, would be to have it create a new field if you enter the name and value at the right and click on "Set" and there is no existing field with that name. That way it works no matter how you try it.
@BobRay Does this still need a fix?
I agree that your suggestion that the UI needs an update, but it seems the sky has not fallen down since 2010 when this was created :-)
No, but I suspect a lot of users have been confused. ;) I would say it still needs fixing. Otherwise, it's likely to persist into future versions.
While we're discussing that panel, there should probably also be a button to add any new extended fields to all other user records. It's a real pain to do them one-by-one.
I started looking at the oldest issues here and came upon this one; it's one that still warrants addressing IMO. I've always thought the whole design and UI for the extended fields was not so great. It's certainly more difficult to work with than it should be.
One thing I'm curious about: Is anyone using containers for the fields they set up and, if so, why? If it was possible to lose the containers feature, it'd be relatively easy to set up a much more intuitive UI for this area.
I suspect little attention at best has been paid to this in a long time. Can you describe what the improvements would offer?
A couple scenarios I can think of:
- If containers were taken out of the equation the "fields" could be displayed and managed in a simple grid having editable name and value columns
- If "containers" were deemed necessary but could be limited to just one level (no nesting), we could manage via a grouping grid where the "container" (probably better identified as a category or field group) could be a third column (perhaps managed by a dynamic editable combo whose store is populated by the unique values of its grid column)
Wow, 2010???
The improvements I suggested way back when would result in less confusion for people trying to use the extended fields.
Yeah, pretty crazy! But it might point to the possibility that (figuratively) no one uses this feature, perhaps because it's so unintuitive. I guess ultimately the better way to do it is for devs to extend the user class and add fields via a custom table and their own form implementation.
Totally agree with https://github.com/modxcms/revolution/issues/10518#issuecomment-1179626115, the tree interface is just confusing (trees are good for resources/elements), the regular grid of items is much more logical and clearer.
