Sunday, October 18th, 2020
Tuesday, September 15th, 2020
Saturday, September 12th, 2020
Monday, September 7th, 2020
Tuesday, September 1st, 2020
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.
Tuesday, August 11th, 2020
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.
Sunday, August 2nd, 2020
Friday, July 31st, 2020
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, July 23rd, 2020
4 Design Patterns That Violate “Back” Button Expectations – 59% of Sites Get It Wrong - Articles - Baymard Institute
Some interesting research in here around user expecations with the back button:
Generally, we’ve observed that if a new view is sufficiently different visually, or if a new view conceptually feels like a new page, it will be perceived as one — regardless of whether it technically is a new page or not. This has consequences for how a site should handle common product-finding and -exploration elements like overlays, filtering, and sorting. For example, if users click a link and 70% of the view changes to something new, most will perceive this to be a new page, even if it’s technically still the same page, just with a new view loaded in.
Friday, July 17th, 2020
Sunday, July 12th, 2020
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.
Sunday, April 19th, 2020
Saturday, April 11th, 2020