I quite like it as is. though the two green "Sign x" buttons and forms are slightly jarring - could be improved if the default was to show a sign-in form, with a "New user?" link that changes/expands the form to become a sign-up form.
Does anyone have tips for displaying errors on the signup form? I'm stuck for !4527 (closed) for best implementation as the errors returned from the form POST are bullet points above the form, but is this a good idea for these AJAX realtime validation error messages as they occur dynamically?
I am not fan of splitting login and signup pages. We intentionally made it one page based on user testing because user takes hard time finding "sign up" link.
Hi @dzaporozhets about splitting. Have you considered that when you send users from a website to register to a gitlab instance, they currently might be overwhelmed by the choice (and typically enter their details in the login section instead of the register section)? I've been hinting at this here: #17518 (moved)
Would it be a consideration to have the main page have both, but allow alternate pages that only have one or the other?
Also just noticed that we use Sign in and Sign Up on the sign_in page but Register and Log In to post comments.
Its harder for users to distinguish between Sign in and Sign up quickly. Register and Log In is easier to distinguish and could provide a faster log in experience.
We should also make it clearer on this page that we can signup using external services. At the moment, the wording suggests that we can only sign in through Oauth.
Moreover, as the oauth box is very close to the sign in box, that can be misleading.
I redesigned the page to look more like GitLab and I took the suggestions from @tauriedavis and @regisF.
Version 1 - Text fields as boxes
Login form - Empty state
I combined the login and register panels into one. It's true that this hides one of them at all times, but the original layout was too cluttered and it was very hard to identify all the different elements. This cleaner layout will allow users to quickly find what they're looking for.
The OAuth icons now have their own section and the wording "Access GitLab with"refers not only to logging in any more.
Login form - Filled out
For the text fields, I separated them into individual boxes so we can have the title of the field as an individual element. This mean that the title is not lost when the user starts typing and they can still identify each element in the form.
Login form - Error
Separating the text fields also allows us to show an error message right below the element it refers to, which means the user no longer has to hover over an alert icon.
Register form - Empty state
We can now show indications for password generation outside of the text field.
I changed the color of the register button to separate it from the action of logging in.
Register form - Filled out
2FA form - Empty state
2FA form - Filled out
Version 2 - Text fields as lines
Login form - Empty state
This is a more modern look. Text fields originally show the title as a placeholder.
Login form - Filled out
Once the user starts typing, the title moves up and the user's content takes its place
This looks awesome @cperessini!
Really like how you've combined the register and login forms, and the change to the OAuth wording and icons.
While the changes to the text-box text are also awesome (personally prefer the first version), however I'm not sure how well the design sits with regard to UX used throughout the rest of GitLab?
@dzaporozhets About separating the page there is an issue which I've reopened #17518 (moved) Do note that this could just be an anchor to the page that helps display the relevant form (like /users#register or /users#login).
@cperessini Aweeeesome! I can't wait to see the final designs getting implemented. 😻
There is an MR that will likely be merged today that adds another UI element to the registration form and I expect you guys can come up with a better pattern than me.
!4773 (closed) will be dynamically checking the username is not already in use. There is a chance this will also be added for checking the email addresses as I'll open an issue about that today.
@toby-mole We use text fields like the ones in version 1 already (see profile settings). Or did you just mean the other ones?
@lbennett That's great! Can you make that feature detect when the user is done typing? It can be obtrusive to get error messages while you are still in progress, see from the article I linked
Use inline validation after the user fills out the field (unless it helps them while in the process)
@cperessini Indeed we wait for the user to stop typing, in a sense.
This works by running the validation Xms after the user clicks a key. But, if the user presses another key before that Xms is complete, the timer restarts. Therefore, the validation will only show when the user stops typing for a total of Xms.
Now, lets say you've written half of your intended username, and you pause for Xms before typing the rest because you're thinking of what to type, then the validation will kick in before you've finished typing, but I think the majority of people know what they're writing in a username or email field before they even click on it so this shouldn't be a problem.
Currently we do show a little spinner as soon as the user starts typing, all the way until they stop typing and the validation is complete, so it would be wise for us to drop this spinner with the new UI.
Do you think it's possible that we move Don't receive a confirmation email? Request a new one to the place below Access GitLab with... box?
My concern is the text between two boxes is possibly easy to be ignored. And if the similar functionalities (Register/Sign in/ Access Gitlab with..) are closer to each other, that would be better. 🙂
Login form - Error
What do you think if the input field also has highlightwhile something error? 🙂
@lbennett Great! I think the spinner is good, but maybe it's better to show it once it actually starts checking for availability.
@tauriedavis I really like that, it makes it more obvious and looks great. We don't have other elements like that one though, is that a problem @dzaporozhets?
@hazelyang👍 to the error highlight! I see the problem of the email line being overlooked, but I think it should be close to the form where you use your email rather than the OAuth one. @tauriedavis do you have an opinion? 😁
@lbennett It might be a little much. If it doesn't take you too much effort we could test it out, though. I think something like the Draw option, but it needs to be able to keep going once the line reaches the original corner, because we don't know how long it'll take to check.
Apart from that, it made me think that if the username is available, we should paint the border green.
Yes, I think it would be too much. Also, the spinner makes it look like something is loading and I should wait for it to finish. It would be better if there was a spinner only if the validation is taking too long or hanging.
@cperessini Are we still using flash messages (bright pink, at the top of the page) to display server responses (e.g. "Invalid password")? Or are we wanting to present those errors in the same style as other validation errors (red text beneath the relevant fields)?
Another way of asking this: is it important to distinguish visually between errors that occur before form submission and errors that occur after? I can see why it would be good to present errors in a consistent style, but I could also see that being a source of confusion.
@brycepj Giving all errors the same style is good, so let's use the red text beneath the field for all of them. Plus, we didn't have a way to show errors inline before, which is why I think we were using flash messages.
@cperessini We're not currently discriminating between an errant password and an errant username on the server. In both cases, the users receives "Invalid Login or password." I'm not sure it would be simple to change that, and there may be good reasons to have it that way.
0. Am I correct in assuming that the current design specifies error messages for these fields? Perhaps the intention may have been only to display error messages for the username field, when the current username has already been taken?
Is it important to have more specific error messages in this case? If so, I will probably need to pull in a backend dev to assess the work that needs to be done.
If not, where should the error message go? Below the username field, or the password field?