How should the sign-up page for a mobile website work?

Question

How should the sign-up page for a mobile website be? For example:-

1. Does repeat password make more sense or less on mobile version of a website. To put it differently, are users more prone to make a typo while typing on a mobile? To me, it looks like there should be more possibility of a typo on mobile than on pc but then re-typing the password is also going to be more inconvenient on mobile. Related question but it doesn't talk about mobile version.

2. Relevancy of captcha?

3. T&Cs and/or Privacy Policy? (which is there on the full/desktop site)

4. Also, anymore things which should be kept in mind while working on mobile sign-up page UI

Answer 1

1. What I have seen as a good practice is entering the password only once, but displaying it is text rather than masking it. This way you can see exactly what your entered and will not have to worry about errors.

2. I don't think captcha is necessary here, not positive on that though. It would be one extra and potentially annoying step for mobile use though.

3. Maybe a link to the T&C?

Answer 2

1. I suspect you're right that mobile users are more likely to make a typo while entering their password. However, I would still have them enter it once as they will likely enter their email correctly and can always reset the password.

   As for masking, most phones already address this issue by having a delay so that characters can be seen before they are masked. It's probably fine to show it as plain text to be certain they can review the entire password.

2. Spam registrations are still an issue with mobile sign-up forms, so you probably will want to use CAPTCHA or something similar.

3. I agree with Matt, if it's possible to put the legal text on another page and provide a link that's probably best. Just make sure they when they finish reading it (one person might do it) the form isn't cleared when they come back. You can use a standard "I Agree" checkbox, or incorporate it right into a large "I agree, sign me up" button to make sure there are no problems selecting it.

4. As with any sign-up form, keep it short with only the essential information needed to create an account. Once they sign in you can ask for more information, just make sure it's easy to get in the door.

Answer 3

1. Also agree with Matt. Unmasked passwords should be fine nowadays even though the perceived security that comes with a masked password shouldn't be neglected from a UX point of view. I know Yahoo! uses completely unmasked password input for their iPhone apps and has done so for quite some time (Luke Wroblewski mentions this in a post written in 2012 which I can unfortunately not find at the moment), which makes me believe it works well. Yahoo doesn't even offer a Show/Hide feature which I find strange as the user might feel uncomfortable with typing the password in cleartext in his/her current user context.
   If you choose to mask the password, thus imposing a re-type procedure, the need for Show/Hide functionality is still there since a type-O in the "select password"-field would make the user first have to retype the repetition, just to realize that it wasn't correctly typed the first time. Then correct the password to the intended one, then retype it again, hopefully correct this time. That would mean typing the password four times instead of just one in the unmasked version.

2. I would do everything in my power to avoid a captcha. As the algorithms for cracking captchas get better better, the captchas get tougher and tougher for humans to break. Feels a bit backwards too, while we're working hard to limit labour and input time, like in the topic of question 1, to add such a time consuming, unattractive element. As stated in, for instance, this article How Good are Humans at Solving CAPTCHAs?, the clearance accuracy can be very low (below 70%) and usually takes 10 seconds or more to beat for an undergrad. And it's probably even worse on mobiles. If technically feasible, I would introduce the captcha for the second or third attempt from the same client, to spare the average user the pain.

3. These kind of texts and content (that has to be there but almost nobody reads), I prefer to put in temporary views, such as modals or popovers. The benefit being that the user will get a strong feeling that the all the data he/she has entered will still be there when the temporary view is dismissed. Taking the user away to another page gives no such promise. Even though the user will eventually find out that it's still there, I think it's nicer to not leave the user in doubt.

4. Error handling/feedback gets a bit more complicated since it's common the screen won't be able to show all fields at the same time. In-line validation is recommended as when the submit-button is tapped, an error might actually occur off-screen, leaving the user unaware of what needs to be corrected before another attempt can be made. Also, make sure to always use the correct keyboard for input. On a PC, you have one keyboard and dropdowns. On a smartphone, you have regular keyboard, e-mail keyboard, numpad, regualar picker, date picker and probably something else I have forgotten. Use the correct method to match the data that's going into the field. This might be very basic, but I get surprised of how many error you see in this area.