Sunday, March 28th, 2021
Friday, February 12th, 2021
Increasingly, I think UX doesn’t live up to its original meaning of “user experience.” Instead, much of the discpline today, as it’s practiced in Big Tech firms, is better described by a new name.
UX is now “user exploitation.”
Wednesday, January 20th, 2021
The verbs of the web are GET and POST. In theory there’s also PUT, DELETE, and PATCH but in practice POST often does those jobs.
I’m always surprised when front-end developers don’t think about these verbs (or request methods, to use the technical term). Knowing when to use GET and when to use POST is crucial to having a solid foundation for whatever you’re building on the web.
Luckily it’s not hard to know when to use each one. If the user is requesting something, use GET. If the user is changing something, use POST.
That’s why links are GET requests by default. A link “gets” a resource and delivers it to the user.
Most forms use the POST method becuase they’re changing something—creating, editing, deleting, updating.
<form method="post" action="/items/id/edit">
But not all forms should use POST. A search form should use GET.
<form method="get" action="/search"> <input type="search" name="term">
When a user performs a search, they’re still requesting a resource (a page of search results). It’s just that they need to provide some specific details for the GET request. Those details get translated into a query string appended to the URL specified in the
I sometimes see the GET method used incorrectly:
- “Log out” links that should be forms with a “log out” button—you can always style it to look like a link if you want.
- “Unsubscribe” links in emails that immediately trigger the action of unsubscribing instead of going to a form where the POST method does the unsubscribing. I realise that this turns unsubscribing into a two-step process, which is a bit annoying from a usability point of view, but a destructive action should never be baked into a GET request.
When the it was first created, the World Wide Web was stateless by design. If you requested one web page, and then subsequently requested another web page, the server had no way of knowing that the same user was making both requests. After serving up a page in response to a GET request, the server promptly forgot all about it.
The Web is named for its hyperlinked structure. In order for the web to remain vibrant, users need to be able to expect that merely visiting any given link won’t have implications for the security of their computer, or for any essential aspects of their privacy.
The expectation of safe stateless browsing has been eroded over time. Every time you click on a search result in Google, or you tap on a recommended video in YouTube, or—heaven help us—you actually click on an advertisement, you just know that you’re adding to a dossier of your online profile. That’s not how the web is supposed to work.
Don’t get me wrong: building a profile of someone based on their actions isn’t inherently wrong. If a user taps on “like” or “favourite” or “bookmark”, they are actively telling the server to perform an update (and so those actions should be POST requests). But do you see the difference in where the power lies? With POST actions—fave, rate, save—the user is in charge. With GET requests, no one is supposed to be in charge—it’s meant to be a neutral transaction. Alas, the reality of today’s web is that many GET requests give more power to the dossier-building servers at the expense of the user’s agency.
If a trade-off needs to be made, always put user needs above all.
The current abuse of GET requests is damage that the web needs to route around.
Browsers are helping to a certain extent. Most browsers have the concept of private browsing, allowing you some level of statelessness, or at least time-limited statefulness. But it’s kind of messed up that private browsing is the exception, while surveillance is the default. It should be the other way around.
Chrome has different priorities, which is understandable given that it comes from a company with a business model that is currently tied to tracking and surveillance (though it needn’t remain that way). With anti-trust proceedings rumbling in the background, there’s talk of breaking up Google to avoid monopolistic abuses of power. I honestly think it would be the best thing that could happen to Chrome if it were an independent browser that could fully focus on user needs without having to consider the surveillance needs of an advertising broker.
But we needn’t wait for the browsers to make the web a safer place for users.
Developers write the code that updates those dossiers. Developers add those oh-so-harmless-looking third-party scripts to page templates.
What if we refused?
Front-end developers in particular should be the last line of defence for users. The entire field of front-end devlopment is supposed to be predicated on the prioritisation of user needs.
And if the moral argument isn’t enough, perhaps the technical argument can get through. Tracking users based on their GET requests violates the very bedrock of the web’s architecture. Stop doing that.
Sunday, August 30th, 2020
RFC 8890 maybe the closest thing we’ve got to a Hippocratic oath right now.
A community that agrees to principles that are informed by shared values can use them to navigate hard decisions.
Many discussions influenced this document, both inside and outside of the IETF and IAB. In particular, Edward Snowden’s comments regarding the priority of end users at IETF 93 and the HTML5 Priority of Constituencies were both influential.
Monday, August 10th, 2020
Hidde gave a great talk recently called On the origin of cascades (by means of natural selectors):
It’s been 25 years since the first people proposed a language to style the web. Since the late nineties, CSS lived through years of platform evolution.
It’s a lovely history lesson that reminded me of that great post by Zach Bloom a while back called The Languages Which Almost Became CSS.
The TL;DR timeline of CSS goes something like this:
- June 1993: Rob Raisch proposes some ideas for stylesheets in HTML on the
- October 1993: Pei Wei shares his ideas for a stylesheet language, also on the
- October 1994: Håkon Wium Lie publishes Cascading HTML style sheets — a proposal.
- March 1995: Bert Bos publishes his Stream-based Style sheet Proposal.
Håkon and Bert joined forces and that’s what led to the Cascading Style Sheet language we use today.
Hidde looks at how the concept of the cascade evolved from those early days. But there’s another idea in Håkon’s proposal that fascinates me:
While the author (or publisher) often wants to give the documents a distinct look and feel, the user will set preferences to make all documents appear more similar. Designing a style sheet notation that fill both groups’ needs is a challenge.
The proposed solution is referred to as “influence”.
The user supplies the initial sheet which may request total control of the presentation, but — more likely — hands most of the influence over to the style sheets referenced in the incoming document.
So an author could try demanding that their lovely styles are to be implemented without question by specifying an influence of 100%. The proposed syntax looked like this:
h1.font.size = 24pt 100%
More reasonably, the author could specify, say, 40% influence:
h2.font.size = 20pt 40%
Here, the requested influence is reduced to 40%. If a style sheet later in the cascade also requests influence over h2.font.size, up to 60% can be granted. When the document is rendered, a weighted average of the two requests is calculated, and the final font size is determined.
Okay, that sounds pretty convoluted but then again, so is specificity.
This idea of influence in CSS reminds me of Cap’s post about The Sliding Scale of Giving a Fuck:
Hold on a second. I’m like a two-out-of-ten on this. How strongly do you feel?
I’m probably a six-out-of-ten, I replied after a couple moments of consideration.
Cool, then let’s do it your way.
In the end, the concept of influence in CSS died out, but user style sheets survived …for a while. Now they too are as dead as a dodo. Most people today aren’t aware that browsers used to provide a mechanism for applying your own visual preferences for browsing the web (kind of like Neopets or MySpace but for literally every single web page …just think of how empowering that was!).
Even if you don’t mourn the death of user style sheets—you can dismiss them as a power-user feature—I think it’s such a shame that the concept of shared influence has fallen by the wayside. Web design today is dictatorial. Designers and developers issue their ultimata in the form of CSS, even though technically every line of CSS you write is a suggestion to a web browser—not a demand.
I wish that web design were more of a two-way street, more of a conversation between designer and end user.
There are occassional glimpses of this mindset. Like I said when I added a dark mode to my website:
Y’know, when I first heard about Apple adding dark mode to their OS—and also to CSS—I thought, “Oh, great, Apple are making shit up again!” But then I realised that, like user style sheets, this is one more reminder to designers and developers that they don’t get the last word—users do.
Friday, July 24th, 2020
This is about seamful design.
We need to know things better if we want to be better.
It’s also about progressive enhancement.
Highly sophisticated systems work flawlessly, as long as things go as expected.
When a problem occurs which hasn’t been anticipated by the designers, those systems are prone to fail. The more complex the systems are, the higher are the chances that things go wrong. They are less resilient.
Thursday, April 30th, 2020
This is a great case study of the excellent California COVID-19 response site. Accessibility and performance are the watchwords here.
Want to know their secret weapon?
A $20 device running Android 9, with no contract commitment has been one of the most useful and effective tools in our effort to be accessible.
Leaner, faster sites benefit everybody, but making sure your applications run smoothly on low-end hardware makes a massive difference for those users.
I was on the podcast A Question Of Code recently. It was fun! The podcast is aimed at people who are making a career change into web development, so it’s right up my alley.
I sometimes get asked about what a new starter should learn. On the podcast, I mentioned a post I wrote a while back with links to some great resources and tutorials. As I said then:
That’s assuming you want to be a good well-rounded web developer. But it might be that you need to get a job as quickly as possible. In that case, my advice would be very different. I would advise you to learn React.
Regardless of your initial route, what’s the next step? How do you go from starting out in web development to being a top-notch web developer?
I don’t consider myself to be a top-notch web developer (far from it), but I am very fortunate in that I’ve had the opportunity to work alongside some tippety-top-notch developers at Clearleft—Trys, Cassie, Danielle, Mark, Graham, Charlotte, Andy, and Natalie.
They—and other top-notch developers I’m fortunate to know—have something in common. They prioritise users. Sure, they’ll all have their favourite technologies and specialised areas, but they don’t lose sight of who they’re building for.
When you think about it, there’s quite a power imbalance between users and developers on the web. Users can—ideally—choose which web browser to use, and maybe make some preference changes if they know where to look, but that’s about it. Developers dictate everything else—the technology that a website will use, the sheer amount of code shipped over the network to the user, whether the site will be built in a fragile or a resilient way. Users are dependent on developers, but developers don’t always act in the best interests of users. It’s a classic example of the principal-agent problem:
The principal–agent problem, in political science and economics (also known as agency dilemma or the agency problem) occurs when one person or entity (the “agent”), is able to make decisions and/or take actions on behalf of, or that impact, another person or entity: the “principal”. This dilemma exists in circumstances where agents are motivated to act in their own best interests, which are contrary to those of their principals, and is an example of moral hazard.
A top-notch developer never forgets that they are an agent, and that the user is the principal.
But is it realistic to expect web developers to be so focused on user needs? After all, there’s a whole separate field of user experience design that specialises in this focus. It hardly seems practical to suggest that a top-notch developer needs to first become a good UX designer. There’s already plenty to focus on when it comes to just the technology side of front-end development.
So maybe this is too simplistic a way of defining the principle-agent relationship between users and developers:
user :: developer
There’s something that sits in between, mediating that relationship. It’s a piece of software that in the world of web standards is even referred to as a “user agent”: the web browser.
user :: web browser :: developer
So if making the leap to understanding users seems too much of a stretch, there’s an intermediate step. Get to know how web browsers work. As a web developer, if you know what web browsers “like” and “dislike”, you’re well on the way to making great user experiences. If you understand the pain points for browser when they’re parsing and rendering your code, you’ve got a pretty good proxy for understanding the pain points that your users are experiencing.
Friday, March 27th, 2020
An interview with Joanne McNeil about her new book, Lurking:
Someone who was creating, say, a small decentralized community for a specific group of people would not have luck finding investors, as opposed to Facebook, which sought to build a platform for all.
‘Sfunny, when I was on Quarantine Book Club the other day, this is exactly what I talked about one point—how Facebook (and venture capital) moved the goalposts on what constitutes success and failure on the web.
Tuesday, February 4th, 2020
Some really interesting ideas here from Hidde on how browsers could provide optional settings for users to override developers when it comes to accessibility issues like colour contrast, focus styles, and autoplaying videos.
Thursday, August 8th, 2019
I recently wrote about a web-specific example of a general principle for choosing the right tool for the job:
I was—yet again—talking about appropriateness. Use the right technology for the task at hand. Here’s the example I gave:
Surprisingly, I got some pushback on this. Šime Vidas wrote:
Based on my experience, this is not necessarily the case.
Going from server-side rendering and progressive enhancement via JS to a single-page app powered by a JS framework was a enormous reduction in complexity for me (so the opposite of over-engineering).
(Emphasis mine.) He goes on to say:
My main concerns are ease of use & maintainability. If you get those things right, you’re good and it’s not over-engineering.
There’s no doubt that maintainability is a desirable goal. And ease of use for the developer is also important …but I think they pale in comparison to ease of use for the end user.
To be fair, the specific use-case I mentioned was making a blog. And a blog is a personal thing. You can do whatever the heck you like on your own website and don’t let anyone tell you otherwise.
So I probably chose a poor example to illustrate my point. I was thinking more about when you’re making websites for a living. You’re being paid money to make something available on the web. In that situation, I strongly believe that user needs should win out over developer convenience.
As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time.
That’s why I responded to Šime, saying:
Your main concern should be user needs—not your own.
When I talk about over-engineering, I’m speaking from the perspective of end users, not developers.
Before considering your ease of use, and maintainability, consider users first.
In fairness to Šime, he’s being very open and honest about his priorities. I admire that. I’ve seen too many developers try to provide user experience justifications for decisions made for developer convenience. Once again I recommend Alex’s excellent article, The “Developer Experience” Bait-and-Switch:
The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.
Now I worry I wasn’t specific enough when I talked about choosing appropriate technology:
Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand.
I should have made it clear that I was talking about what is appropriate or inapropriate for users. I think I made the mistake of assuming that this was obvious, and didn’t need saying. I’ll try not to make that mistake again.
If you’re in that situation—you are being paid money to make websites, and you are making technology decisions—I urge you to remember Charlie’s words: it isn’t about you.
Saturday, March 9th, 2019
Handing back control
An Event Apart Seattle was most excellent. This year, the AEA team are trying something different and making each event three days long. That’s a lot of mindblowing content!
What always fascinates me at events like these is the way that some themes seem to emerge, without any prior collusion between the speakers. This time, I felt that there was a strong thread of giving control directly to users:
Margot described this in terms of vulnerability for the brand, but the kind of vulnerability that leads to trust.
Sarah talked about it in terms of respect—respecting the privacy of users, and respecting the way that they want to use your services. Call it compassion, call it empathy, or call it just good business sense, but providing these kind of controls in an interface is an excellent long-term strategy.
In Val’s animation talk, she did a deep dive into
prefers-reduced-motion, a media query that deliberately hands control back to the user.
Even in a CSS-heavy talk like Jen’s, she took the time to explain why starting with meaningful markup is so important—it’s because you can’t control how the user will access your content. They may use tools like reader modes, or Pocket, or have web pages read aloud to them. The user has the final say, and rightly so.
In his CSS talk, Eric reminded us that a style sheet is a list of strong suggestions, not instructions.
Beth’s talk was probably the most explicit on the theme of returning control to users. She drew on examples from beyond the world of the web—from architecture, urban planning, and more—to show that the most successful systems are not imposed from the top down, but involve everyone, especially those most marginalised.
And even in my own talk on service workers, I raved about the design pattern of allowing users to save pages offline to read later. Instead of trying to guess what the user wants, give them the means to take control.
I was really encouraged to see this theme emerge. Mind you, when I look at the reality of most web products, it’s easy to get discouraged. Far from providing their users with controls over their own content, Instagram won’t even let their customers have a chronological feed. And Matt recently wrote about how both Twitter and Quora are heading further and further away from giving control to their users in his piece called Optimizing for outrage.
Still, I came away from An Event Apart Seattle with a renewed determination to do my part in giving people more control over the products and services we design and develop.
I spent the first two days of the conference trying to liveblog as much as I could. I find it really focuses my attention, although it’s also quite knackering. I didn’t do too badly; I managed to write cover eleven of the talks (out of the conference’s total of seventeen):
- Slow Design for an Anxious World by Jeffrey Zeldman
- Designing for Trust in an Uncertain World by Margot Bloomstein
- Designing for Personalities by Sarah Parmenter
- Generation Style by Eric Meyer
- Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
- Designing Intrinsic Layouts by Jen Simmons
- How to Think Like a Front-End Developer by Chris Coyier
- From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
- Move Fast and Don’t Break Things by Scott Jehl
- Mobile Planet by Luke Wroblewski
- Unsolved Problems by Beth Dean
Friday, November 30th, 2018
Ben Terrett on balancing the needs of an individual user with the needs of everyone else.
Of course we care about our clients: we want them to be successful and profitable. But we think there’s a balance to be struck between what success means for just the user or customer, and what success means for society.
Tuesday, October 23rd, 2018
This long zoom by Andy is right up my alley—a history of UX design that begins in 1880. It’s not often that you get to read something that includes Don Norman, Doug Engelbart, Lilian Gilbreth, and Vladimir Lenin. So good!
Sunday, August 12th, 2018
A terrific piece by Hidde, about CSS grid, but also about a much bigger question:
I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.
If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.
Wednesday, July 18th, 2018
Erika has written a great guest post on Ev’s blog. It covers the meaning, the impact, and the responsibility of design …and how we’ve been chasing the wrong measurements of success.
We design for the experience of a single user at a time and expect that the collective experience, and the collective impact, will take care of itself.
Wednesday, June 27th, 2018
Between the utopian and dystopian, which vision of the future seems more likely to you? Which vision seems more true to how we currently live with technology, in the form of our smartphones and social media apps?
Tuesday, June 26th, 2018
I have to admit, I didn’t realise that text reszing behaved differently for user preferences compared to page zoom. For that reason alone, I’m going to avoid setting font sizes in pixels.
If 2 to 3% (or more!) of your users are relying on a custom font size, you should know that so you can either support that user preference or make a conscious decision to not support it. Doing anything less is frankly irresponsible, especially considering that users with larger font sizes may be using those sizes to compensate for visual disabilities.
Monday, June 18th, 2018
Developer happiness is only a benefit if it first does no harm to others. Even better if it genuinely amplifies benefits to those further up chain of priorities.
Saturday, February 10th, 2018
Maybe being able to speak a foreign language is more fun than using a translation software.
Whenever we are about to substitute a laborious activity such as learning a language, cooking a meal, or tending to plants with a — deceptively — simple solution, we might always ask ourselves: Should the technology grow — or the person using it?
See, this is what I’m talking about—seamlessness is not, in my opinion, a desirable goal for its own sake. Every augmentation is also an amputation.
Some questions for us to ask ourselves as we design and build:
- Empowerment: Who’s having the fun?
- Resilience: Does it make us more vulnerable?
- Empathy: What is the impact of simplification on others?