Make ‘email already taken’ more noticeable on smaller screens

Contribute UX

AI-generated summary

The discussion focuses on making the “email already taken” error message more noticeable on smaller screens. jidanni initiates the conversation by sharing screenshots of a user attempting to create an account, only to find out the email address is already taken. The error message appears below the fold, making it easily missed.

jidanni suggests improvements, including:

  • displaying the error message in the visible area of the screen
  • locking the form and turning it red when the asynchronous check returns an error
  • waiting for the check to succeed before allowing the user to proceed

JammyDodger questions the need for improvement, as the error message appears as soon as the email address is entered. However, jidanni explains that the issue is with the error message being displayed outside the visible area of the screen.

jidanni provides additional details about their device, a Chromebook with a 1920x1080 screen at CTRL+0 zoom, and shares a screenshot.

1

Today we shall take a trip with a user who is not sure if he already has an account at some run of the mill Discourse site.

Our journey starts out on a happy note.

Screenshot 2024-03-19 05.16.59
Screenshot 2024-03-19 05.16.59762×650 46.8 KB

It’s all green lights and we’re feeling good,

Screenshot 2024-03-19 05.15.10
Screenshot 2024-03-19 05.15.10762×650 42.3 KB

Wait. The doctor’s report is back from the hospital. I am sorry to tell the family the bad news. And sorry for getting your hopes up so high and then letting you down.

Screenshot 2024-03-19 05.13.45
Screenshot 2024-03-19 05.13.45762×650 46.4 KB

Well, think about it from the bright side. You still have an account.

2

Testing this out, as soon as I enter my email address and move down to enter a username the feedback pops up that the email address is already taken. This seems to be the first opportunity to provide that information so I’m not sure what you want to improve here?

3

Well trust me that I would not have proceeded further one single inch if any red thing appeared anywhere in my field of vision. So maybe the problem is

  • red things occur in an area already scrolled out of the small window of view, even on desktop.
  • red things occur asynchronously, not always fast enough for the user to see before he has scrolled them past the small window.

Also the moment the asynchronous check comes back with bad results, the entire form should lock up and turn red… No point in the user continuing to fill out the form when it is already doomed for failure, and the form already knows that.

Or, perhaps

  • just wait for the check to succeed before allowing the user to go on to the next question. Surely the connection between the form and the database is higher bandwidth than between the form and user, so no need to allow the user to fill in the form so fast.
4

Could you add some extra detail about the device you’re using (inc. screen size) as well as any zoom/text enlargement you may be applying?

5

Here’s a pristine 1920x1080 screenshot, taken on a Chromebook at CTRL+0 zoom

c
c1920×1080 123 KB

P.S., there on https://community.opencellid.org/ if you click Log in with GitHub you get 404. And odd, those three side buttons, one is Log in, the other two are Sign in.