Hot answers tagged

11

With all the concern about the security implications of someone "looking over the user's shoulder" I think we forget the actual user experience of showing the plain password. A password is usually something you don't want known and most often it has personal meaning to the user. The obfuscated way of showing passwords re-enforces a sense of security to the ...


5

In short, it's because you usually sign in with a different website that doesn't have those elements. Many logins are handled using OpenID Connect/OAuth 2.0. It works like this: you trigger an action that requires signing in (eg. you click the log on button, you try to navigate to a protected page), the website you're using redirects you to their ...


5

The use case for sign-in and registration are different. When you're signing in you know your password (unless you've forgotten it), so the main reason for using plaintext is to prevent typing mistakes. However when you're registering you're entering new data rather than confirming existing data, so the potential impact of a typo is greater. This is why ...


5

Smashing Magazine also covered this in their article: http://uxdesign.smashingmagazine.com/2011/08/22/new-approaches-to-designing-login-forms/ At the bottom is the example of facebook who give you a plain text password field if you fail to get the password right on mobile login. The obvious one is people looking over your shoulder, but this would actually ...


4

When you sign up with facebook, you're essentially just creating a profile on the local site (Airbnb in this case) using data from your facebook profile. So something like name, avatar, and location. When you sign in with facebook you're authenticating yourself using facebook. Although the two are related, they are essentially different actions, and so in ...


4

The short answer is - yes. But there is no actual research in open access, however there is a range of material that contains some of this information. Some research based information available here: https://conversionxl.com/blog/password-ux/ https://conversionxl.com/blog/error-messages/ You might find this useful: https://freshsparks.com/user-experience-...


3

I think the main purpose of sign up page is to make sign up, adding navigation can disturb user from completing that. that way I think most many companies hide their navigation.


2

The risk of removing the sign up is potential user hesitation/confusion. If users only see "Sign in" -- they might think, "But I never created an account! Where do I sign up?!" That said, I think it would be really interesting to do think-aloud usability testing and see how many people actually have an issue with only seeing a "sign in". My gut feeling is ...


2

The length of a user staying logged in until they are automatically logged out depends on the sensitivity of the data. While it is perfectly fine for a bank to sign out their users after 5 or 10 minutes of idling, this would be a very frustrating experience for a social network or online shop. There is no direct rule and for as far as I know not even a ...


2

To me, Google's two step sign in seemed like a step backward in usability when they first introduced this extra step of clicking 'next' to enter the password. However, I realized that this solves a very important problem for G Suite users. While using Google's apps that are configured for companies/organizations, the employees or organization members had to ...


1

The purpose of a sign in journey is to get the user to sign up. This is the only goal/requirement of the journey as a whole. Any distractions risk the conversion (in this instance a sign up of a user). If a user is distracted by something in the navigation (etc) or any other visual elements the conversion is lost. It is way more valuable (in the sign up ...


1

It may be interesting in some cases to place two inputs side by side but in your second example juxtaposed inputs doesn't seem to be related. About validation texts, I guess it's more interesting to put them under the input than on the right. So you can have the same layout if there are other pages elsewhere on this project without enough space to the right ...


1

Neither really. You want to focus on the first input field if there is such present, but not the button. You can have button of two different colors as per your example, but only for the purpose of highlighting the difference. As per your comments, there is a solution to this (please see example #1), but if the sign up form is rather big, you want to ask ...


1

My guess is that the cybersecurity folks have more say in that case than the UX people. Transitioning from click to keyboard to mouse takes a lot of mental energy and doing so multiple times separated by a page reload is a good argument against that practice from a UX standpoint. However, I would guess that companies like Amazon and Google are doing a lot ...


1

Users would be confused. What would you ask them? "Sign in or sign up"? Users who are not signed up will not understand why you ask them to sign in. Users who are signed up will not understand why you ask them to sign up again. Of course, technically you can reuse your code in your application, if you wish. E.g. you can reuse CSS for email styling in both ...


1

I think the most simplified way for a double sign-in is to remember the user and just ask for a password. It's a common pattern I've seen across some large sites (Amazon for example) This pattern as a whole is much faster and causes a lot less friction when forcing a second sign in. Facebook do it extremely well, they make it personal with my name and ...


1

Often sites require a second sign in if they notice odd behaviour from your account. Facebook does this if some of your posts have been marked as spam. At times they ask you to fill out captcha as well to ensure you aren't a bot or a bot hasn't taken over your account. While I have never noticed your issue, I am lead to believe it is one of two things. The ...


1

Your description does not indicate any reason why a common screen can't be landed on when the account has not been verified. This is rather straight forward on the backend and is a very common flow for sites that require e-mail validation.


Only top voted, non community-wiki answers of a minimum length are eligible