2

I am developing an iOS app, now it's time to do the login screen. Keep It Simple Stupid is the main principle. In line with that, what should I do? What are the pro's and con's of these two designs, in terms of user experience?

Login button

[ Logo ]
[ E-mail input ]
[ Password input ]
[ Login button ]

Once both fields are filled out, user taps a button on the screen to submit the login information.

Keyboard login button

[ Logo ]
[ E-mail input ]
[ Password input ]
-------------------------
[ Keyboard with Go button in lower right corner ]

Once both fields are filled out, user taps the 'Go' button on the on screen keyboard.


I tend to go with no dedicated login button, but just using the keyboard. This seem the Keep it Simple approach, but not much for the Stupid thing..

1

I would have both - but prototype and test the models - we might be surprised.

  • Users will not notice the duplication.
  • But they will notice if their preferred pattern is not there. Many will be made uncomfortable if the spot that there is no action button (even if they don't eventually need it).

Expert review is always useful. But in this case I highly recommend testing the different paths with users (preferably normal users not experts with opinions). Then let us know the outcome on here!

2
  • 1
    This is, naturally, a good practice. But, I do not have the luxury of a test group with unexperienced users. All of them are pretty quick in figuring out that there would be no login button. I looked at some login screens in other apps and have always encountered a login button. That may be a sign..? – Rebel Designer Oct 24 '15 at 8:39
  • I agree but would push harder than good. It's essential for good design. World class designs are all tested. I would strongly suggest you mock it up in your favourite prototyping tool (Pixate, Principle, Keynote, PhoneGap, crayons and napkins) and take it to the pub. (My team has a dedicated UR group of 5 experts and a full lab with test subject - it is indeed a wonderful luxury that we use a lot. But the majority of our testing is still done casually in the corridor and the real world.) Of course, you can over test. If you have a strong feeling about this one... – Aidan Hall Oct 24 '15 at 8:55
1

I think I would provide both and then use analytics to see which option receives more interactions. You could also AB test the removal of the login button to see if there if there are any dropoffs of users logging in. You could even time how long it takes for users find the login button on average, to roughly determine which button is more obvious.

My suspicion is that the login button would be more effective. I think it is easier to overlook the "Go" button on the keyboard and that it would be dangerous to omit a login button.

I think I would provide both. There's no reason not to provide a "Go" button as a shortcut, as the system will provide some form of a return key regardless.

0

I would suggest using both options you proposed. I have never seen an iOS app without a Log-in button, and it is simply good practice to follow the trail that's already been laid down by convention. Consider the following scenarios:

  • User types their username and password using the on-screen keyboard. If the Log-in button is covered by the keyboard, they can still press the Go/Enter key. If the Enter key doesn't work as Go, then this is breaking away from iOS conventions, which may confuse users.

  • If the user somehow dismisses the on-screen keyboard, they would be stuck without a Log-in button. This would be bad. If there is a Log-in button, hey presto, problem solved.

  • If the user is using a physical keyboard, the Enter key is not labelled as Go, and not all users will know that Enter means "log-in". An on-screen Log-in fills this void.

All the evidence points to simply using both the Go key and a Log-in button.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.