Collection of common CSS mistakes, and how to fix them.
I like the way this is organised: it’s like “code smells” for CSS. Some of them will probably be familiar, in which case, you can dive in and find out what’s going on.
I think a lot about Danielle’s talk at Patterns Day last year.
Around about the six minute mark she starts talking about gaps and overlaps.
Gaps are where hidden complexity live. If we don’t have a category to cover it, in effect it becomes invisible. But that doesn’t mean it’s not there. Unidentified gaps cause inconsistency and confusion.
Overlaps occur when two separate categories encompass some of the same areas of responsibility. They cause conflict, duplication of effort, and unnecessary friction.
This is the bit I keep thinking about. It’s such an insightful lens to view things through. On just about any project, tensions are almost due to either gaps (“I thought someone else was doing that”) or overlaps (“Oh, you’re doing that? I thought we were doing that”).
When I was talking to Gerry on his new podcast recently, we were trying to figure out why web performance is in such a woeful state. I mused that there may be a gap. Perhaps designers think it’s a technical problem and developers think it’s a design problem. I guess you could try to bridge this gap by having someone whose job is to focus entirely on performance. But I suspect the better—but harder—solution is to create a shared culture of performance, of the kind Lara wrote about in her book:
Performance is truly everyone’s responsibility. Anyone who affects the user experience of a site has a relationship to how it performs. While it’s possible for you to single-handedly build and maintain an incredibly fast experience, you’d be constantly fighting an uphill battle when other contributors touch the site and make changes, or as the Web continues to evolve.
I suspect there’s a similar ownership gap at play when it comes to the ubiquitous obtrusive overlays that are plastered on so many websites these days.
Kirill Grouchnikov recently published a gallery of screenshots showcasing the beauty of modern mobile websites:
There are two things common between the websites in these screenshots that I took yesterday.
- They are beautifully designed, with great typography, clear branding, all optimized for readability.
- I had to install Firefox, Adblock Plus and uBlock Origin, as well as manually select and remove additional elements such as subscription overlays.
The web can be beautiful. Except it’s not right now.
How is this dissonance possible? How can designers and developers who clearly care about the user experience be responsible for unleashing such user-hostile interfaces?
I get that. But surely the solution can’t be to shrug our shoulders, pass the buck, and say “not my job.” Somebody designed each one of those obtrusive overlays. Somebody coded up each one and pushed them into production.
It’s clear that this is a problem of communication and understanding, rather than a technical problem. As always. We like to talk about how hard and complex our technical work is, but frankly, it’s a lot easier to get a computer to do what you want than to convince a human. Not least because you also need to understand what that other human wants. As Danielle says:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
So let’s say it is someone in the marketing department who is pushing to have an obtrusive newsletter sign-up form get shoved in the user’s face. Talk to them. Figure out what their goals are—what outcome are they hoping to get to. If they don’t seem to understand the user-experience implications, talk to them about that. But it needs to be a two-way conversation. You need to understand what they need before you start telling them what you want.
I realise that makes it sound patronisingly simple, and I know that in actuality it’s a sisyphean task. It may be that genuine understanding between people is the wickedest of design problems. But even if this problem seems insurmoutable, at least you’d be tackling the right problem.
Because the web can’t survive like this.
Enumerating the anti-patterns that cause serious user experience issues that don’t get nearly enough attention:
While such intrusions can be a source of irritation or even stress for many people, they may be complete showstoppers for people with anxiety or panic disorders.
I’m looking forward to reading the follow-up post.
(I was going to say I was anxiously awaiting the follow-up post but …never mind.)
This is a fun—and useful—way of improving the interview process. The Rubik’s Cube examples brought a smile to my face.
This gets nothing but agreement from me:
For altering the default scroll speed I honestly couldn’t come up with a valid use-case.
My theory is that site owners are trying to apply app-like whizz-banginess to the act of just trying to read some damn text, and so they end up screwing with the one interaction still left to the reader—scrolling.
The transcript of a terrific talk by Harry on how dark patterns are often driven by a slavish devotion to conversion rates.
Doorslamming.
Twitter has come in for a lot of (justifiable) criticism for changes to its API that make it somewhat developer-hostile. But it has to be said that developers don’t always behave responsibly when they’re using the API.
The classic example of this is the granting of permissions. James summed it up nicely: it’s just plain rude to ask for write-access to my Twitter account before I’ve even started to use your service. I could understand it if the service needed to post to my timeline, but most of the time these services claim that they want me to sign up via Twitter so that I can find my friends who are also using the service — that doesn’t require write access. Quite often, these requests to authenticate are accompanied by reassurances like “we’ll never tweet without your permission” …in which case, why ask for write-access in the first place?
To be fair, it used to be a lot harder to separate out read and write permissions for Twitter authentication. But now it’s actually not that bad, although it’s still not as granular as it could be.
One of the services that used to require write-access to my Twitter account was Lanyrd. I gave it permission, but only because I knew the people behind the service (a decision-making process that doesn’t scale very well). I always felt uneasy that Lanyrd had write-access to my timeline. Eventually I decided that I couldn’t in good conscience allow the lovely Lanyrd people to be an exception just because I knew where they lived. Fortunately, they concurred with my unease. They changed their log-in system so that it only requires read-access. If and when they need write-access, that’s the point at which they ask for it:
We now ask for read-only permission the first time you sign in, and only ask to upgrade to write access later on when you do something that needs it; for example following someone on Twitter from the our attendee directory.
Far too many services ask for write-access up front, without providing a justification. When asked for an explanation, I’m sure most of them would say “well, that’s how everyone else does it”, and they would, alas, be correct.
What’s worse is that users grant write-access so freely. I was somewhat shocked by the amount of tech-savvy friends who unwittingly spammed my timeline with automated tweets from a service called Twitter Counter. Their reactions ranged from sheepish to embarrassed to angry.
I urge you to go through your Twitter settings and prune any services that currently have write-access that don’t actually need it. You may be surprised by the sheer volume of apps that can post to Twitter on your behalf. Do you trust them all? Are you certain that they won’t be bought up by a different, less trustworthy company?
If a service asks me to sign up but insists on having write-access to my Twitter account, it feels like being asked out on a date while insisting I sign a pre-nuptial agreement. Not only is somewhat premature, it shows a certain lack of respect.
Not every service behaves so ungallantly. Done Not Done, 1001 Beers, and Mapalong all use Twitter for log-in, but none of them require write-access up-front.
Branch and Medium are typical examples of bad actors in this regard. The core functionality of these sites has nothing to do with posting to Twitter, but both sites want write-access so that they can potentially post to Twitter on my behalf later on. I know that I won’t ever want either service to do that. I can either trust them, or not use the service at all. Signing up without granting write-access to my Twitter account isn’t an option.
I sent some feedback to Branch and part of their response was to say the problem was with the way Twitter lumps permissions together. That used to be true, but Lanyrd’s exemplary use of Twitter for log-in makes that argument somewhat hollow.
In the case of Branch, Medium, and many other services, Twitter authentication is the only way to sign up and start using the service. Using a username and password isn’t an option. On the face of it, requiring Twitter for authentication doesn’t sound all that different to requiring an email address for authentication. But demanding write-access to Twitter is the equivalent of demanding the ability to send emails from your email address.
The way that so many services unnecessarily ask for write-access to Twitter—and the way that so many users unquestioningly grant it—reminds me of the password anti-pattern all over again. Because this rude behaviour is so prevalent, it has now become the norm. If we want this situation to change, we need to demand more respect.
The next time that a service demands unwarranted write-access to your Twitter account, refuse to grant it. Then tell the people behind that service why you’re refusing to sign up.
And please take a moment to go through the services you’ve already authorised.
CSSquirrel shares my feelings on the email notification anti-pattern.
Quite quickly after I wrote my email to Findings about their email notification anti-pattern, I got a response back from Lauren Leto:
Give it to us. I applaud you shouting at us from a rooftop. I also hate defaulting to all notifications and agree that it was a douchebag startup move but can assure it was one made accidentally - a horrible oversight that the entire team feels bad about and will work to amend for you and the rest of our users.
We try to be a site for the common user - nothing like Facebook taking cheap shots wherever they can. I hope we haven’t forever turned you off from our site. Relaunches are hard and mistakes were made but nothing like this will happen again.
Apart from the use of the passive voice (“mistakes were made” rather than “we made mistakes”), that’s a pretty damn good response. She didn’t try to defend or justify the behaviour. That’s good.
She also asked if there was anything they could do to make it up to me. I asked if I could publish their response here. “Yeah, feel free to post”, she said.
I think it’s important that situations like this get documented. It could be especially useful for new start-ups who might be thinking about indulging in a bit of “growth hacking” (spit!) under the impression that this kind of behaviour is acceptable just because other start-ups—like Findings—implemented the email notification anti-pattern.
As Lauren said:
I think every startup manages to mess up one of these at some point in their life, either willingly or unwillingly. A clear listing of all offenses could be useful to everyone.
That’s where Harry’s Dark Patterns wiki comes in:
The purpose of this pattern library is to “name and shame” Dark Patterns and the companies that use them.
- For consumers, forewarned is fore-armed.
- For brand-owners, the bad-press associated with being named as an offender should discourage usage.
- For designers, this site provides ammunition to refuse unethical requests by our clients / bosses. (e.g. “I won’t implement opt-out defaults for the insurance upsells because that practice is considered unethical and it will get you unwanted bad press.”)
The email notification anti-pattern isn’t yet listed on the wiki. I’ll see if I can get Harry to add it.
Dear Findings,
I see you have introduced some new email notifications. I have also noticed (via my newly-overstuffed inbox) that by default, these new email notifications are checked.
WHAT THE FSCK WERE YOU THINKING‽
Sorry. Sorry. I lost my temper for a moment there. And the question is rhetorical because I think I know exactly what you were thinking …“traction”, “retention”, “engagement”, yadda yadda.
I realise that many other sites also do this. That does not make it right. In fact, given the sites that already do this include such pillars of empathy as Facebook, I would say that this kind of behaviour probably has a one-to-one correlation with the douchebaggery of the site in question.
You’re better than this.
Stop. Think. Spare a thought for those of us who don’t suddenly—from one day to the next—want our inboxes spammed by emails we never opted into.
Didn’t anybody stop to think about just how intrusive this would be?
Also, doesn’t this flood of new emails directly contradict this section of your privacy policy?:
As part of the Services, you may occasionally receive email and other communications from us, such as communications relating to your Account. Communications relating to your Account will only be sent for purposes important to the Services, such as password recovery.
Contrary to appearances, I don’t want to be completely negative, so I’ve got a constructive suggestion.
How about this:
If you’re about to introduce new email notifications, and all my existing notification settings are set to “off”, perhaps you could set the new notifications to “off” as well?
Sound good?
All the best,
Jeremy
Yes, yes, yes! This article does an excellent job of explaining what Captchas are attempting to do and why, therefore, they are so utterly shit.
Excellent points, eloquently delivered, on why sites shouldn’t be shoving their native Apps in the face of people who just arrived at their website on a mobile device.
Putting up a splash screen is like McDonalds putting a bouncer on the door, and telling customers who just parked their car and want to enter the restaurant that they should use the drive-through instead.
Two months ago, I called Twitter out on their insistence that developers use OAuth when authorising with Twitter while they themselves continued to use the password anti-pattern when they wanted to peek into third-party address books.
I’m happy to report that Twitter have since fixed this. If you go to the Find Friends portion of the “Who To Follow” section, you’ll now be greeted with links that lead to correct authentication with LinkedIn, Gmail, Yahoo and Hotmail.
Thanks, Twitteroonies!
Meanwhile, Flickr recently launched their own “Who to Follow” functionality. There is nary a password request in sight: they’ve implemented correct authentication right out of the gate for Yahoo, Gmail, Hotmail and Facebook.
Thanks, Flickroonies!
See? I’m not always bitching’n’moaning.
The OAuthcalypse is upon us. Since August 31st, all third-party Twitter services must use OAuth to authenticate. This is a good thing; a very good thing. Before that date, services were allowed to use the password anti-pattern to log you in.
Twitter has put its foot down and declared that the password anti-pattern will no longer be tolerated. Hurrah!
What a shame then, that Twitter is being utterly hypocritical. On their Find Friends page, they encourage you to:
Scan your email address book or contacts to discover which of your friends are already using Twitter.
They do this using the password anti-pattern. You are asked for your Gmail password even though the Google Contacts API would allow Twitter to connect to Gmail using proper authentication …exactly what Twitter is insisting third-parties use when they want to access Twitter’s data.
Twitter asks for your Yahoo Mail password even though the Yahoo Contacts API would allow them access to your address book using OAuth.
Twitter asks for AOL passwords (now there’s an audience that we shouldn’t be teaching to give their passwords away) but even AOL has an API with proper authentication.
Twitter does connect to LinkedIn correctly. That’s one out of four.
There are two solutions to this state of affairs. Either Twitter decides to do the right thing and switch over to using APIs and authentication for Gmail, Yahoo and AOL …or else Gmail, Yahoo and AOL follow Twitter’s example and disallow the password anti-pattern for scraping address books.
Twitter should not be encouraging Gmail users, Yahoo users and AOL users to divulge their passwords but at the same time, Gmail, Yahoo and AOL should be taking steps to ensure that such profligate behaviour is not rewarded.
Twitter has done the right thing with third-party services wishing to access its data. Now let’s see if the third-party services currently being abused by Twitter will follow this example.
Update: There are some very encouraging responses from Twitter. Ryan Sarver says:
all good points and I think there are already plans to fix it
And Josh Elman concurs:
yes - great points and something we hope to migrate very soon
A quick way of leaving Facebook, Twitter, Linked In and MySpace. It uses the password anti-pattern but after using this, I guess you won't be needing that password again.
And this, boys and girls, is why the password anti-pattern is bad, m'kay?
A PMOG mission where players learn about the password anti-pattern.
Twitter's promotion of the password anti-pattern bites them on the ass.
Twply is a straightforward little Twitter app that sends @replies to email. It uses the password anti-pattern. Oh, but don’t worry. It states quite clearly on the site that Your password is safe with us. No worries!
Twply is up for sale …sold. That means all those passwords are available to the highest bidder ($1200 in this case).
Sleep tight, Twply users. May you wake to a better day.