Do I really need a login button?

Question

We've been having a discussion in the office surrounding a login page we're developing for a new web application. The web application is in intranet-based application, and is mainly used by users who have to use telnet applications as 80% of the daily job.

I created the initial page design in Photoshop, which we discussed and all approved. However, now I've given it over to one of the other developers to start building, he has noticed that there was no login (or other) button on the page - it's simply has two fields; one for username and the other for password. After querying it with me, I stated that it was intentional, as I didn't see the need - most people would just press enter anyway, as that's what they have to do in their telnet application. Then the discussion started...

There were several points made in-so-far as "if there's no button, they won't know what to do" and "they will expect the button and will raise support calls over the page not working". There were even suggestions that the users would just "sit there" not knowing what to do.

Now.. my question is: Do users really need a login button?

I'm genuinely interested to learn what sort of percentage of end-users would be able to cope with a simple login page that required them to press enter after entering their details to continue. It's important to note, there wouldn't be any on-screen prompt to press enter - they would see a tool tip over the password stating what to do, but that's it!

(Exclude mobile users from the fray - simply targeting run-of-the-mill desktops and laptop users :))

An example of the login box:

Answer 1

Ultimately it's probably not a good idea to go down this path without serious testing because of user expectation based around existing conventions.

That's an important point, because what I'm taking away from your description is that this is currently untested and you designed this UI under the assumption that your users would understand. This is generally a bad idea: always get feedback from your audience, especially when you're trying something new, and especially in a core area like login.

Your telnet argument is something to take into consideration, but also understand that you're building a web app here and you're likely going to be dealing with user expectation of web apps, not telnet. Your brain shifts between contexts: when you use a web app, you expect to single-click on items to follow them, whereas in desktop apps, you might expect to doubleclick. Recognising the mental model that users have when they're using your web app as opposed to a different space like telnet is an important aspect of designing a user interface.

There are some patterns emerging that are starting to diverge a bit from the standard "log in or sign up" convention, however. Each of these faces the same challenges: what do users expect and how do you build trust, expectation and discoverability around some of these new ideas? For instance, StackExchange employs single sign on, which can be confusing for users who aren't familiar with that pattern. Amazon (successfully) integrates registration and login into one form, although it remains to be seen how effective that pattern would be on other sites.

The point is, when you break convention, you're heading into unfamiliar territory and you need to realise the effect that can have on people. If you're thinking about doing this, I'd recommend grabbing some "run of the mill desktop and laptop users" from your immediate environment (say, the office manager and someone from the office across the road) and asking them to log in. You'll learn a lot. You might learn that your initial assumption was correct. But at least you'll have the data to prove it, instead of just the assumption. :-)

---

Edit: As you mentioned in a comment in an answer to your question on Programmers, "questioning the validity of the convention" is a good starting point, but you should make sure your answer to that question is founded in data. Anyone can question conventions, but conventions have become conventions for a reason: they're effective solutions to the problem. Moving away from those without good reason (and good reason in the UI world means having data or some form of metrics) will usually do more harm than good.

Answer 2

At work we have a staff development system that only displays the login button if you are browsing in Firefox. Every time a class is held, our helpdesk receives calls from people who are unable to log in. Every call has to do with the fact that they don't see a login button. We now have to go out of our way to tell the users they have to hit enter to log in.

Your users may be a little more computer savvy, but my guess is that you will have plenty of support calls about it if you leave the button out.

Answer 3

I really like Rahul's response, but I will add my own 2 cents. I've grown extremely hesitant to use the Enter key on any Web form due to uncertainty about its default function. I'm just not sure what it's going to do! Some people aren't as careful with their development efforts, and they fail to specify default buttons for a form properly, confusing users who do press enter out of habit.

As a result, I've trained myself to hit Tab and then Spacebar, expecting that the next control after the password box will be the Login button (or possibly the Save Password checkbox), because Spacebar is effectively the same as clicking my mouse on a button without having to take the time to lift my hands from the keyboard and position my mouse over a UI element.

The point being, I suppose, include a button, but make sure it's the default action of the form, and that it is properly set up to be next in the tab order after the password box. This way you satisfy both sets of users.

Answer 4

If you have any blind users, the expectation will be a button of some kind. Otherwise, there will be no indication as to how to log-in, unless you somehow detect a screen reader and allow a button in this specific case.

Answer 5

Have you considered users that don't have a physical keyboard? People that use an iPad or a phone with a touch-screen?

Answer 6

What about the option to let users save their login information? Would it still be reasonable to omit the login button? That way as a user I would have to move my hand from my mouse to the keyboard to login and then back to the mouse again to further interact with the application.

So I'd say: yes you need one.

Answer 7

When it comes to elements that are present in each other web applications, you can try to find a pattern resource and see what they say: http://www.welie.com/patterns/showPattern.php?patternID=login

"Users can use the TAB key to go from the username field to the password field and press ENTER instead of selecting the 'Log in' button".

Usually, actions are represented though buttons/links and additional keyboard interaction is secondary and seen as for 'advanced' users.

If you're concerning about usability/accessibility reasons, then you should have also a button: this way users could interact with the form only with mouse/pointing devices (copy/paste the entries | press the button) or only with the keyboard.

When I first read your question I though about the "Search box" case. http://www.welie.com/patterns/showPattern.php?patternID=search The pattern say it should have a button, but in time (production usage) that button became a magnifying glass icon/button in the right corner of the input, and after that it advanced into an identifying left aligned icon. With the advancement of trends (Google Instant) the search button becomes less and less used (but still present).

There is a difference between Search and Login, first of all because Login requires 2 inputs so if you would try to add for example a Login icon, instead of the button (just like the Search case), where would you put it, in the first input, in the last, or in both?

As a developer, the obvious answer is in the last, because every user should have entered the username, then the password and then hit enter. So in your case you listen to Enter for the last input, but what happen if the user is pressing Enter in the first input (username one)? From consistency reasons you should listen to both inputs, also because there are cases where user sees he did a mistake and switches back to username input.

I think your type of users will pass the tests and login successfully, but this type of form is not great for everybody (you also mentioned mobiles users).

Examples of login forms: http://www.smileycat.com/design_elements/login_forms/

Answer 8

First off, I've come to this through Twitter and am not a programmer, but have reasonable IT literacy.

Interesting proposition as I have long since abandoned the Login button when using web sites - most I use seem happy for me to press enter.

Couple of points: The school kids test was interesting, although I suspect they would find web forms far more intuitive than adult users, especially those who were not using computers (ZX/C64/BBC) growing up. I know a few of my friends who would have spent a couple of moments (at least) pondering the missing button - and these are people who use computers everyday for work, but just know how to work the applications they use.

Given that the button isn't there, what is the action of the form when pressing Enter on the username field? Or less likely, what happens if they have entered the password first and pressed enter? You may need something that has a Tab action until both fields are complete.

Just locked my Windows PC (work machine, I have no choice), logging back in, the password field "login" button is less obvious and not labelled. Again I just use enter.

There you go, a numpty's perspective ;)

Answer 9

Do some usability testing and find out what users do. I understand that's a project, but if it matters, it matters enough to test.

Answer 10

If I came across such a page, I might think that the website hasn't loaded completely, or that there is some bug on the server side script. Why risk the chance of a user navigating away from the site?

Also, in your testing, have you considered that you might be getting higher success rates than what you might actually get when the site goes live? When people feel that they are being tested, they might be expecting to overcome some sort of challenge (e.g. a missing login button) as though it's an IQ test of some sort. However, if they are on their own web browsers at home, they would probably have a completely different mind set and would act differently (e.g. they wouldn't be expecting to overcome any challenges, and in fact might expect the exact opposite. They may expect that the website would do everything possible to accommodate all users and make it easy to login since the website obviously wants a lot of users to be happy).

Basically your test scenario is not 100% similar to what actual users will experience (i.e. your subjects know that they are being tested and/or testing something), unless you can reproduce the same exact conditions (i.e. not let the subjects know that this is a test), you may draw inaccurate conclusions based on inaccurate testing.

I'm not sure exactly how you are conducting your tests, but another thing that might affect the quality of your testing is if other students see that no one else has problems/questions and they are able to login just fine. This might cause them to try different things (e.g. press the 'return' button) until they get the same results as their peers. Thus, you might want to isolate the subjects as well.

Accurate testing can be a very difficult task since you have to ensure that all the variables are exactly the same except for the variable you are testing for. From what little time I spent thinking about this problem, I have already identified an additional two variables that may affect your test's accuracy. There may be additional ones which I haven't thought of.

Answer 11

Do Both

Have the form submit itself as soon as someone presses Enter (and both fields have been filled out), and also have a button to press for people who love using the mouse.

Either way, your user is happy doing what they're used to.

Answer 12

I don't know how relevent this is, but I was quite intrigued by this and I set up a page much like your screenshot and then asked my wife to try it out.

she did manage to log in ok without having to ask for help, but I did note that after typing in her password, she opted to use the mouse and started to look for a button. Only when she didn't find it, she paused for a few moments and then tried pressing return, letting her in.

Asking her what she thought to it, she first of said it was ok and just normal, but after asking her what she thought of the missing button, she did say she was a little confused, but thought that if she pressed return, it might move to the next screen like it does when you want a new page in word.

I'm not entirely sure what she means, but the result was she managed to get in unaided, although she did spent a moment looking for a button.

Answer 13

Ultimately, like other answers suggest you need to ask who your audience is. Your test on school kids although interesting doesn't actually provide you with enough value to say "My Test proved it isn't needed".

If you were to remove the login button these are some of the things you would have to combat:

• Accessibility Issues
• What the user would expect
• Touch based devices in the future (Windows 7 and Tablets)

I personally work with Web Applications in Flash Builder and as part of the proof of concept we go through usability testing. As designers/developers you cannot underestimate the level of intelligence of some of your users. As a rule of thumb I would always say to provide your users with what they would expect. Only in exceptional circumstances should you move away from a convention that has become so widely used.

If it takes a user a couple of seconds to work out what to do next, you need to re-evaluate how you have presented the User Interface.

With touch screen technology becoming more widely used I can't see this particular pattern to be changing any time soon. It may evolve but the core will most likely stay the same.

As a recommendation I would personally keep the login Button and allow the user to press the enter key to proceed, include a login button that can be clicked using the mouse tab through and select the login button using the keyboard only.

That then covers your advanced users, accessibility rules and your IT Illiterate users by keeping the standard setup for a login screen.

As a side note - Excellent answer by Rahul kudos!

Answer 14

One of the concern is to make sure not to get too many support calls about missing button/design change and not to make users confused.

To resolve that , I would add following message

Press Enter key to login 

right below the password field.

This will help users ( who might expect a login button to click to login ) know that they can press enter key to login after reading the message. It might be awkward for them for the first time but they will at least not get confused and call for support, and next time they visit the website, they will know what to do.

Power users' eyes will ignore the message because they are already using enter key to login.

Answer 15

A solution with no button wouldn't allow for the user to have 5 logon attempts before locking their password.

Therefore your system is open to a brute force attack as a hacker could have unlimited attempts to guess the password?

You could add logic to the logon to prevent such a hack, but it's something that you would need to consider.

Answer 16

I have seen a similar type of approach in software where they do not require an enter to verify credentials. Once your credentials are entered and you stop typing they check the validity of said credentials instantly.

If your credentials are wrong it automatically throws up a very visible error message letting you know what went wrong and you simply re-enter or try new credentials and the process repeats until you have successfully logged in.

Answer 17

I'd say the best thing to do would be something like this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

You could also do a small arrow outside the text field, like it's done in the Windows 7 login screen.

You probably would want to restyle the button... maybe making it blend into the textbox until you hover over it.

The only downside of it being inside the password field is it's hard to edit if you have a long password. Just make sure not to overlook this!

Answer 18

For our internally used web apps, we used an auto-login feature.

The user simply types the address or clicks the brwoser favorite/bookmark and they're automatically recognized and allowed in. How we did this, I'm not sure as I'm the resident graphic designer.

It might have been done as part of the admin creating profiles, security and permissions for the known employees? Possibly from their IP?

As someone who would routinely enter the app to check the design, it was nice not having to login every time.

Again, I'm a designer so there may be quite a few things I'm not taking into consideration, but for known employees working in internal apps, this was pretty nice.

Answer 19

I would say you do need a login button, for a number of reasons:

1. Most apps I have used return the focus to the first field when you finish entering data in the last field. Now, this may well be an old practice that has been superceded by newer preferences, but its certainly how I expect a form to behave.

2. Assuming your app will have other forms, they are likely to be more complicated than the login form and require the presence of a SUBMIT button, which is really all your login button is. Given that these forms will need the button, it makes sense to have the button on all forms, to avoid confusion.

3. Not every browser treats the ENTER key in the same fashion. Again, this may well be an old-school problem, but I remember having issues with how the ENTER key behaved when there was only one field. On some browsers it was the same as SUBMIT, on other browsers, the SUBMIT button still needed to be clicked. They key point was, it was not controlled by your app, it was controlled by the browser. So I learned long ago never to assume anything about the ENTER key, and to always rely on SUBMIT. Again, this may no longer be a problem, but I haven't ever had a problem by sticking to this principle, so I see no reason to change.

Answer 20

I think the answer here is scripts. If a user doesn't hit enter within some predetermined amount of time, then notify them that they must hit enter to login, because chances are that they haven't figured it out. For the few people that have scripts disabled, you could detect that in a number of ways and give them a button.

Answer 21

You are WAY too conservative in your design, I'd say. It's not the 20th century anymore!

1. Remove the Login button (you already did that -- but you have to stand by your decision). After all, a user can always press Enter and get logged in. However make sure that when the user presses Enter while in the Username field, it acts as Tab button instead of form submit.
2. Remove the need for Enter button. AJAX-powered instant forms are the way of the future. This isn't a security threat either: you probably have a requirement on minimum password length, and you can introduce a small delay (say 1sec) before the server acknowledges the password it recognizes. That delay can increase with each "unsuccessful" match. Note that the Enter button should still work (users don't like to wait even 1 second), -- this functionality is for those users who tend to stop, look for the Login button, get all confused, and then call the customer support.
3. Remove the username field. Not entirely, but for the majority of interactions. Username is probably still needed on the first logon, after that you can save that information in a cookie, or remember it server-side based on computer's IP address. Whenever a different user comes in, enters his/her password, presses Enter, and the server doesn't recognize this password -- instead of yelling in big red letters "wrong password!!!" just make the username field appear just beneath the password and move the focus there. Ideally it should look smooth enough that the user doesn't even understand that there was a failed login attempt -- from his perspective the username field just appears next, almost like a telnet application :)
4. Finally, make the logo smaller and less prominent; perhaps you can even style it as a watermark. The final login page can look something like this (if the logo looks a little ragged blame mspaint):

Even if your manager would disagree with such forward-looking design, it should be a breeze compromising on the original "just no login button" version.