Performance and accessibility aren’t features that can linger at the bottom of a Jira board to be considered later when it’s convenient.
Instead we must start to see inaccessible and slow websites for what they are: a form of cruelty. And if we want to build a web that is truly a World Wide Web, a place for all and everyone, a web that is accessible and fast for as many people as possible, and one that will outlive us all, then first we must make our websites something else altogether; we must make them kind.
Frank Chimero on causing ‘good trouble’ and re-imagining the status quo to combat achievement culture | Creative Boom
It’s really easy to think that not working full bore is somehow failing your teammates or that withholding effort is poor work ethic and moral weakness. That thought is worth interrogating, though, and it all seems kind of ridiculous once you get it out in the open. There should be no guilt for refusing to work hysterically.
It’s a terribly clickbaity (and negatively phrased) title, but if you turn it around, there’s some good advcie in here for deciding where to focus when it comes to dev technology:
- Programming languages are different, but design smells are alike.
- Frameworks are different, but the same design patterns shine through.
- Developers are different, but rules of dealing with people are uniform.
Designing your design process:
- Know your strengths and focus resources on your weaknesses.
- Learn to identify the immovable objects.
- What has to be perfect now and what can be fixed later?
I’ve come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.
Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?
In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?
Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.
Some sensible answers to this question here…
…of which, exactly zero mention end users.
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.
A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.
Mike talks about the pros and cons of working with companies at different stages of design maturity:
- design hostile,
- design ignorant,
- design agnostic,
- design interested, and
- design driven.
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.
It’s ironic, isn’t it? Design is more important and respected than ever, which means we have more agency to affect change. But at the same time, our priorities have been subverted, pushed towards corporate benefit over human benefit. It’s hard to reconcile those things.
I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”
By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.
Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.
Two sides of a debate on progressive enhancement…
Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:
Joe Hoyle disagrees:
Caspar acknowledges this:
I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).
But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:
Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.
It will come as no surprise that I agree with every single word that Tim has written here.
Thoughtful points from Chris, delivered on the closing day of this year’s Brooklyn Beta.
So, the next time you feel like you’re missing out, stop it. Zoom out a little bit and give yourself some space and some perspective, so you can focus on what matters.