Is there a problem with hiding “forgot password” until it's needed?Forgot Password typical use caseShould I provide a “Forgot Password” option for a one-time sign in Android application?Forgot Password Alternatives?Are we stuck with the “Forgot password” link?Forgot Password Inline vs. Separate PageImplementing a passphrase instead of a passwordWhere to redirect the user after a password recovery email has been sentForgot Password Icon? How's this?Why enter again (or at the very least confirm) my email address when I click “Forgot password”?Improving on the abcdef password“Forgot password?” or “Reset password”?

Can White Castle?

Do French speakers not use the subjunctive informally?

Sho, greek letter

quadratic equation solving mistake

Was there ever a name for the weapons of the Others?

Archery in modern conflicts

Change the boot order with no option in UEFI settings

Importance of the principal bundle in Chern-Simons theory

Should I tell my insurance company I'm making payments on my new car?

A player is constantly pestering me about rules, what do I do as a DM?

Is there any set of 2-6 notes that doesn't have a chord name?

What reason would an alien civilization have for building a Dyson Sphere (or Swarm) if cheap Nuclear fusion is available?

How risky is real estate?

In the Marvel universe, can a human have a baby with any non-human?

Hot coffee brewing solutions for deep woods camping

How can I repair scratches on a painted French door?

Why is the Turkish president's surname spelt in Russian as Эрдоган, with г?

Would a two-seat light aircaft with a landing speed of 20 knots and a top speed of 180 knots be technically possible?

An expansion from Ramanujan related to birthday problem

How to reply to small talk/random facts in a non-offensive way?

Change CPU MHz from Registry

Can the negators "jamais, rien, personne, plus, ni, aucun" be used in a single sentence?

Can you apprehend something instead of someone?

How precise do models need to be for 3d printing?



Is there a problem with hiding “forgot password” until it's needed?


Forgot Password typical use caseShould I provide a “Forgot Password” option for a one-time sign in Android application?Forgot Password Alternatives?Are we stuck with the “Forgot password” link?Forgot Password Inline vs. Separate PageImplementing a passphrase instead of a passwordWhere to redirect the user after a password recovery email has been sentForgot Password Icon? How's this?Why enter again (or at the very least confirm) my email address when I click “Forgot password”?Improving on the abcdef password“Forgot password?” or “Reset password”?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








49















To be honest, I don't really see any use for the "forgot password" button/link unless the user put in a wrong password before. In my current project, we need as much space as possible and I was thinking about showing it only when needed. My colleague talked about "Accessibility"-reasons why it is not possible, but also couldn't give me a real argument.



What is your take on it?










share|improve this question



















  • 64





    @IrwinAllen13 Splitting the user name and password fields across 2 pages is really irritating for the user and complicates things for no benefit.

    – Hobbes
    Mar 25 at 13:10






  • 28





    This sounds like one of the levels of the H-word from the Hyundai Super Bowl commercial. If you put in the wrong password twice, closed your browser/app, then you would have to put it in wrong a third time and lock your account in order to be given the option to avoid locking your account?

    – MonkeyZeus
    Mar 25 at 13:19







  • 55





    I think you have that backwards. If I enter a password, that means I have some idea what the password is (maybe I got confused with the password from another site, or I can't remember one of the characters) and likely will be able to get it after a few more tries. If I've completely forgotten what my password is, I'm not going to enter a random string of characters hoping it's right. And if "forgot password" takes up too much space, "help" is slightly more than one fourth the size. Would that fit? Or just a question mark.

    – Acccumulation
    Mar 25 at 15:29







  • 11





    @MonkeyZeus Google does this because on 'password step' they may need to redirect you to authenticate on some third-party (corporate) website instead of supplying your password to Google. Think of Google Apps.

    – user11153
    Mar 25 at 16:16






  • 20





    “In my current project we need as much space as possible” — has the price of pixels suddenly gone up?

    – Paul D. Waite
    Mar 25 at 17:18

















49















To be honest, I don't really see any use for the "forgot password" button/link unless the user put in a wrong password before. In my current project, we need as much space as possible and I was thinking about showing it only when needed. My colleague talked about "Accessibility"-reasons why it is not possible, but also couldn't give me a real argument.



What is your take on it?










share|improve this question



















  • 64





    @IrwinAllen13 Splitting the user name and password fields across 2 pages is really irritating for the user and complicates things for no benefit.

    – Hobbes
    Mar 25 at 13:10






  • 28





    This sounds like one of the levels of the H-word from the Hyundai Super Bowl commercial. If you put in the wrong password twice, closed your browser/app, then you would have to put it in wrong a third time and lock your account in order to be given the option to avoid locking your account?

    – MonkeyZeus
    Mar 25 at 13:19







  • 55





    I think you have that backwards. If I enter a password, that means I have some idea what the password is (maybe I got confused with the password from another site, or I can't remember one of the characters) and likely will be able to get it after a few more tries. If I've completely forgotten what my password is, I'm not going to enter a random string of characters hoping it's right. And if "forgot password" takes up too much space, "help" is slightly more than one fourth the size. Would that fit? Or just a question mark.

    – Acccumulation
    Mar 25 at 15:29







  • 11





    @MonkeyZeus Google does this because on 'password step' they may need to redirect you to authenticate on some third-party (corporate) website instead of supplying your password to Google. Think of Google Apps.

    – user11153
    Mar 25 at 16:16






  • 20





    “In my current project we need as much space as possible” — has the price of pixels suddenly gone up?

    – Paul D. Waite
    Mar 25 at 17:18













49












49








49


8






To be honest, I don't really see any use for the "forgot password" button/link unless the user put in a wrong password before. In my current project, we need as much space as possible and I was thinking about showing it only when needed. My colleague talked about "Accessibility"-reasons why it is not possible, but also couldn't give me a real argument.



What is your take on it?










share|improve this question
















To be honest, I don't really see any use for the "forgot password" button/link unless the user put in a wrong password before. In my current project, we need as much space as possible and I was thinking about showing it only when needed. My colleague talked about "Accessibility"-reasons why it is not possible, but also couldn't give me a real argument.



What is your take on it?







login password dynamic-ui






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 25 at 23:25









DxTx

1035 bronze badges




1035 bronze badges










asked Mar 25 at 9:08









hans wrusthans wrust

2631 gold badge2 silver badges4 bronze badges




2631 gold badge2 silver badges4 bronze badges







  • 64





    @IrwinAllen13 Splitting the user name and password fields across 2 pages is really irritating for the user and complicates things for no benefit.

    – Hobbes
    Mar 25 at 13:10






  • 28





    This sounds like one of the levels of the H-word from the Hyundai Super Bowl commercial. If you put in the wrong password twice, closed your browser/app, then you would have to put it in wrong a third time and lock your account in order to be given the option to avoid locking your account?

    – MonkeyZeus
    Mar 25 at 13:19







  • 55





    I think you have that backwards. If I enter a password, that means I have some idea what the password is (maybe I got confused with the password from another site, or I can't remember one of the characters) and likely will be able to get it after a few more tries. If I've completely forgotten what my password is, I'm not going to enter a random string of characters hoping it's right. And if "forgot password" takes up too much space, "help" is slightly more than one fourth the size. Would that fit? Or just a question mark.

    – Acccumulation
    Mar 25 at 15:29







  • 11





    @MonkeyZeus Google does this because on 'password step' they may need to redirect you to authenticate on some third-party (corporate) website instead of supplying your password to Google. Think of Google Apps.

    – user11153
    Mar 25 at 16:16






  • 20





    “In my current project we need as much space as possible” — has the price of pixels suddenly gone up?

    – Paul D. Waite
    Mar 25 at 17:18












  • 64





    @IrwinAllen13 Splitting the user name and password fields across 2 pages is really irritating for the user and complicates things for no benefit.

    – Hobbes
    Mar 25 at 13:10






  • 28





    This sounds like one of the levels of the H-word from the Hyundai Super Bowl commercial. If you put in the wrong password twice, closed your browser/app, then you would have to put it in wrong a third time and lock your account in order to be given the option to avoid locking your account?

    – MonkeyZeus
    Mar 25 at 13:19







  • 55





    I think you have that backwards. If I enter a password, that means I have some idea what the password is (maybe I got confused with the password from another site, or I can't remember one of the characters) and likely will be able to get it after a few more tries. If I've completely forgotten what my password is, I'm not going to enter a random string of characters hoping it's right. And if "forgot password" takes up too much space, "help" is slightly more than one fourth the size. Would that fit? Or just a question mark.

    – Acccumulation
    Mar 25 at 15:29







  • 11





    @MonkeyZeus Google does this because on 'password step' they may need to redirect you to authenticate on some third-party (corporate) website instead of supplying your password to Google. Think of Google Apps.

    – user11153
    Mar 25 at 16:16






  • 20





    “In my current project we need as much space as possible” — has the price of pixels suddenly gone up?

    – Paul D. Waite
    Mar 25 at 17:18







64




64





@IrwinAllen13 Splitting the user name and password fields across 2 pages is really irritating for the user and complicates things for no benefit.

– Hobbes
Mar 25 at 13:10





@IrwinAllen13 Splitting the user name and password fields across 2 pages is really irritating for the user and complicates things for no benefit.

– Hobbes
Mar 25 at 13:10




28




28





This sounds like one of the levels of the H-word from the Hyundai Super Bowl commercial. If you put in the wrong password twice, closed your browser/app, then you would have to put it in wrong a third time and lock your account in order to be given the option to avoid locking your account?

– MonkeyZeus
Mar 25 at 13:19






This sounds like one of the levels of the H-word from the Hyundai Super Bowl commercial. If you put in the wrong password twice, closed your browser/app, then you would have to put it in wrong a third time and lock your account in order to be given the option to avoid locking your account?

– MonkeyZeus
Mar 25 at 13:19





55




55





I think you have that backwards. If I enter a password, that means I have some idea what the password is (maybe I got confused with the password from another site, or I can't remember one of the characters) and likely will be able to get it after a few more tries. If I've completely forgotten what my password is, I'm not going to enter a random string of characters hoping it's right. And if "forgot password" takes up too much space, "help" is slightly more than one fourth the size. Would that fit? Or just a question mark.

– Acccumulation
Mar 25 at 15:29






I think you have that backwards. If I enter a password, that means I have some idea what the password is (maybe I got confused with the password from another site, or I can't remember one of the characters) and likely will be able to get it after a few more tries. If I've completely forgotten what my password is, I'm not going to enter a random string of characters hoping it's right. And if "forgot password" takes up too much space, "help" is slightly more than one fourth the size. Would that fit? Or just a question mark.

– Acccumulation
Mar 25 at 15:29





11




11





@MonkeyZeus Google does this because on 'password step' they may need to redirect you to authenticate on some third-party (corporate) website instead of supplying your password to Google. Think of Google Apps.

– user11153
Mar 25 at 16:16





@MonkeyZeus Google does this because on 'password step' they may need to redirect you to authenticate on some third-party (corporate) website instead of supplying your password to Google. Think of Google Apps.

– user11153
Mar 25 at 16:16




20




20





“In my current project we need as much space as possible” — has the price of pixels suddenly gone up?

– Paul D. Waite
Mar 25 at 17:18





“In my current project we need as much space as possible” — has the price of pixels suddenly gone up?

– Paul D. Waite
Mar 25 at 17:18










8 Answers
8






active

oldest

votes


















283














Let me try to paint a picture to explain why your comment below is a huge oversight.




Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.




Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an account exists but they haven't used it in a long time so they have definitely forgotten the password.



In this scenario, the first thing they'd do is ... ?



They will look for a password recovery option which is something in the lines of a "Forgot Password" option.



In such a condition, the user hasn't put in a wrong password yet, but they need that option



Your colleague is absolutely right about accessibility. Hiding critical actions and information selectively is a very bad practice.






share|improve this answer


















  • 74





    Indeed - to make the thought process on the user's side more explicit: Some users will, if they don't know the password, not dare to try and input anything. And, as opposed to other irrational fears about that magical computer-thing, this one is even slightly justified as (usually, repeated) wrong input of a password may result in (semi-)permanently locking the account.

    – O. R. Mapper
    Mar 25 at 10:22






  • 36





    Agreed. Based on my own experience, hiding the Forgot Password option at first would likely result in an increased number of calls/emails to your customer support contact point, because people unable to find the link will reach out for a human to help. You don't notice until you do this sort of thing exactly how many people just rely on "forgot password" to constantly reset their password, rather than simply remember their password.

    – Steve-O
    Mar 25 at 14:34






  • 9





    @O.R.Mapper I don't like entering wrong passwords because I'm convinced that the site is harvesting passwords for other sites.

    – JPhi1618
    Mar 25 at 14:39






  • 4





    @JPhi1618: I don't understand. If that should be the case, adding bogus data to the password collection sounds like a good thing to me.

    – O. R. Mapper
    Mar 25 at 14:49






  • 6





    Another scenario is that the user suspects that their credentials are compromised and just wants to reset them immediately.

    – Lorentz Vedeler
    Mar 25 at 14:55


















46














It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.



How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?



You have no idea what the password is, as it will likely be some random combination of letters, numbers, characters, etc., and therefore will want to reset it straight away.






share|improve this answer






























    12














    Globally Consistent Convention Versus Design "Wants"



    There is always weight towards convention in user experience/interface design for numerous reasons, but crucial systems where there is a safety/security element are ones where that should be given even higher than normal priority.




    In my current project we need as much space as possible




    Your reason for wanting to try breaking with a globally (externally) consistent pattern is essentially "we're lacking space".



    Others have explained certain aspects of why this is a pattern you shouldn't break from specifically in relation to the element you're asking about. Those are great answers and this is merely meant to be a supplemental piece in addition to them. I want to address why you feel the need to break from convention in the first place and advise that you circle back to this encompassing design issue as the real reason you tried finding something to cut at all, and what therefor instead needs to be addressed.



    Needs vs Wants



    My simplest advice would be this: when dealing with anything related to security or safety, I recommend you consider conventional design components and layouts to be "needs" and your contravening design level issues to simply be "wants": if you can come up with a hard need related to the core purpose of the interface (for example: people are misclicking on a UI element and it is causing authentication issues), then it can be properly weighed against the various reasons already behind the conventional design needs (such as, if we move these elements to avoid misclicks, does it cause a worse issue to emerge that was already foreseen in the current design, making this a necessary evil), but until it arrives at that point it is merely a want and can generally be considered lower precedence.



    Generally speaking, a login page/screen/modal should have as little extraneous information going on as possible, both for the sake of usability but also potentially for the sake of security (for example, avoid loading external resources where possible here). If you have a space issue on your login interface, something is almost certainly "wrong" with the encompassing design (even if this is an embedded interface of some kind). It's impossible to speculate about what per se the problem is without any related information, but I'd strongly urge you to stop trying to look for ways to break from convention here and instead look at how you can refactor the design of this interface to better fit with conventional login interface paradigms, even if it means that this screen does not perfectly match the design templating of other screens (I'd absolute advise that you keep at least related elements consistent: brand logos, colors, etc, but simply find ways to cull elements and/or reduce whitespace areas/etc that are not necessary for a login screen).



    Login interfaces in particular have numerous usability concerns which overlap with security concerns, and breaking with conventional design--beyond the generalized usability reasons to try to stick with common convention due to related user knowledge/expectations--can have severe security implications here that are not always immediately foreseeable: don't break from convention simply to satisfy having seemingly backed yourself into a design corner where something "doesn't look nice" or "doesn't fit": re-examine the surrounding design itself so that it can encompass the conventional interface/component layout. If you have a specific need or reason to change the design related to a functionality change, that would be worth exploring (but will most likely result in the same outcome, per the other answers).



    More simply put:



    If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you? Look to that for something to change first.



    "If it ain't broke, don't fix it" simply because something else is broke with it in it. Re-align your thinking as to what the issue is.



    Convention at all costs?



    Hardly. I'm not arguing that convention can't be wrong. I'm instead saying that an easy first step analysis is to weight convention to a degree where it isn't simply questioned at each corner, short of discovering an issue actually directly relating to the conventional choices and design themselves.



    Hopefully the nuance here isn't lost.



    It's entirely possible to fully unpack the reason for this, but I find it to be a generally reasonable basic rule that greatly saves on time that nearly always turns out to have been either needlessly wasted or at best poorly spent: don't rush to make changes to something that fits with convention simply because some other choice is in conflict, instead revisit the conflict with the assumption that the convention simply has more weight by default than whatever is on the other side of the conflicting issue.



    Often whatever came into conflict with a convention will even turn out to have other shortfalls that simply weren't exposed yet: the fact that accommodating a highly standard convention is problematic in a given design or in conjunction with other design elements is often a warning sign regarding that conflicting design.



    On the other hand, when faced with a convention that is causing direct issues (for example, in higher education, it's common to present a "mega menu" despite a complete lack of evidence that this actually helps prospective--or any--students navigate University websites, and one of the most common complaints is often difficulty navigating the website and discovering appropriate content in a meaningful way), then it's worth spending the time to do a proper analysis of what the benefits (and costs) are to changing it, even if ultimately the answer arrived at is still "no".



    The key though is that conventional design generally unpacks not only key pre-shared knowledge and user expectations due to global consistency, but it also often represents lessons learned over the course of multiple entities and often years of exposure, some of which may be less immediately obvious and may go deeper than seemingly simple relatively superficial choices. Not always. But often.



    Is it possible to chase down each of those reasons? Certainly. But my question is whether it's actually worth the time, especially if doing so turns into a practice you commonly turn to for solving other problems. Personally, the lesson I've learned over years of development and design, is that it's generally a waste of time and ultimately highly unproductive, and more costly than superficial analysis would assume (potentially even in devastating ways when consequences can go beyond simpler satisfaction aspects or reversible user actions), to open things up to changes of conventional choices/elements/layouts simply due to how it fits in with some other choice made, some other design element, etc.



    Consider a push-pull door (the classic example, to lean on Norman). What if you want to design the surrounding opening clearance and doorstop area differently, so you change the handle design to allow the door to open an inch further given a design element in the doorstop area that would hit the standard pull handle in a standard vertical orientation, only now it looks like a horizontal push handle instead of a pull? Would spending time considering that have really been worth it, versus simply saying that the doorstop area's creative new design needed to accommodate the conventional design of the door interface? Was whatever new creativeness went into the doorstop area either so important or so entirely constrained to such a high level as to really be worth even exploring that, versus simply exploring an appropriate accommodation in the new design and accepting some degree of related compromise perhaps in that new design?




    As a quick example of why it's a good idea to stick with convention particularly in circumstances where mistakes may result in worse implications than simply someone not being pleased with the flow, or the aesthetic (short of a direct functional reason to change from it, with careful exploration of related consequences): what happens if you were to reverse the order of the username and password fields? Let's say it's for a web page: ideally everything is coded correctly so every aspect of this goes across HTTPS as POST fields. What if, in trying to get clever, someone loaded a "reset password" link with the username as a get parameter (querystring)? So what happens when someone tries logging in, puts their credentials in in reverse of the input fields, and then without paying enough attention clicks the "reset password" link... and that happens to be a non https page/endpoint?



    Even if it's https, that url with querystring is now in the server logs most likely. Which ideally are secure. And ideally there's no association now with a specific account. But it's one more potential place for that to leak.



    What happens if someone tries entering their parameters in reverse during a presentation? This happens even with standard configurations by simple user error (accidental tab/etc), but how often would it happen if the fields were reversed? If there's a malicious actor in the audience, do they get kicked out if they manage to log in during the timeframe between the accidental password reveal and the user resetting their password, or can they keep navigating within the application? etc.




    Aside: On Accessibility



    (I'm writing this in relation to an assumption of this being in a web page, but similar accessibility concepts/constructs exist in other interfaces)



    FYI, this might not be an accessibility issue if this is a webpage that you submit with the submit action being that it loads the same page again from the server with the related markup of a login attempt that did not authenticate alongside a link to the password reset.



    Where this becomes a possible accessibility issue is that if this is dynamically AJAXed (single page application/etc), such that it sends the results to the server via client side scripting and then updates the page without reloading it, you may require ARIA tagging (most likely as live regions, and you'll need to carefully consider how much/what you mark as live regions versus not) to allow screen readers to update properly regarding the submission error and the availability of the link.



    Particularly with screen readers, it's important to keep in mind that updates to parts of the page that aren't being interacted with can be very non obvious, especially if the person accessing the page has already explored those areas and formed a mental model in relation to them where they no longer anticipate related information being present there. In turn, it requires careful consideration (and actual testing!) to not create a circumstance where dynamic updates create an overwhelming level of immediate feedback via added aria-live decoration (while keeping a flow that allows people to reach related updated information intuitively), and you also need to pay attention to what the dynamic updates do in various screen readers in terms of cursor location changes, if any.






    share|improve this answer




















    • 2





      I especially liked 'If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you?'

      – Máté Juhász
      Mar 27 at 8:03


















    3














    If someone forgets their password they will first look for a forget password so this would just waste the user's time, annoying them causing them to want to leave. Also some people will use the change password to find out a username that they have forgotten so this would force then to try and remember it, annoying them. Finally some users will use the password reset to change the password, this will annoy them as most other sites will do this.



    When designing a application/website it is all about making any action easy and fast. Hiding the forgotten password button makes it harder and slower. This should never be done.






    share|improve this answer
































      2














      As a user, I would be a little upset with your proposal. There are a few sites where I just don't bother to remember the password, and use the "forgot password" feature as a one-time-password system.



      If you really need to save space, you could start with a "Forgot password?" button until something is entered in the password field.






      share|improve this answer






























        2














        In case you are still looking for solutions, how's this.



        At the very minimum - the way Google does it - you need an input box for the user name and a "Next" button.

        In this case, you can have the button read "Forgot password?" at first, as long as the user hasn't filled in anything in the box. Then as soon as they have input anything, change the button to "Next" to go to the input password screen.






        share|improve this answer






























          2














          As other members have pointed out, this is primarily a bad idea because it assumes that the user already has a password in mind to try.



          If I visit a website I haven't visited in a very long time and the password isn't in my password manager, I'll often simply just reset the password rather than trying to guess what it may be. In such a case, I wouldn't have a password in mind to use on a failed login first.



          Secondly, sometimes users will want to reset their password without signing in; for example, in the event of your website being breached. If the link is hidden, this is likely to frustrate users and it may not be immediately obvious how to get the link to show up.






          share|improve this answer






























            0














            This needs to be answered alongside the context in your question:




            we need as much space as possible




            I don't know what your login page looks like or why you so desperately need the space, but assuming you do, then yes, an easy thing to cut is a Forgot Password link on the first login page. It's not ideal, and you will probably lose users that come back after a while and don't want to guess a password. You need to balance that and other UX options with your need for real estate.



            A more holistic approach to the problem is sharing your current login screen and its detailed space requirements. There are ways to indicate actions to users without a giant text span, and likewise there is probably a better way to solve your problem without hiding functionality.






            share|improve this answer

























              Your Answer








              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "102"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: false,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              imageUploader:
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              ,
              noCode: true, onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );













              draft saved

              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f124619%2fis-there-a-problem-with-hiding-forgot-password-until-its-needed%23new-answer', 'question_page');

              );

              Post as a guest















              Required, but never shown

























              8 Answers
              8






              active

              oldest

              votes








              8 Answers
              8






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              283














              Let me try to paint a picture to explain why your comment below is a huge oversight.




              Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.




              Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an account exists but they haven't used it in a long time so they have definitely forgotten the password.



              In this scenario, the first thing they'd do is ... ?



              They will look for a password recovery option which is something in the lines of a "Forgot Password" option.



              In such a condition, the user hasn't put in a wrong password yet, but they need that option



              Your colleague is absolutely right about accessibility. Hiding critical actions and information selectively is a very bad practice.






              share|improve this answer


















              • 74





                Indeed - to make the thought process on the user's side more explicit: Some users will, if they don't know the password, not dare to try and input anything. And, as opposed to other irrational fears about that magical computer-thing, this one is even slightly justified as (usually, repeated) wrong input of a password may result in (semi-)permanently locking the account.

                – O. R. Mapper
                Mar 25 at 10:22






              • 36





                Agreed. Based on my own experience, hiding the Forgot Password option at first would likely result in an increased number of calls/emails to your customer support contact point, because people unable to find the link will reach out for a human to help. You don't notice until you do this sort of thing exactly how many people just rely on "forgot password" to constantly reset their password, rather than simply remember their password.

                – Steve-O
                Mar 25 at 14:34






              • 9





                @O.R.Mapper I don't like entering wrong passwords because I'm convinced that the site is harvesting passwords for other sites.

                – JPhi1618
                Mar 25 at 14:39






              • 4





                @JPhi1618: I don't understand. If that should be the case, adding bogus data to the password collection sounds like a good thing to me.

                – O. R. Mapper
                Mar 25 at 14:49






              • 6





                Another scenario is that the user suspects that their credentials are compromised and just wants to reset them immediately.

                – Lorentz Vedeler
                Mar 25 at 14:55















              283














              Let me try to paint a picture to explain why your comment below is a huge oversight.




              Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.




              Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an account exists but they haven't used it in a long time so they have definitely forgotten the password.



              In this scenario, the first thing they'd do is ... ?



              They will look for a password recovery option which is something in the lines of a "Forgot Password" option.



              In such a condition, the user hasn't put in a wrong password yet, but they need that option



              Your colleague is absolutely right about accessibility. Hiding critical actions and information selectively is a very bad practice.






              share|improve this answer


















              • 74





                Indeed - to make the thought process on the user's side more explicit: Some users will, if they don't know the password, not dare to try and input anything. And, as opposed to other irrational fears about that magical computer-thing, this one is even slightly justified as (usually, repeated) wrong input of a password may result in (semi-)permanently locking the account.

                – O. R. Mapper
                Mar 25 at 10:22






              • 36





                Agreed. Based on my own experience, hiding the Forgot Password option at first would likely result in an increased number of calls/emails to your customer support contact point, because people unable to find the link will reach out for a human to help. You don't notice until you do this sort of thing exactly how many people just rely on "forgot password" to constantly reset their password, rather than simply remember their password.

                – Steve-O
                Mar 25 at 14:34






              • 9





                @O.R.Mapper I don't like entering wrong passwords because I'm convinced that the site is harvesting passwords for other sites.

                – JPhi1618
                Mar 25 at 14:39






              • 4





                @JPhi1618: I don't understand. If that should be the case, adding bogus data to the password collection sounds like a good thing to me.

                – O. R. Mapper
                Mar 25 at 14:49






              • 6





                Another scenario is that the user suspects that their credentials are compromised and just wants to reset them immediately.

                – Lorentz Vedeler
                Mar 25 at 14:55













              283












              283








              283







              Let me try to paint a picture to explain why your comment below is a huge oversight.




              Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.




              Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an account exists but they haven't used it in a long time so they have definitely forgotten the password.



              In this scenario, the first thing they'd do is ... ?



              They will look for a password recovery option which is something in the lines of a "Forgot Password" option.



              In such a condition, the user hasn't put in a wrong password yet, but they need that option



              Your colleague is absolutely right about accessibility. Hiding critical actions and information selectively is a very bad practice.






              share|improve this answer













              Let me try to paint a picture to explain why your comment below is a huge oversight.




              Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.




              Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an account exists but they haven't used it in a long time so they have definitely forgotten the password.



              In this scenario, the first thing they'd do is ... ?



              They will look for a password recovery option which is something in the lines of a "Forgot Password" option.



              In such a condition, the user hasn't put in a wrong password yet, but they need that option



              Your colleague is absolutely right about accessibility. Hiding critical actions and information selectively is a very bad practice.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Mar 25 at 9:39









              Shreyas TripathyShreyas Tripathy

              5,1113 gold badges20 silver badges38 bronze badges




              5,1113 gold badges20 silver badges38 bronze badges







              • 74





                Indeed - to make the thought process on the user's side more explicit: Some users will, if they don't know the password, not dare to try and input anything. And, as opposed to other irrational fears about that magical computer-thing, this one is even slightly justified as (usually, repeated) wrong input of a password may result in (semi-)permanently locking the account.

                – O. R. Mapper
                Mar 25 at 10:22






              • 36





                Agreed. Based on my own experience, hiding the Forgot Password option at first would likely result in an increased number of calls/emails to your customer support contact point, because people unable to find the link will reach out for a human to help. You don't notice until you do this sort of thing exactly how many people just rely on "forgot password" to constantly reset their password, rather than simply remember their password.

                – Steve-O
                Mar 25 at 14:34






              • 9





                @O.R.Mapper I don't like entering wrong passwords because I'm convinced that the site is harvesting passwords for other sites.

                – JPhi1618
                Mar 25 at 14:39






              • 4





                @JPhi1618: I don't understand. If that should be the case, adding bogus data to the password collection sounds like a good thing to me.

                – O. R. Mapper
                Mar 25 at 14:49






              • 6





                Another scenario is that the user suspects that their credentials are compromised and just wants to reset them immediately.

                – Lorentz Vedeler
                Mar 25 at 14:55












              • 74





                Indeed - to make the thought process on the user's side more explicit: Some users will, if they don't know the password, not dare to try and input anything. And, as opposed to other irrational fears about that magical computer-thing, this one is even slightly justified as (usually, repeated) wrong input of a password may result in (semi-)permanently locking the account.

                – O. R. Mapper
                Mar 25 at 10:22






              • 36





                Agreed. Based on my own experience, hiding the Forgot Password option at first would likely result in an increased number of calls/emails to your customer support contact point, because people unable to find the link will reach out for a human to help. You don't notice until you do this sort of thing exactly how many people just rely on "forgot password" to constantly reset their password, rather than simply remember their password.

                – Steve-O
                Mar 25 at 14:34






              • 9





                @O.R.Mapper I don't like entering wrong passwords because I'm convinced that the site is harvesting passwords for other sites.

                – JPhi1618
                Mar 25 at 14:39






              • 4





                @JPhi1618: I don't understand. If that should be the case, adding bogus data to the password collection sounds like a good thing to me.

                – O. R. Mapper
                Mar 25 at 14:49






              • 6





                Another scenario is that the user suspects that their credentials are compromised and just wants to reset them immediately.

                – Lorentz Vedeler
                Mar 25 at 14:55







              74




              74





              Indeed - to make the thought process on the user's side more explicit: Some users will, if they don't know the password, not dare to try and input anything. And, as opposed to other irrational fears about that magical computer-thing, this one is even slightly justified as (usually, repeated) wrong input of a password may result in (semi-)permanently locking the account.

              – O. R. Mapper
              Mar 25 at 10:22





              Indeed - to make the thought process on the user's side more explicit: Some users will, if they don't know the password, not dare to try and input anything. And, as opposed to other irrational fears about that magical computer-thing, this one is even slightly justified as (usually, repeated) wrong input of a password may result in (semi-)permanently locking the account.

              – O. R. Mapper
              Mar 25 at 10:22




              36




              36





              Agreed. Based on my own experience, hiding the Forgot Password option at first would likely result in an increased number of calls/emails to your customer support contact point, because people unable to find the link will reach out for a human to help. You don't notice until you do this sort of thing exactly how many people just rely on "forgot password" to constantly reset their password, rather than simply remember their password.

              – Steve-O
              Mar 25 at 14:34





              Agreed. Based on my own experience, hiding the Forgot Password option at first would likely result in an increased number of calls/emails to your customer support contact point, because people unable to find the link will reach out for a human to help. You don't notice until you do this sort of thing exactly how many people just rely on "forgot password" to constantly reset their password, rather than simply remember their password.

              – Steve-O
              Mar 25 at 14:34




              9




              9





              @O.R.Mapper I don't like entering wrong passwords because I'm convinced that the site is harvesting passwords for other sites.

              – JPhi1618
              Mar 25 at 14:39





              @O.R.Mapper I don't like entering wrong passwords because I'm convinced that the site is harvesting passwords for other sites.

              – JPhi1618
              Mar 25 at 14:39




              4




              4





              @JPhi1618: I don't understand. If that should be the case, adding bogus data to the password collection sounds like a good thing to me.

              – O. R. Mapper
              Mar 25 at 14:49





              @JPhi1618: I don't understand. If that should be the case, adding bogus data to the password collection sounds like a good thing to me.

              – O. R. Mapper
              Mar 25 at 14:49




              6




              6





              Another scenario is that the user suspects that their credentials are compromised and just wants to reset them immediately.

              – Lorentz Vedeler
              Mar 25 at 14:55





              Another scenario is that the user suspects that their credentials are compromised and just wants to reset them immediately.

              – Lorentz Vedeler
              Mar 25 at 14:55













              46














              It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.



              How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?



              You have no idea what the password is, as it will likely be some random combination of letters, numbers, characters, etc., and therefore will want to reset it straight away.






              share|improve this answer



























                46














                It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.



                How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?



                You have no idea what the password is, as it will likely be some random combination of letters, numbers, characters, etc., and therefore will want to reset it straight away.






                share|improve this answer

























                  46












                  46








                  46







                  It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.



                  How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?



                  You have no idea what the password is, as it will likely be some random combination of letters, numbers, characters, etc., and therefore will want to reset it straight away.






                  share|improve this answer













                  It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.



                  How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?



                  You have no idea what the password is, as it will likely be some random combination of letters, numbers, characters, etc., and therefore will want to reset it straight away.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Mar 25 at 9:39









                  user2397282user2397282

                  6691 silver badge5 bronze badges




                  6691 silver badge5 bronze badges





















                      12














                      Globally Consistent Convention Versus Design "Wants"



                      There is always weight towards convention in user experience/interface design for numerous reasons, but crucial systems where there is a safety/security element are ones where that should be given even higher than normal priority.




                      In my current project we need as much space as possible




                      Your reason for wanting to try breaking with a globally (externally) consistent pattern is essentially "we're lacking space".



                      Others have explained certain aspects of why this is a pattern you shouldn't break from specifically in relation to the element you're asking about. Those are great answers and this is merely meant to be a supplemental piece in addition to them. I want to address why you feel the need to break from convention in the first place and advise that you circle back to this encompassing design issue as the real reason you tried finding something to cut at all, and what therefor instead needs to be addressed.



                      Needs vs Wants



                      My simplest advice would be this: when dealing with anything related to security or safety, I recommend you consider conventional design components and layouts to be "needs" and your contravening design level issues to simply be "wants": if you can come up with a hard need related to the core purpose of the interface (for example: people are misclicking on a UI element and it is causing authentication issues), then it can be properly weighed against the various reasons already behind the conventional design needs (such as, if we move these elements to avoid misclicks, does it cause a worse issue to emerge that was already foreseen in the current design, making this a necessary evil), but until it arrives at that point it is merely a want and can generally be considered lower precedence.



                      Generally speaking, a login page/screen/modal should have as little extraneous information going on as possible, both for the sake of usability but also potentially for the sake of security (for example, avoid loading external resources where possible here). If you have a space issue on your login interface, something is almost certainly "wrong" with the encompassing design (even if this is an embedded interface of some kind). It's impossible to speculate about what per se the problem is without any related information, but I'd strongly urge you to stop trying to look for ways to break from convention here and instead look at how you can refactor the design of this interface to better fit with conventional login interface paradigms, even if it means that this screen does not perfectly match the design templating of other screens (I'd absolute advise that you keep at least related elements consistent: brand logos, colors, etc, but simply find ways to cull elements and/or reduce whitespace areas/etc that are not necessary for a login screen).



                      Login interfaces in particular have numerous usability concerns which overlap with security concerns, and breaking with conventional design--beyond the generalized usability reasons to try to stick with common convention due to related user knowledge/expectations--can have severe security implications here that are not always immediately foreseeable: don't break from convention simply to satisfy having seemingly backed yourself into a design corner where something "doesn't look nice" or "doesn't fit": re-examine the surrounding design itself so that it can encompass the conventional interface/component layout. If you have a specific need or reason to change the design related to a functionality change, that would be worth exploring (but will most likely result in the same outcome, per the other answers).



                      More simply put:



                      If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you? Look to that for something to change first.



                      "If it ain't broke, don't fix it" simply because something else is broke with it in it. Re-align your thinking as to what the issue is.



                      Convention at all costs?



                      Hardly. I'm not arguing that convention can't be wrong. I'm instead saying that an easy first step analysis is to weight convention to a degree where it isn't simply questioned at each corner, short of discovering an issue actually directly relating to the conventional choices and design themselves.



                      Hopefully the nuance here isn't lost.



                      It's entirely possible to fully unpack the reason for this, but I find it to be a generally reasonable basic rule that greatly saves on time that nearly always turns out to have been either needlessly wasted or at best poorly spent: don't rush to make changes to something that fits with convention simply because some other choice is in conflict, instead revisit the conflict with the assumption that the convention simply has more weight by default than whatever is on the other side of the conflicting issue.



                      Often whatever came into conflict with a convention will even turn out to have other shortfalls that simply weren't exposed yet: the fact that accommodating a highly standard convention is problematic in a given design or in conjunction with other design elements is often a warning sign regarding that conflicting design.



                      On the other hand, when faced with a convention that is causing direct issues (for example, in higher education, it's common to present a "mega menu" despite a complete lack of evidence that this actually helps prospective--or any--students navigate University websites, and one of the most common complaints is often difficulty navigating the website and discovering appropriate content in a meaningful way), then it's worth spending the time to do a proper analysis of what the benefits (and costs) are to changing it, even if ultimately the answer arrived at is still "no".



                      The key though is that conventional design generally unpacks not only key pre-shared knowledge and user expectations due to global consistency, but it also often represents lessons learned over the course of multiple entities and often years of exposure, some of which may be less immediately obvious and may go deeper than seemingly simple relatively superficial choices. Not always. But often.



                      Is it possible to chase down each of those reasons? Certainly. But my question is whether it's actually worth the time, especially if doing so turns into a practice you commonly turn to for solving other problems. Personally, the lesson I've learned over years of development and design, is that it's generally a waste of time and ultimately highly unproductive, and more costly than superficial analysis would assume (potentially even in devastating ways when consequences can go beyond simpler satisfaction aspects or reversible user actions), to open things up to changes of conventional choices/elements/layouts simply due to how it fits in with some other choice made, some other design element, etc.



                      Consider a push-pull door (the classic example, to lean on Norman). What if you want to design the surrounding opening clearance and doorstop area differently, so you change the handle design to allow the door to open an inch further given a design element in the doorstop area that would hit the standard pull handle in a standard vertical orientation, only now it looks like a horizontal push handle instead of a pull? Would spending time considering that have really been worth it, versus simply saying that the doorstop area's creative new design needed to accommodate the conventional design of the door interface? Was whatever new creativeness went into the doorstop area either so important or so entirely constrained to such a high level as to really be worth even exploring that, versus simply exploring an appropriate accommodation in the new design and accepting some degree of related compromise perhaps in that new design?




                      As a quick example of why it's a good idea to stick with convention particularly in circumstances where mistakes may result in worse implications than simply someone not being pleased with the flow, or the aesthetic (short of a direct functional reason to change from it, with careful exploration of related consequences): what happens if you were to reverse the order of the username and password fields? Let's say it's for a web page: ideally everything is coded correctly so every aspect of this goes across HTTPS as POST fields. What if, in trying to get clever, someone loaded a "reset password" link with the username as a get parameter (querystring)? So what happens when someone tries logging in, puts their credentials in in reverse of the input fields, and then without paying enough attention clicks the "reset password" link... and that happens to be a non https page/endpoint?



                      Even if it's https, that url with querystring is now in the server logs most likely. Which ideally are secure. And ideally there's no association now with a specific account. But it's one more potential place for that to leak.



                      What happens if someone tries entering their parameters in reverse during a presentation? This happens even with standard configurations by simple user error (accidental tab/etc), but how often would it happen if the fields were reversed? If there's a malicious actor in the audience, do they get kicked out if they manage to log in during the timeframe between the accidental password reveal and the user resetting their password, or can they keep navigating within the application? etc.




                      Aside: On Accessibility



                      (I'm writing this in relation to an assumption of this being in a web page, but similar accessibility concepts/constructs exist in other interfaces)



                      FYI, this might not be an accessibility issue if this is a webpage that you submit with the submit action being that it loads the same page again from the server with the related markup of a login attempt that did not authenticate alongside a link to the password reset.



                      Where this becomes a possible accessibility issue is that if this is dynamically AJAXed (single page application/etc), such that it sends the results to the server via client side scripting and then updates the page without reloading it, you may require ARIA tagging (most likely as live regions, and you'll need to carefully consider how much/what you mark as live regions versus not) to allow screen readers to update properly regarding the submission error and the availability of the link.



                      Particularly with screen readers, it's important to keep in mind that updates to parts of the page that aren't being interacted with can be very non obvious, especially if the person accessing the page has already explored those areas and formed a mental model in relation to them where they no longer anticipate related information being present there. In turn, it requires careful consideration (and actual testing!) to not create a circumstance where dynamic updates create an overwhelming level of immediate feedback via added aria-live decoration (while keeping a flow that allows people to reach related updated information intuitively), and you also need to pay attention to what the dynamic updates do in various screen readers in terms of cursor location changes, if any.






                      share|improve this answer




















                      • 2





                        I especially liked 'If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you?'

                        – Máté Juhász
                        Mar 27 at 8:03















                      12














                      Globally Consistent Convention Versus Design "Wants"



                      There is always weight towards convention in user experience/interface design for numerous reasons, but crucial systems where there is a safety/security element are ones where that should be given even higher than normal priority.




                      In my current project we need as much space as possible




                      Your reason for wanting to try breaking with a globally (externally) consistent pattern is essentially "we're lacking space".



                      Others have explained certain aspects of why this is a pattern you shouldn't break from specifically in relation to the element you're asking about. Those are great answers and this is merely meant to be a supplemental piece in addition to them. I want to address why you feel the need to break from convention in the first place and advise that you circle back to this encompassing design issue as the real reason you tried finding something to cut at all, and what therefor instead needs to be addressed.



                      Needs vs Wants



                      My simplest advice would be this: when dealing with anything related to security or safety, I recommend you consider conventional design components and layouts to be "needs" and your contravening design level issues to simply be "wants": if you can come up with a hard need related to the core purpose of the interface (for example: people are misclicking on a UI element and it is causing authentication issues), then it can be properly weighed against the various reasons already behind the conventional design needs (such as, if we move these elements to avoid misclicks, does it cause a worse issue to emerge that was already foreseen in the current design, making this a necessary evil), but until it arrives at that point it is merely a want and can generally be considered lower precedence.



                      Generally speaking, a login page/screen/modal should have as little extraneous information going on as possible, both for the sake of usability but also potentially for the sake of security (for example, avoid loading external resources where possible here). If you have a space issue on your login interface, something is almost certainly "wrong" with the encompassing design (even if this is an embedded interface of some kind). It's impossible to speculate about what per se the problem is without any related information, but I'd strongly urge you to stop trying to look for ways to break from convention here and instead look at how you can refactor the design of this interface to better fit with conventional login interface paradigms, even if it means that this screen does not perfectly match the design templating of other screens (I'd absolute advise that you keep at least related elements consistent: brand logos, colors, etc, but simply find ways to cull elements and/or reduce whitespace areas/etc that are not necessary for a login screen).



                      Login interfaces in particular have numerous usability concerns which overlap with security concerns, and breaking with conventional design--beyond the generalized usability reasons to try to stick with common convention due to related user knowledge/expectations--can have severe security implications here that are not always immediately foreseeable: don't break from convention simply to satisfy having seemingly backed yourself into a design corner where something "doesn't look nice" or "doesn't fit": re-examine the surrounding design itself so that it can encompass the conventional interface/component layout. If you have a specific need or reason to change the design related to a functionality change, that would be worth exploring (but will most likely result in the same outcome, per the other answers).



                      More simply put:



                      If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you? Look to that for something to change first.



                      "If it ain't broke, don't fix it" simply because something else is broke with it in it. Re-align your thinking as to what the issue is.



                      Convention at all costs?



                      Hardly. I'm not arguing that convention can't be wrong. I'm instead saying that an easy first step analysis is to weight convention to a degree where it isn't simply questioned at each corner, short of discovering an issue actually directly relating to the conventional choices and design themselves.



                      Hopefully the nuance here isn't lost.



                      It's entirely possible to fully unpack the reason for this, but I find it to be a generally reasonable basic rule that greatly saves on time that nearly always turns out to have been either needlessly wasted or at best poorly spent: don't rush to make changes to something that fits with convention simply because some other choice is in conflict, instead revisit the conflict with the assumption that the convention simply has more weight by default than whatever is on the other side of the conflicting issue.



                      Often whatever came into conflict with a convention will even turn out to have other shortfalls that simply weren't exposed yet: the fact that accommodating a highly standard convention is problematic in a given design or in conjunction with other design elements is often a warning sign regarding that conflicting design.



                      On the other hand, when faced with a convention that is causing direct issues (for example, in higher education, it's common to present a "mega menu" despite a complete lack of evidence that this actually helps prospective--or any--students navigate University websites, and one of the most common complaints is often difficulty navigating the website and discovering appropriate content in a meaningful way), then it's worth spending the time to do a proper analysis of what the benefits (and costs) are to changing it, even if ultimately the answer arrived at is still "no".



                      The key though is that conventional design generally unpacks not only key pre-shared knowledge and user expectations due to global consistency, but it also often represents lessons learned over the course of multiple entities and often years of exposure, some of which may be less immediately obvious and may go deeper than seemingly simple relatively superficial choices. Not always. But often.



                      Is it possible to chase down each of those reasons? Certainly. But my question is whether it's actually worth the time, especially if doing so turns into a practice you commonly turn to for solving other problems. Personally, the lesson I've learned over years of development and design, is that it's generally a waste of time and ultimately highly unproductive, and more costly than superficial analysis would assume (potentially even in devastating ways when consequences can go beyond simpler satisfaction aspects or reversible user actions), to open things up to changes of conventional choices/elements/layouts simply due to how it fits in with some other choice made, some other design element, etc.



                      Consider a push-pull door (the classic example, to lean on Norman). What if you want to design the surrounding opening clearance and doorstop area differently, so you change the handle design to allow the door to open an inch further given a design element in the doorstop area that would hit the standard pull handle in a standard vertical orientation, only now it looks like a horizontal push handle instead of a pull? Would spending time considering that have really been worth it, versus simply saying that the doorstop area's creative new design needed to accommodate the conventional design of the door interface? Was whatever new creativeness went into the doorstop area either so important or so entirely constrained to such a high level as to really be worth even exploring that, versus simply exploring an appropriate accommodation in the new design and accepting some degree of related compromise perhaps in that new design?




                      As a quick example of why it's a good idea to stick with convention particularly in circumstances where mistakes may result in worse implications than simply someone not being pleased with the flow, or the aesthetic (short of a direct functional reason to change from it, with careful exploration of related consequences): what happens if you were to reverse the order of the username and password fields? Let's say it's for a web page: ideally everything is coded correctly so every aspect of this goes across HTTPS as POST fields. What if, in trying to get clever, someone loaded a "reset password" link with the username as a get parameter (querystring)? So what happens when someone tries logging in, puts their credentials in in reverse of the input fields, and then without paying enough attention clicks the "reset password" link... and that happens to be a non https page/endpoint?



                      Even if it's https, that url with querystring is now in the server logs most likely. Which ideally are secure. And ideally there's no association now with a specific account. But it's one more potential place for that to leak.



                      What happens if someone tries entering their parameters in reverse during a presentation? This happens even with standard configurations by simple user error (accidental tab/etc), but how often would it happen if the fields were reversed? If there's a malicious actor in the audience, do they get kicked out if they manage to log in during the timeframe between the accidental password reveal and the user resetting their password, or can they keep navigating within the application? etc.




                      Aside: On Accessibility



                      (I'm writing this in relation to an assumption of this being in a web page, but similar accessibility concepts/constructs exist in other interfaces)



                      FYI, this might not be an accessibility issue if this is a webpage that you submit with the submit action being that it loads the same page again from the server with the related markup of a login attempt that did not authenticate alongside a link to the password reset.



                      Where this becomes a possible accessibility issue is that if this is dynamically AJAXed (single page application/etc), such that it sends the results to the server via client side scripting and then updates the page without reloading it, you may require ARIA tagging (most likely as live regions, and you'll need to carefully consider how much/what you mark as live regions versus not) to allow screen readers to update properly regarding the submission error and the availability of the link.



                      Particularly with screen readers, it's important to keep in mind that updates to parts of the page that aren't being interacted with can be very non obvious, especially if the person accessing the page has already explored those areas and formed a mental model in relation to them where they no longer anticipate related information being present there. In turn, it requires careful consideration (and actual testing!) to not create a circumstance where dynamic updates create an overwhelming level of immediate feedback via added aria-live decoration (while keeping a flow that allows people to reach related updated information intuitively), and you also need to pay attention to what the dynamic updates do in various screen readers in terms of cursor location changes, if any.






                      share|improve this answer




















                      • 2





                        I especially liked 'If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you?'

                        – Máté Juhász
                        Mar 27 at 8:03













                      12












                      12








                      12







                      Globally Consistent Convention Versus Design "Wants"



                      There is always weight towards convention in user experience/interface design for numerous reasons, but crucial systems where there is a safety/security element are ones where that should be given even higher than normal priority.




                      In my current project we need as much space as possible




                      Your reason for wanting to try breaking with a globally (externally) consistent pattern is essentially "we're lacking space".



                      Others have explained certain aspects of why this is a pattern you shouldn't break from specifically in relation to the element you're asking about. Those are great answers and this is merely meant to be a supplemental piece in addition to them. I want to address why you feel the need to break from convention in the first place and advise that you circle back to this encompassing design issue as the real reason you tried finding something to cut at all, and what therefor instead needs to be addressed.



                      Needs vs Wants



                      My simplest advice would be this: when dealing with anything related to security or safety, I recommend you consider conventional design components and layouts to be "needs" and your contravening design level issues to simply be "wants": if you can come up with a hard need related to the core purpose of the interface (for example: people are misclicking on a UI element and it is causing authentication issues), then it can be properly weighed against the various reasons already behind the conventional design needs (such as, if we move these elements to avoid misclicks, does it cause a worse issue to emerge that was already foreseen in the current design, making this a necessary evil), but until it arrives at that point it is merely a want and can generally be considered lower precedence.



                      Generally speaking, a login page/screen/modal should have as little extraneous information going on as possible, both for the sake of usability but also potentially for the sake of security (for example, avoid loading external resources where possible here). If you have a space issue on your login interface, something is almost certainly "wrong" with the encompassing design (even if this is an embedded interface of some kind). It's impossible to speculate about what per se the problem is without any related information, but I'd strongly urge you to stop trying to look for ways to break from convention here and instead look at how you can refactor the design of this interface to better fit with conventional login interface paradigms, even if it means that this screen does not perfectly match the design templating of other screens (I'd absolute advise that you keep at least related elements consistent: brand logos, colors, etc, but simply find ways to cull elements and/or reduce whitespace areas/etc that are not necessary for a login screen).



                      Login interfaces in particular have numerous usability concerns which overlap with security concerns, and breaking with conventional design--beyond the generalized usability reasons to try to stick with common convention due to related user knowledge/expectations--can have severe security implications here that are not always immediately foreseeable: don't break from convention simply to satisfy having seemingly backed yourself into a design corner where something "doesn't look nice" or "doesn't fit": re-examine the surrounding design itself so that it can encompass the conventional interface/component layout. If you have a specific need or reason to change the design related to a functionality change, that would be worth exploring (but will most likely result in the same outcome, per the other answers).



                      More simply put:



                      If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you? Look to that for something to change first.



                      "If it ain't broke, don't fix it" simply because something else is broke with it in it. Re-align your thinking as to what the issue is.



                      Convention at all costs?



                      Hardly. I'm not arguing that convention can't be wrong. I'm instead saying that an easy first step analysis is to weight convention to a degree where it isn't simply questioned at each corner, short of discovering an issue actually directly relating to the conventional choices and design themselves.



                      Hopefully the nuance here isn't lost.



                      It's entirely possible to fully unpack the reason for this, but I find it to be a generally reasonable basic rule that greatly saves on time that nearly always turns out to have been either needlessly wasted or at best poorly spent: don't rush to make changes to something that fits with convention simply because some other choice is in conflict, instead revisit the conflict with the assumption that the convention simply has more weight by default than whatever is on the other side of the conflicting issue.



                      Often whatever came into conflict with a convention will even turn out to have other shortfalls that simply weren't exposed yet: the fact that accommodating a highly standard convention is problematic in a given design or in conjunction with other design elements is often a warning sign regarding that conflicting design.



                      On the other hand, when faced with a convention that is causing direct issues (for example, in higher education, it's common to present a "mega menu" despite a complete lack of evidence that this actually helps prospective--or any--students navigate University websites, and one of the most common complaints is often difficulty navigating the website and discovering appropriate content in a meaningful way), then it's worth spending the time to do a proper analysis of what the benefits (and costs) are to changing it, even if ultimately the answer arrived at is still "no".



                      The key though is that conventional design generally unpacks not only key pre-shared knowledge and user expectations due to global consistency, but it also often represents lessons learned over the course of multiple entities and often years of exposure, some of which may be less immediately obvious and may go deeper than seemingly simple relatively superficial choices. Not always. But often.



                      Is it possible to chase down each of those reasons? Certainly. But my question is whether it's actually worth the time, especially if doing so turns into a practice you commonly turn to for solving other problems. Personally, the lesson I've learned over years of development and design, is that it's generally a waste of time and ultimately highly unproductive, and more costly than superficial analysis would assume (potentially even in devastating ways when consequences can go beyond simpler satisfaction aspects or reversible user actions), to open things up to changes of conventional choices/elements/layouts simply due to how it fits in with some other choice made, some other design element, etc.



                      Consider a push-pull door (the classic example, to lean on Norman). What if you want to design the surrounding opening clearance and doorstop area differently, so you change the handle design to allow the door to open an inch further given a design element in the doorstop area that would hit the standard pull handle in a standard vertical orientation, only now it looks like a horizontal push handle instead of a pull? Would spending time considering that have really been worth it, versus simply saying that the doorstop area's creative new design needed to accommodate the conventional design of the door interface? Was whatever new creativeness went into the doorstop area either so important or so entirely constrained to such a high level as to really be worth even exploring that, versus simply exploring an appropriate accommodation in the new design and accepting some degree of related compromise perhaps in that new design?




                      As a quick example of why it's a good idea to stick with convention particularly in circumstances where mistakes may result in worse implications than simply someone not being pleased with the flow, or the aesthetic (short of a direct functional reason to change from it, with careful exploration of related consequences): what happens if you were to reverse the order of the username and password fields? Let's say it's for a web page: ideally everything is coded correctly so every aspect of this goes across HTTPS as POST fields. What if, in trying to get clever, someone loaded a "reset password" link with the username as a get parameter (querystring)? So what happens when someone tries logging in, puts their credentials in in reverse of the input fields, and then without paying enough attention clicks the "reset password" link... and that happens to be a non https page/endpoint?



                      Even if it's https, that url with querystring is now in the server logs most likely. Which ideally are secure. And ideally there's no association now with a specific account. But it's one more potential place for that to leak.



                      What happens if someone tries entering their parameters in reverse during a presentation? This happens even with standard configurations by simple user error (accidental tab/etc), but how often would it happen if the fields were reversed? If there's a malicious actor in the audience, do they get kicked out if they manage to log in during the timeframe between the accidental password reveal and the user resetting their password, or can they keep navigating within the application? etc.




                      Aside: On Accessibility



                      (I'm writing this in relation to an assumption of this being in a web page, but similar accessibility concepts/constructs exist in other interfaces)



                      FYI, this might not be an accessibility issue if this is a webpage that you submit with the submit action being that it loads the same page again from the server with the related markup of a login attempt that did not authenticate alongside a link to the password reset.



                      Where this becomes a possible accessibility issue is that if this is dynamically AJAXed (single page application/etc), such that it sends the results to the server via client side scripting and then updates the page without reloading it, you may require ARIA tagging (most likely as live regions, and you'll need to carefully consider how much/what you mark as live regions versus not) to allow screen readers to update properly regarding the submission error and the availability of the link.



                      Particularly with screen readers, it's important to keep in mind that updates to parts of the page that aren't being interacted with can be very non obvious, especially if the person accessing the page has already explored those areas and formed a mental model in relation to them where they no longer anticipate related information being present there. In turn, it requires careful consideration (and actual testing!) to not create a circumstance where dynamic updates create an overwhelming level of immediate feedback via added aria-live decoration (while keeping a flow that allows people to reach related updated information intuitively), and you also need to pay attention to what the dynamic updates do in various screen readers in terms of cursor location changes, if any.






                      share|improve this answer















                      Globally Consistent Convention Versus Design "Wants"



                      There is always weight towards convention in user experience/interface design for numerous reasons, but crucial systems where there is a safety/security element are ones where that should be given even higher than normal priority.




                      In my current project we need as much space as possible




                      Your reason for wanting to try breaking with a globally (externally) consistent pattern is essentially "we're lacking space".



                      Others have explained certain aspects of why this is a pattern you shouldn't break from specifically in relation to the element you're asking about. Those are great answers and this is merely meant to be a supplemental piece in addition to them. I want to address why you feel the need to break from convention in the first place and advise that you circle back to this encompassing design issue as the real reason you tried finding something to cut at all, and what therefor instead needs to be addressed.



                      Needs vs Wants



                      My simplest advice would be this: when dealing with anything related to security or safety, I recommend you consider conventional design components and layouts to be "needs" and your contravening design level issues to simply be "wants": if you can come up with a hard need related to the core purpose of the interface (for example: people are misclicking on a UI element and it is causing authentication issues), then it can be properly weighed against the various reasons already behind the conventional design needs (such as, if we move these elements to avoid misclicks, does it cause a worse issue to emerge that was already foreseen in the current design, making this a necessary evil), but until it arrives at that point it is merely a want and can generally be considered lower precedence.



                      Generally speaking, a login page/screen/modal should have as little extraneous information going on as possible, both for the sake of usability but also potentially for the sake of security (for example, avoid loading external resources where possible here). If you have a space issue on your login interface, something is almost certainly "wrong" with the encompassing design (even if this is an embedded interface of some kind). It's impossible to speculate about what per se the problem is without any related information, but I'd strongly urge you to stop trying to look for ways to break from convention here and instead look at how you can refactor the design of this interface to better fit with conventional login interface paradigms, even if it means that this screen does not perfectly match the design templating of other screens (I'd absolute advise that you keep at least related elements consistent: brand logos, colors, etc, but simply find ways to cull elements and/or reduce whitespace areas/etc that are not necessary for a login screen).



                      Login interfaces in particular have numerous usability concerns which overlap with security concerns, and breaking with conventional design--beyond the generalized usability reasons to try to stick with common convention due to related user knowledge/expectations--can have severe security implications here that are not always immediately foreseeable: don't break from convention simply to satisfy having seemingly backed yourself into a design corner where something "doesn't look nice" or "doesn't fit": re-examine the surrounding design itself so that it can encompass the conventional interface/component layout. If you have a specific need or reason to change the design related to a functionality change, that would be worth exploring (but will most likely result in the same outcome, per the other answers).



                      More simply put:



                      If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you? Look to that for something to change first.



                      "If it ain't broke, don't fix it" simply because something else is broke with it in it. Re-align your thinking as to what the issue is.



                      Convention at all costs?



                      Hardly. I'm not arguing that convention can't be wrong. I'm instead saying that an easy first step analysis is to weight convention to a degree where it isn't simply questioned at each corner, short of discovering an issue actually directly relating to the conventional choices and design themselves.



                      Hopefully the nuance here isn't lost.



                      It's entirely possible to fully unpack the reason for this, but I find it to be a generally reasonable basic rule that greatly saves on time that nearly always turns out to have been either needlessly wasted or at best poorly spent: don't rush to make changes to something that fits with convention simply because some other choice is in conflict, instead revisit the conflict with the assumption that the convention simply has more weight by default than whatever is on the other side of the conflicting issue.



                      Often whatever came into conflict with a convention will even turn out to have other shortfalls that simply weren't exposed yet: the fact that accommodating a highly standard convention is problematic in a given design or in conjunction with other design elements is often a warning sign regarding that conflicting design.



                      On the other hand, when faced with a convention that is causing direct issues (for example, in higher education, it's common to present a "mega menu" despite a complete lack of evidence that this actually helps prospective--or any--students navigate University websites, and one of the most common complaints is often difficulty navigating the website and discovering appropriate content in a meaningful way), then it's worth spending the time to do a proper analysis of what the benefits (and costs) are to changing it, even if ultimately the answer arrived at is still "no".



                      The key though is that conventional design generally unpacks not only key pre-shared knowledge and user expectations due to global consistency, but it also often represents lessons learned over the course of multiple entities and often years of exposure, some of which may be less immediately obvious and may go deeper than seemingly simple relatively superficial choices. Not always. But often.



                      Is it possible to chase down each of those reasons? Certainly. But my question is whether it's actually worth the time, especially if doing so turns into a practice you commonly turn to for solving other problems. Personally, the lesson I've learned over years of development and design, is that it's generally a waste of time and ultimately highly unproductive, and more costly than superficial analysis would assume (potentially even in devastating ways when consequences can go beyond simpler satisfaction aspects or reversible user actions), to open things up to changes of conventional choices/elements/layouts simply due to how it fits in with some other choice made, some other design element, etc.



                      Consider a push-pull door (the classic example, to lean on Norman). What if you want to design the surrounding opening clearance and doorstop area differently, so you change the handle design to allow the door to open an inch further given a design element in the doorstop area that would hit the standard pull handle in a standard vertical orientation, only now it looks like a horizontal push handle instead of a pull? Would spending time considering that have really been worth it, versus simply saying that the doorstop area's creative new design needed to accommodate the conventional design of the door interface? Was whatever new creativeness went into the doorstop area either so important or so entirely constrained to such a high level as to really be worth even exploring that, versus simply exploring an appropriate accommodation in the new design and accepting some degree of related compromise perhaps in that new design?




                      As a quick example of why it's a good idea to stick with convention particularly in circumstances where mistakes may result in worse implications than simply someone not being pleased with the flow, or the aesthetic (short of a direct functional reason to change from it, with careful exploration of related consequences): what happens if you were to reverse the order of the username and password fields? Let's say it's for a web page: ideally everything is coded correctly so every aspect of this goes across HTTPS as POST fields. What if, in trying to get clever, someone loaded a "reset password" link with the username as a get parameter (querystring)? So what happens when someone tries logging in, puts their credentials in in reverse of the input fields, and then without paying enough attention clicks the "reset password" link... and that happens to be a non https page/endpoint?



                      Even if it's https, that url with querystring is now in the server logs most likely. Which ideally are secure. And ideally there's no association now with a specific account. But it's one more potential place for that to leak.



                      What happens if someone tries entering their parameters in reverse during a presentation? This happens even with standard configurations by simple user error (accidental tab/etc), but how often would it happen if the fields were reversed? If there's a malicious actor in the audience, do they get kicked out if they manage to log in during the timeframe between the accidental password reveal and the user resetting their password, or can they keep navigating within the application? etc.




                      Aside: On Accessibility



                      (I'm writing this in relation to an assumption of this being in a web page, but similar accessibility concepts/constructs exist in other interfaces)



                      FYI, this might not be an accessibility issue if this is a webpage that you submit with the submit action being that it loads the same page again from the server with the related markup of a login attempt that did not authenticate alongside a link to the password reset.



                      Where this becomes a possible accessibility issue is that if this is dynamically AJAXed (single page application/etc), such that it sends the results to the server via client side scripting and then updates the page without reloading it, you may require ARIA tagging (most likely as live regions, and you'll need to carefully consider how much/what you mark as live regions versus not) to allow screen readers to update properly regarding the submission error and the availability of the link.



                      Particularly with screen readers, it's important to keep in mind that updates to parts of the page that aren't being interacted with can be very non obvious, especially if the person accessing the page has already explored those areas and formed a mental model in relation to them where they no longer anticipate related information being present there. In turn, it requires careful consideration (and actual testing!) to not create a circumstance where dynamic updates create an overwhelming level of immediate feedback via added aria-live decoration (while keeping a flow that allows people to reach related updated information intuitively), and you also need to pay attention to what the dynamic updates do in various screen readers in terms of cursor location changes, if any.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Mar 27 at 18:39

























                      answered Mar 25 at 19:03









                      taswyntaswyn

                      2,7071 gold badge10 silver badges10 bronze badges




                      2,7071 gold badge10 silver badges10 bronze badges







                      • 2





                        I especially liked 'If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you?'

                        – Máté Juhász
                        Mar 27 at 8:03












                      • 2





                        I especially liked 'If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you?'

                        – Máté Juhász
                        Mar 27 at 8:03







                      2




                      2





                      I especially liked 'If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you?'

                      – Máté Juhász
                      Mar 27 at 8:03





                      I especially liked 'If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you?'

                      – Máté Juhász
                      Mar 27 at 8:03











                      3














                      If someone forgets their password they will first look for a forget password so this would just waste the user's time, annoying them causing them to want to leave. Also some people will use the change password to find out a username that they have forgotten so this would force then to try and remember it, annoying them. Finally some users will use the password reset to change the password, this will annoy them as most other sites will do this.



                      When designing a application/website it is all about making any action easy and fast. Hiding the forgotten password button makes it harder and slower. This should never be done.






                      share|improve this answer





























                        3














                        If someone forgets their password they will first look for a forget password so this would just waste the user's time, annoying them causing them to want to leave. Also some people will use the change password to find out a username that they have forgotten so this would force then to try and remember it, annoying them. Finally some users will use the password reset to change the password, this will annoy them as most other sites will do this.



                        When designing a application/website it is all about making any action easy and fast. Hiding the forgotten password button makes it harder and slower. This should never be done.






                        share|improve this answer



























                          3












                          3








                          3







                          If someone forgets their password they will first look for a forget password so this would just waste the user's time, annoying them causing them to want to leave. Also some people will use the change password to find out a username that they have forgotten so this would force then to try and remember it, annoying them. Finally some users will use the password reset to change the password, this will annoy them as most other sites will do this.



                          When designing a application/website it is all about making any action easy and fast. Hiding the forgotten password button makes it harder and slower. This should never be done.






                          share|improve this answer















                          If someone forgets their password they will first look for a forget password so this would just waste the user's time, annoying them causing them to want to leave. Also some people will use the change password to find out a username that they have forgotten so this would force then to try and remember it, annoying them. Finally some users will use the password reset to change the password, this will annoy them as most other sites will do this.



                          When designing a application/website it is all about making any action easy and fast. Hiding the forgotten password button makes it harder and slower. This should never be done.







                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited Mar 26 at 12:53









                          Mayo

                          5,7086 gold badges24 silver badges33 bronze badges




                          5,7086 gold badges24 silver badges33 bronze badges










                          answered Mar 26 at 9:52









                          Harry SHarry S

                          312 bronze badges




                          312 bronze badges





















                              2














                              As a user, I would be a little upset with your proposal. There are a few sites where I just don't bother to remember the password, and use the "forgot password" feature as a one-time-password system.



                              If you really need to save space, you could start with a "Forgot password?" button until something is entered in the password field.






                              share|improve this answer



























                                2














                                As a user, I would be a little upset with your proposal. There are a few sites where I just don't bother to remember the password, and use the "forgot password" feature as a one-time-password system.



                                If you really need to save space, you could start with a "Forgot password?" button until something is entered in the password field.






                                share|improve this answer

























                                  2












                                  2








                                  2







                                  As a user, I would be a little upset with your proposal. There are a few sites where I just don't bother to remember the password, and use the "forgot password" feature as a one-time-password system.



                                  If you really need to save space, you could start with a "Forgot password?" button until something is entered in the password field.






                                  share|improve this answer













                                  As a user, I would be a little upset with your proposal. There are a few sites where I just don't bother to remember the password, and use the "forgot password" feature as a one-time-password system.



                                  If you really need to save space, you could start with a "Forgot password?" button until something is entered in the password field.







                                  share|improve this answer












                                  share|improve this answer



                                  share|improve this answer










                                  answered Mar 27 at 9:45









                                  Alberto Cabello SánchezAlberto Cabello Sánchez

                                  211 bronze badge




                                  211 bronze badge





















                                      2














                                      In case you are still looking for solutions, how's this.



                                      At the very minimum - the way Google does it - you need an input box for the user name and a "Next" button.

                                      In this case, you can have the button read "Forgot password?" at first, as long as the user hasn't filled in anything in the box. Then as soon as they have input anything, change the button to "Next" to go to the input password screen.






                                      share|improve this answer



























                                        2














                                        In case you are still looking for solutions, how's this.



                                        At the very minimum - the way Google does it - you need an input box for the user name and a "Next" button.

                                        In this case, you can have the button read "Forgot password?" at first, as long as the user hasn't filled in anything in the box. Then as soon as they have input anything, change the button to "Next" to go to the input password screen.






                                        share|improve this answer

























                                          2












                                          2








                                          2







                                          In case you are still looking for solutions, how's this.



                                          At the very minimum - the way Google does it - you need an input box for the user name and a "Next" button.

                                          In this case, you can have the button read "Forgot password?" at first, as long as the user hasn't filled in anything in the box. Then as soon as they have input anything, change the button to "Next" to go to the input password screen.






                                          share|improve this answer













                                          In case you are still looking for solutions, how's this.



                                          At the very minimum - the way Google does it - you need an input box for the user name and a "Next" button.

                                          In this case, you can have the button read "Forgot password?" at first, as long as the user hasn't filled in anything in the box. Then as soon as they have input anything, change the button to "Next" to go to the input password screen.







                                          share|improve this answer












                                          share|improve this answer



                                          share|improve this answer










                                          answered Mar 27 at 11:48









                                          Mr ListerMr Lister

                                          2902 silver badges12 bronze badges




                                          2902 silver badges12 bronze badges





















                                              2














                                              As other members have pointed out, this is primarily a bad idea because it assumes that the user already has a password in mind to try.



                                              If I visit a website I haven't visited in a very long time and the password isn't in my password manager, I'll often simply just reset the password rather than trying to guess what it may be. In such a case, I wouldn't have a password in mind to use on a failed login first.



                                              Secondly, sometimes users will want to reset their password without signing in; for example, in the event of your website being breached. If the link is hidden, this is likely to frustrate users and it may not be immediately obvious how to get the link to show up.






                                              share|improve this answer



























                                                2














                                                As other members have pointed out, this is primarily a bad idea because it assumes that the user already has a password in mind to try.



                                                If I visit a website I haven't visited in a very long time and the password isn't in my password manager, I'll often simply just reset the password rather than trying to guess what it may be. In such a case, I wouldn't have a password in mind to use on a failed login first.



                                                Secondly, sometimes users will want to reset their password without signing in; for example, in the event of your website being breached. If the link is hidden, this is likely to frustrate users and it may not be immediately obvious how to get the link to show up.






                                                share|improve this answer

























                                                  2












                                                  2








                                                  2







                                                  As other members have pointed out, this is primarily a bad idea because it assumes that the user already has a password in mind to try.



                                                  If I visit a website I haven't visited in a very long time and the password isn't in my password manager, I'll often simply just reset the password rather than trying to guess what it may be. In such a case, I wouldn't have a password in mind to use on a failed login first.



                                                  Secondly, sometimes users will want to reset their password without signing in; for example, in the event of your website being breached. If the link is hidden, this is likely to frustrate users and it may not be immediately obvious how to get the link to show up.






                                                  share|improve this answer













                                                  As other members have pointed out, this is primarily a bad idea because it assumes that the user already has a password in mind to try.



                                                  If I visit a website I haven't visited in a very long time and the password isn't in my password manager, I'll often simply just reset the password rather than trying to guess what it may be. In such a case, I wouldn't have a password in mind to use on a failed login first.



                                                  Secondly, sometimes users will want to reset their password without signing in; for example, in the event of your website being breached. If the link is hidden, this is likely to frustrate users and it may not be immediately obvious how to get the link to show up.







                                                  share|improve this answer












                                                  share|improve this answer



                                                  share|improve this answer










                                                  answered Mar 27 at 14:33









                                                  AlexandraAlexandra

                                                  211 bronze badge




                                                  211 bronze badge





















                                                      0














                                                      This needs to be answered alongside the context in your question:




                                                      we need as much space as possible




                                                      I don't know what your login page looks like or why you so desperately need the space, but assuming you do, then yes, an easy thing to cut is a Forgot Password link on the first login page. It's not ideal, and you will probably lose users that come back after a while and don't want to guess a password. You need to balance that and other UX options with your need for real estate.



                                                      A more holistic approach to the problem is sharing your current login screen and its detailed space requirements. There are ways to indicate actions to users without a giant text span, and likewise there is probably a better way to solve your problem without hiding functionality.






                                                      share|improve this answer



























                                                        0














                                                        This needs to be answered alongside the context in your question:




                                                        we need as much space as possible




                                                        I don't know what your login page looks like or why you so desperately need the space, but assuming you do, then yes, an easy thing to cut is a Forgot Password link on the first login page. It's not ideal, and you will probably lose users that come back after a while and don't want to guess a password. You need to balance that and other UX options with your need for real estate.



                                                        A more holistic approach to the problem is sharing your current login screen and its detailed space requirements. There are ways to indicate actions to users without a giant text span, and likewise there is probably a better way to solve your problem without hiding functionality.






                                                        share|improve this answer

























                                                          0












                                                          0








                                                          0







                                                          This needs to be answered alongside the context in your question:




                                                          we need as much space as possible




                                                          I don't know what your login page looks like or why you so desperately need the space, but assuming you do, then yes, an easy thing to cut is a Forgot Password link on the first login page. It's not ideal, and you will probably lose users that come back after a while and don't want to guess a password. You need to balance that and other UX options with your need for real estate.



                                                          A more holistic approach to the problem is sharing your current login screen and its detailed space requirements. There are ways to indicate actions to users without a giant text span, and likewise there is probably a better way to solve your problem without hiding functionality.






                                                          share|improve this answer













                                                          This needs to be answered alongside the context in your question:




                                                          we need as much space as possible




                                                          I don't know what your login page looks like or why you so desperately need the space, but assuming you do, then yes, an easy thing to cut is a Forgot Password link on the first login page. It's not ideal, and you will probably lose users that come back after a while and don't want to guess a password. You need to balance that and other UX options with your need for real estate.



                                                          A more holistic approach to the problem is sharing your current login screen and its detailed space requirements. There are ways to indicate actions to users without a giant text span, and likewise there is probably a better way to solve your problem without hiding functionality.







                                                          share|improve this answer












                                                          share|improve this answer



                                                          share|improve this answer










                                                          answered Mar 26 at 12:06









                                                          user1717828user1717828

                                                          2691 silver badge9 bronze badges




                                                          2691 silver badge9 bronze badges



























                                                              draft saved

                                                              draft discarded
















































                                                              Thanks for contributing an answer to User Experience Stack Exchange!


                                                              • Please be sure to answer the question. Provide details and share your research!

                                                              But avoid


                                                              • Asking for help, clarification, or responding to other answers.

                                                              • Making statements based on opinion; back them up with references or personal experience.

                                                              To learn more, see our tips on writing great answers.




                                                              draft saved


                                                              draft discarded














                                                              StackExchange.ready(
                                                              function ()
                                                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f124619%2fis-there-a-problem-with-hiding-forgot-password-until-its-needed%23new-answer', 'question_page');

                                                              );

                                                              Post as a guest















                                                              Required, but never shown





















































                                                              Required, but never shown














                                                              Required, but never shown












                                                              Required, but never shown







                                                              Required, but never shown

































                                                              Required, but never shown














                                                              Required, but never shown












                                                              Required, but never shown







                                                              Required, but never shown







                                                              Popular posts from this blog

                                                              Kamusi Yaliyomo Aina za kamusi | Muundo wa kamusi | Faida za kamusi | Dhima ya picha katika kamusi | Marejeo | Tazama pia | Viungo vya nje | UrambazajiKuhusu kamusiGo-SwahiliWiki-KamusiKamusi ya Kiswahili na Kiingerezakuihariri na kuongeza habari

                                                              SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

                                                              은진 송씨 목차 역사 본관 분파 인물 조선 왕실과의 인척 관계 집성촌 항렬자 인구 같이 보기 각주 둘러보기 메뉴은진 송씨세종실록 149권, 지리지 충청도 공주목 은진현