Is there a problem with hiding “forgot password” until it's needed? The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Should 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”?
Match Roman Numerals
How long does the line of fire that you can create as an action using the Investiture of Flame spell last?
Why does this iterative way of solving of equation work?
Program that generates brainfuck code that outputs given text
Finding the path in a graph from A to B then back to A with a minimum of shared edges
How did passengers keep warm on sail ships?
What information about me do stores get via my credit card?
What do you call a plan that's an alternative plan in case your initial plan fails?
Mortgage adviser recommends a longer term than necessary combined with overpayments
Can smartphones with the same camera sensor have different image quality?
How does ice melt when immersed in water?
How to split app screen on my Mac?
Did God make two great lights or did He make the great light two?
Slither Like a Snake
Is it ok to offer lower paid work as a trial period before negotiating for a full-time job?
Would an alien lifeform be able to achieve space travel if lacking in vision?
rotate text in posterbox
"... to apply for a visa" or "... and applied for a visa"?
Did the UK government pay "millions and millions of dollars" to try to snag Julian Assange?
Pandas DataFrames: Create new rows with calculations across existing rows
ELI5: Why do they say that Israel would have been the fourth country to land a spacecraft on the Moon and why do they call it low cost?
Typeface like Times New Roman but with "tied" percent sign
How did the audience guess the pentatonic scale in Bobby McFerrin's presentation?
Is there a trick to getting spices to fix to nuts?
Is there a problem with hiding “forgot password” until it's needed?
The 2019 Stack Overflow Developer Survey Results Are In
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Should 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;
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
|
show 13 more comments
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
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
|
show 13 more comments
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
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
login password dynamic-ui
edited Mar 25 at 23:25
DxTx
1035
1035
asked Mar 25 at 9:08
hans wrusthans wrust
263124
263124
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
|
show 13 more comments
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
|
show 13 more comments
8 Answers
8
active
oldest
votes
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.
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
|
show 7 more comments
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.
add a comment |
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.
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
|
show 7 more comments
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.
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
|
show 7 more comments
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.
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.
answered Mar 25 at 9:39
Shreyas TripathyShreyas Tripathy
5,03731936
5,03731936
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
|
show 7 more comments
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
|
show 7 more comments
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 25 at 9:39
user2397282user2397282
56514
56514
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
edited Mar 27 at 18:39
answered Mar 25 at 19:03
taswyntaswyn
2,6771010
2,6771010
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Mar 26 at 12:53
Mayo
5,60852433
5,60852433
answered Mar 26 at 9:52
Harry SHarry S
312
312
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 27 at 9:45
Alberto Cabello SánchezAlberto Cabello Sánchez
211
211
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 27 at 11:48
Mr ListerMr Lister
290212
290212
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 27 at 14:33
AlexandraAlexandra
211
211
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 26 at 12:06
user1717828user1717828
27419
27419
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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