Mostly agree, but a couple of things I think aren't entirely fair.
Logins in modals are fine if the login button is not hidden in a dropdown or menu and the modal is accessible via a URL. In that context there are no extra steps as described.
I haven't used the Slack magic-link in a bit, but if I remember correctly it does not send you a temporary password, instead it sends you a temporary link that logs you in automatically. So while I agree it's annoying to go to your email just to login, once you've done that it's a lot simpler than described in the article. You just click the link.
Not to mention... it’s easy to have a login modal and a dedicated login page. Modal being the main driver.
Magic link is amazing. All enterprise software should use it. Especially if they require special character in passwords for security theatre bs.
- the point saying it pushes you to like get out of the website / product and might distract you by browsing your email is not super logical.. most websites are asking to confirm your email address by opening an email.. so it's not a real problem
I mean maybe? But I'm usually trying to accomplish something when I need to log in quickly. Usually it's to screenshare and because I don't often use the slack desktop app I have to re-cred it. Magic link makes that awesome.
Slack has the magic link — but some sites send you a one-time code you have to paste. Sort of forced two-factor authentication. It's definitely tedious, but I imagine ultimately more secure. I'd put up with it for my bank, but not for some things.
This comment on HackerNews highlights a tricky problem with enterprise logins in applications that have several ways to login and not knowing which method each user is using under the hood until the username or email has been entered:
It gives us an opportunity (especially as devs) to find a better way to handle these things. Also know that some industries (i.e. finance) have different security standards that might affect a login experience, which is another challenge for us to make easier while fulfilling those requirements.
I agree with a lot of the things in that post but disagree with the first point about Popup/Modal login and registration forms. They really do work quite well and don't have to be used in isolation, they can always be used together with login and registration pages as well depending on how they are linked internally.
Please do more magic links and less storing password strings.
Don't be clever with titles without capitals ;) This article has a main title and subtitles all not starting with the proper capital letter. Also, the different paragraphs are not numbered, so I can't refer to #1 or #2.
Regarding Splitting up the signup process across multiple pages, that is being done for security reasons, and password managers can handle it pretty well.
But for the rest, I think the article has a lot of valid points.
I would add "don't make your section headers appear visually smaller than your body copy". The font Brad's using for the section headers, while technically 3pts larger tab the body copy, appears visually smaller because it's condensed and he's using all lowercase. Make that font like 28 or 30pt and adjust font weight if necessary. Also, use sentence or title case here.
1Password does not handle multi-page logins automatically.
In fact since switching I have been fairly consistently disappointed with 1Password's quality of auto-fill compared to LastPass. Kind of regretting switching my family over (I was tempted by the prettier design).
Can't really compare to LastPass, but I've been happy with how 1Password handles various email then password logins.
This is a matter of preference. Even if it is a little jarring to read an all lowercase headline, the article styling is internally consistent and doesn't take away from readability. If anything, you could argue the headlines actually stand out even more because of the lack of caps. ¯_(ツ)_/¯
Most of these points are Brad complaining that he can't use his 1Password to fill in forms properly - I feel like it has very little to do with improving a users' experience and just fitting in with what he deems convenient.
Magic links are no where near as complex as he's stated here - there's no copy and pasting of passwords.. it's a magic link. You tap on it, it logs you straight back into the app that sent you to your inbox. It's also a fantastic way to validate email addresses.
I'd love to see user research on some of the suggestions. It's fine having you're own theory about the usability of said implementation, but what do user's think of it?
I think the reason why Notion uses "magic links" is to verify your email address.
I also have the same feeling for the magic link stuff too. Medium might be a better example than notion -since they don't have a password login.
It's a bit 'get off my lawn', this article.
Login forms in modals can provide a better UX as you can login on the current page, rather than clicking away to somewhere else. As long as there is still a URL-accessible login page somewhere.
And magic link auth can be smoother and more secure than using a password. Nothing to remember, reuse or forget. No being held hostage to the website's often crappy security policies.*
It outsources security to the user's inbox, but then so does password auth. A password reset email is just as vulnerable as a magic link email.
*It's infuriating, the number of websites I encounter where I can't use a strong generated password due to some bullshit rule. Seriously, no symbols in a password? Character limit? What??
the simpler login form design - the faster to implement it. Plus, having "industry standard" is always better, I think.
"Have a dedicated page for login". This one is so true. Let's say modal can be used but every (commercial) site should have dedicated login page. I've seen many times where company wants to run a CRM campaign to teach users to login but they cannot because there's no login page.
But why can't you use URL for a modal as well?
You can but it needs to be developed to work like that.
Lucky we're working with developers then.
Some teams unfortunately can't get things like that built. So the rule to avoid modal logins is good advice for those types of teams.
Serious question; How is that possible?