Take a look at your smartphone and delete all the apps you don’t really need. For many tasks, you can use a browser on your phone instead of an app.
Privacy-wise, browsers are preferable, because they can’t access as much of your information as an app can.
I’m glad I have this site to play with things, almost all web development and ‘front-end’ stuff leaves me cold these days. It’s all so process driven, so full of unnecessary complexities and dependencies, it’s as if the entire industry wants you to forget you can write HTML by hand and upload it somewhere and it’s a working website. It’s complexity for complexity’s sake, like what accountancy software companies did to the tax code: “Oh this is too complex you need to pay us lots of money to sort it out.” Annoying. I can see some resistance to it and there are still people making blogs and playing around with stuff, so hopefully the professional professionals will calm the fuck down at some point.
The title says it all, really. This is another great piece of writing from Paul Ford.
I’ve noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is. This has been the history of the World Wide Web, for example. Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.
Before the hagiographical praise for working with an iPad Pro, Robin nails the fundamental shape of the design process:
I had forgotten that there are two modes of design, just as there is in writing.
The first mode is understanding the problem, getting a ten-thousand foot view of the land. It’s getting people to acknowledge that this really is the problem we need to agree upon. This work needs to happen in a sketchbook in the form of messy, back-of-the-napkin drawings or in writing. All this helps you to form a proper argument and focus your thoughts.
The second mode of design is taking that ten-thousand foot view and zooming all the way in to the hairs on the back of the rabbit; figuring out the precise UI and components, the copywriting, the animations, the everything else. This should be done in a design tool like Figma or Sketch. And this is when we should be talking about color palettes, icons, design systems, and consistency.
The problem with almost all design work is that first phase never really happens. People don’t take that ten thousand foot view of the problem and are focusing instead on the pixels; they’re trapped by the system they know too well.
Yes, yes, yes! Spot on:
I think people get stuck in that second mode because productivity in design is often tied to “how many pages or frames did I design today?” when productivity should instead be thought of as “how did my understanding of the problem change?
!important in CSS are ways of solving your immediate problem …but unless you know what you’re doing, they’re probably going to create new problems.
I feel for BaseCamp, I do. But give up on the native app path. Make sure your existing web interface is a good progressive web app and you can end-run around Apple.
Design systems can often ‘read’ as very top down, but need to be bottom up to reflect the needs of different users of different services in different contexts.
I’ve yet to be involved in a design system that hasn’t struggled to some extent for participation and contribution from the whole of its design community.
Aaaaaand the circle is now complete.
It is a crisis of care.
As with anything, it’s not about the technology itself:
A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.
Another follow-on to my post about design systems and automation. Here, Matthew invokes the spirit of the much-misunderstood Luddite martyrs. It’s good stuff.
Design systems are used by greedy software companies to fatten their bottom line. UI kits replace skilled designers with cheap commoditized labor.
Agile practices pressure teams to deliver more and faster. Scrum underscores soulless feature factories that suck the joy from the craft of software development.
But progress requires more than breaking looms.
Brad weighs in on what I wrote about design systems and automation. He rightly points out that the issue isn’t with any particular tool—and a design system is, after all, a tool—but rather with the culture and processes of the organisation.
Sure, design systems have the ability to dehumanize and that’s something to actively watch out for. But I’d also say to pay close attention to the processes and organizational culture we take part in and contribute to.
There’s a full-on rant here about the dehumanising effects of what’s called “agile” at scale:
I’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.
But a design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing.
Ethan shares his thoughts on what I wrote about design systems and automation. He offers this test on whether a design system is empowering or disempowering:
Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?
When people ask where to find you on the web, what do you tell them? Your personal website can be your home on the web. Or, if you don’t like to share your personal life in public, it can be more like your office. As with your home or your office, you can make it work for your own needs. Do you need a place that’s great for socialising, or somewhere to present your work? Without the constraints of somebody else’s platform, you get to choose what works for you.
A terrific piece from Laura enumerating the many ways that having your own website can empower you.
Have you already got your own website already? Fabulous! Is there anything you can do to make it easier for those who don’t have their own sites yet? Could you help a person move their site away from a big platform? Could you write a tutorial or script that provides guidance and reassurance?
The answer to that is around 1% of the time.
If you had an application bug which occurred 1% of the time, you’d fix it. No team I’ve come across would put up with that level of reliability.
The Jevons Paradox in action:
Even if folks are on a new fast network, they’re very likely choking on the code we’re sending, rendering the potential speed improvements of 5G moot.
The longer I spend in this field, the more convinced I am that web performance is not a technical problem; it’s a people problem.
The way you build web pages—using
IntersectionObserver, for example—can have a direct effect on the climate emergency.
Webpages can be good citizens of battery life.
It’s important to measure the battery impact in Web Inspector and drive those costs down.
Reinventing the web the long way around, in a way that gives Google even more control of it. No thanks.
How Robin really feels about Google AMP:
Here’s my hot take on this: fuck the algorithm, fuck the impressions, and fuck the king. I would rather trade those benefits and burn my website to the ground than be under the boot and heel and of some giant, uncaring corporation.
There’s no sugar-coating it—AMP components are dreadfully inaccessible:
We’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.