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!

21 Answers
21

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.

thankyou for the detailed response! In the time since initially writing this question, I knocked up a simple test login page, that had no login button. when the user logs in, it simply says success (or fail if they got the name/password wrong). I then sent it to 20 people in our company, ranging from secretaries and accountants, to directors and developers, and not a single person asked about the lack of the button - oddly. some got "fail" despite the username "a" and the password "b" being case-insensitive! My girlfriend's a middle-school teacher and is getting her kids to try it today to
–
Sk93Sep 10 '10 at 9:28

7

32 school kids were tested with a basic login page without any buttons, and all 32 logged in fine. They weren't told about the lack of a button, but rather that they needed to test if the account they were given worked. It was only after the teacher pointed out the lack of button, did the kids both notice and then start to discuss in depth. Apparently, as she's a design teacher, she said it was a very good scenario for the kids to talk through, as it illustrated the design over function / function over design principle perfectly :D.
–
Sk93Sep 10 '10 at 12:36

2

It's great that they passed. About testing (maybe Rahul could help), would have been better to A/B test this? Like, see which was a better response time: with button or without? I'm asking because, maybe with button, the form looks like a genuine login form and users react immediately (read the button text), and without maybe they have some seconds more to read the labels.
–
risherrySep 10 '10 at 13:47

2

I'm a programmer and graphic designer and even I hate it when there's no button on a form. It just makes sense to show that this form does something by providing the button to do so.
–
Nick BedfordMay 19 '11 at 22:33

2

This may be anecdotal evidence, but I'm always surprised to see how mouse/click-dependent users are (especially older users) i.e. click on field1, type, move mouse to field2, click, type etc. The fact that we're here having this conversation suggests we may be more towards the power-user end of the spectrum, and possibly more likely to fill forms with just the keyboard. So it's easy to forget about all those users who will finish typing the password and then wonder where it is they should be clicking next.
–
dennisleesMar 9 '12 at 5:28

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.

But are these calls coming to you because the users have seen the login button on the page in FireFox, and are, rightly, expecting it to appear in <otherBrowser>?
–
Sk93Sep 10 '10 at 16:02

5

No, most users use only one browser and will never see what it looks like in Firefox. They are calling because they "cant log in" because they don't know what to do after entering their username/password.
–
LoganGoesPlacesSep 10 '10 at 16:06

2

I'm curious, what drove the decision to include a button in FF only?
–
xanadontSep 16 '10 at 18:28

1

It is a 3rd party system. I'm thinking it's just a lack of testing on their end.
–
LoganGoesPlacesSep 16 '10 at 19:38

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.

You make a good point about not knowing what enter will do. I have hit enter thinking it would submit a form and to my surprise, a combo box/dropdown was activated at the top of the page. It is easy to run into issues with incorrectly associated elements.
–
LoganGoesPlacesSep 10 '10 at 21:17

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.

Some forms submit on enter, but many do not. Without a submit button to focus, there's nowhere for "tab" to go after entering the password. You could always add DOM that only gets picked up by a screen reader, but that does not help low-vision non-tech-savy users looking for a button.
–
Stefan KendallApr 22 at 16:55

The iPad and iPhone still allow you to submit the form from the keyboard with return/enter key.
–
g .Sep 30 '10 at 13:51

1

My android phone has a return key on the keyboard when using forms. However some people might not be aware of this. Since the login page is probably the most used form it's a lot of risk just for a small gain in aesthetics.
–
KeyoOct 1 '10 at 1:10

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.

"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).

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.

Thanks for your answer PawnSacrifice ;) - pressing enter or tab on the username field moves the cursor into the password field. pressing tab on the password field moves the cursor into the username field. In regards to the difference between users and kids, you make a valid point - thanks
–
Sk93Sep 10 '10 at 15:57

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.

In this particular example, the website is a web-application that the customer will have purchased access to and, as such, there would be no risk of the customers staff "browsing away". Similarly, they would be accessing it from work, rather than from home. Because of these reasons, we didn't think it necessary to isolate the test subjects from each other. However, in a different scenario, I agree that much more structured testing would be needed :) As this was just a theoretical discussion, and not actually something we invested time/money into - our testing was a obviously bit slack.
–
Sk93Nov 23 '10 at 8:12

1

(ran out of space) - However, interestingly, we did install a "click count" on the login button, and out of just over 7k logins, we only recorded 73 button presses.. which is a very interesting number to consider :)
–
Sk93Nov 23 '10 at 8:13

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.

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.

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.

I don't understand this answer. When the user presses Enter, it attempts to log in. This counts as a login attempt. If the user changes the password and presses Enter again, it counts as another login attempt. Rate limiting can still be implemented for such login attempts.
–
Max NanasyJan 10 '14 at 22:07

Rate limiting with unlimited retries is not as secure as preventing access after 'n' tries.
–
TechboyJan 11 '14 at 11:04

Either type of system could be implemented without a physical login button. My point was that the user pressing Enter counts as a login attempt, so not having a physical button doesn't affect how secure login is.
–
Max NanasyJan 11 '14 at 19:19

I know this was posted three years ago, but it you are still puzzled how it was done Tomas, I would guess that the application was checking to see if the browser being used was from the local network (it would have an IP address in a specific range). From a security point of view this is pretty poor, but I agree it sure would be convenient if we didn't have to log onto our local browser-based apps.
–
PuzbieMar 23 '13 at 15:05

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.

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.

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.

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.

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.

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

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.

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.

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 :)

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.

You've no idea on our design criteria, so you can't justly say it's too conservative. Firstly, it's designed to be used on a single pc in a lab environment, frequently used by many different users, so username box is required, as it is very unlikely the first user will be the same as the second. The "fake logo" is that size because of government "crown logo" requirements. You seem to have missed the whole point of the question - is a login button required. Plus.. I'm the manager. Redesign your answer to reflect this and I'll remove the downvote :)
–
Sk93Mar 22 '13 at 15:31

How can you blame me for not knowing what the design criteria are? Or not knowing that you are the manager? Anyways, the question you ask is of interest not only to you, but also to any other person who in the future may be pondering the same problem: "Do I need a login button?". And their context may be different than yours.
–
Pasha SMar 22 '13 at 20:24

I'm not blaming you for not knowing. I'm saying you cannot say the design of a page is too conservative - especially when it's actual design is not the focus of the question. Your 4th point is totally irrelevant to the question at hand. If I had asked for design ideas for a page, your answer is worthy of an upvote, but you seem to have missed the point of the question. If you look at the top voted answers, they're all offering reasons for and against having the button. Your answer doesn't have either, except for claiming it's not 21st century.
–
Sk93Apr 5 '13 at 15:28

1

-1. It is a security flaw to have AJAX verification. 1.) it makes it really hard to detect brute force attacks when a user could just be typing their password in 2.) you should have some sort of delay in your code for a fraction of a second to make brute force attacks hard to do. Not to mention, a user may think it's a different password and keep typing when they're already logged in, perhaps typing a few characters into important data.
–
Annonomus PenguinJul 26 '14 at 1:20