Registration redesign: feedback on the registration form update and ideas for improvements

Hi! Starting on XWiki 16.10.0, we have the updated registration process. This update changes a few things. Among those, the registration form has been updated. The same registration form is used by Admins when creating new users. We forgot to take this use case into account in the first discussion about the changes. This lead to an admin user having a worst experience with the updated form @Redhorse it would be great if you could read the info I shared on the ticket and help us understand better what is your need.


The main issue is that the First and last name are not the first fields in the form anymore, so it makes using the autocomplete feature more difficult to use. Before, filling up the first and last names would create users with first, last and usernames filled up. Now, it’s still the case, but the order of actions to do this is not natural at all.

IMO your issue could be solved mostly by triggering autocomplete as soon as both first and last names are filled up, not just when we focus the username (I kept it the same as before but it’s not in the standard user flow anymore since the username is before the first and last name fields, it’s more difficult to use).

I don’t think that putting the first and last name at the top of the registration form would make sense. We decided to move them down for regular users and IMO they are on average even less important for admins creating users.

Don’t hesitate to share your experience with this UI and any ideas you have to make it more usable for everyone!

@tkrieck It’d be great to have your idea on this design problem :slight_smile:

Thanks in advance for everyone contributing to the discussion!
Lucas C.

This proposal/change was made in the context of a single user joining a wiki, where an autocomplete is less important than for Admins. Sure, it’s a convenient feature, but for that convenience to make sense, we must put less important fields on top of the form registration, this is how the old design works.

Now for Admins the scenario is somewhat the opposite, the convenience of the autocomplete is more important than the less-than-optimal field order.

Would it be possible to use the CSS order property to change the form layout based on the Rights of each user accessing the form? Moving First Name and Last Name to the top of the form. The only downside is that this might cause accessibility issues with tab order, but I am not sure.

I think assuming all Admins use the autocomplete is wrong.
Some Admins do so, so we need to find a solution to avoid degrading their experience with the changes.

I don’t have first hand experience, but I think that if I wanted to create tens of users for my wiki, I would let them fill up their personal info, and just set their username + password so that I can share a blank slate account with them with the minimal amount of time spent on my end.

See order - CSS: Cascading Style Sheets | MDN , it seems like it doesn’t work well with assistive techs (which is somewhat expected since CSS should be for styling and not updating semantic on the fly – the order should be determined in the DOM). If we agree on it, we can definitely use a condition on the velocity template to make it change field order depending on context.

Another downside is that it would make the task a bit longer for Admins who only fill up username+password.


Thanks for your feedback!
Lucas

Good to know that this can be done in Velocity. I understand that these types of switches might not be the best practice from a code POV, but I think that’s a trade-off to keep the same form for admins and end-users.

Let’s see if anyone else chips in =)

Thanks for the reply.

Some notes about the discussion we had during the dev meeting:

  • We should at leastr add a toggle for admins to enable the latest changes
  • If the first and last name infos are not important, we can just remove them from the form.
1 Like

Started Registration form: settling on a default state and breaking changes with a more precise topic of discussion. Marking this discussion as resolved.