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:

the screen

  • 3
    Original question (with answers) programmers.stackexchange.com/questions/2459/…
    – ChrisF
    Commented Sep 10, 2010 at 9:04
  • 1
    Does Google Instant really need a search button? Probably.
    – Daniel
    Commented Jul 11, 2011 at 20:23
  • 1
    Here's a different question that addresses the accessibility issues with not having a submit button: Why is it inaccessible to create a form with no submit button? Commented Nov 13, 2012 at 22:27
  • 1
    @Sk93 CTA means Call to Action. Commented Feb 4, 2014 at 0:31
  • 1
    I once made a fairly simple Wordpress site for a local club. One feature they wanted was a search bar but after UAT the search bar plugin I had found came up as being an issue because it didn't have a search button. The older users didn't know how to execute the search by pressing enter.
    – Chro
    Commented Jun 3, 2016 at 14:07

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.

  • 6
    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
    – Sk93
    Commented Sep 10, 2010 at 9:28
  • 9
    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.
    – Sk93
    Commented Sep 10, 2010 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. Commented Sep 10, 2010 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. Commented May 19, 2011 at 22:33
  • 4
    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.
    – dennislees
    Commented Mar 9, 2012 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>?
    – Sk93
    Commented Sep 10, 2010 at 16:02
  • 7
    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. Commented Sep 10, 2010 at 16:06
  • 4
    I'm curious, what drove the decision to include a button in FF only?
    – xanadont
    Commented Sep 16, 2010 at 18:28
  • 1
    It is a 3rd party system. I'm thinking it's just a lack of testing on their end. Commented Sep 16, 2010 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.

  • 3
    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. Commented Sep 10, 2010 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.

  • 1
    Blind Users? Can you elaborate please?
    – Evorlor
    Commented Apr 22, 2015 at 15:38
  • 1
    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. Commented Apr 22, 2015 at 16:55

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

  • 3
    The iPad and iPhone still allow you to submit the form from the keyboard with return/enter key.
    – g .
    Commented Sep 30, 2010 at 13:51
  • 2
    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.
    – Benbob
    Commented Oct 1, 2010 at 1:10
  • 1
    @Keyo Android supports custom keyboards (many people use Swype or SwiftKey).
    – dbkk
    Commented May 22, 2011 at 21:38
  • @dbkk: but the keyboard for android are supposed to offer the IME actions
    – njzk2
    Commented Jul 27, 2014 at 23:48

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.


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/

  • that's a great set of links there - and a good answer. Thanks :)
    – Sk93
    Commented Sep 10, 2010 at 14:49

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

  • 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
    – Sk93
    Commented Sep 10, 2010 at 15:57

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.

  • see the other comments to similar answers above.
    – Sk93
    Commented Sep 10, 2010 at 18:56

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.

  • 1
    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.
    – Sk93
    Commented Nov 23, 2010 at 8:12
  • 2
    (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 :)
    – Sk93
    Commented Nov 23, 2010 at 8:13

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.


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.

As a side note - Excellent answer by Rahul kudos!


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.

  • 2
    I don't think that if instructions are needed you have a good design.. Commented Jul 9, 2011 at 14:11
  • 1
    Maybe show the message only after some time? Commented Jul 11, 2011 at 18:54

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.

  • 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 Nanasy
    Commented Jan 10, 2014 at 22:07
  • Rate limiting with unlimited retries is not as secure as preventing access after 'n' tries.
    – Techboy
    Commented Jan 11, 2014 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 Nanasy
    Commented Jan 11, 2014 at 19:19

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.


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!


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.

  • 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. Commented Mar 23, 2013 at 15:05

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.


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.

  • 3
    That sounds terribly convoluted as an alternative to just having a log in button...
    – Rahul
    Commented Sep 20, 2010 at 16:21
  • agree - that's not something I think we'd try and implement; At that level of "complexity", we'd just have the button :)
    – Sk93
    Commented Sep 21, 2010 at 13:28

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

Login page redesigned

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 :)
    – Sk93
    Commented Mar 22, 2013 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
    Commented Mar 22, 2013 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.
    – Sk93
    Commented Apr 5, 2013 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. Commented Jul 26, 2014 at 1:20
  • +1 Like some other answers, this answer by @Pasha suggests not only to remove the "LOGIN" button, but also to get rid of the need to press "ENTER" altogether. This is the UX part of Stack Exchange, not the programming part, so yes, please, do challenge conventions!
    – Ideogram
    Commented Jan 16, 2020 at 6:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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