Thursday, April 16th, 2020
Saturday, February 15th, 2020
An absolutely gorgeous piece of hypermedia!
Data visualisations and interactive widgets enliven this maze of mathematics. Dig deep—you may just uncover the secret passages that join these concepts together.
Sunday, January 19th, 2020
I feel like my problem with design in general today is that folks want to burn everything to the ground and start again all the time. Whether that’s with a website, or a new web standard, or a political policy. They don’t want to fix what’s wrong with things bit by bit, everyone wants Thing 2.0 whilst jumping over all the small improvements that are required to get there.
Tuesday, September 3rd, 2019
The new editorial project from David Byrne, as outlined in his recent Long Now talk.
Through stories of hope, rooted in evidence, Reasons to be Cheerful aims to inspire us all to be curious about how the world can be better, and to ask ourselves how we can be part of that change.
Wednesday, June 26th, 2019
Over the last fifty years, we have come to recognize that the fuel of our civilizational expansion has become the main driver of our extinction, and that of many of the species we share the planet with. We are now coming to realize that is as true of our cognitive infrastructure. Something is out of sync, felt everywhere: something amiss in the temporal order, and it is as related to political and technological shifts, shifts in our own cognition and attention, as it is to climatic ones. To think clearly in such times requires an intersectional understanding of time itself, a way of thinking that escapes the cognitive traps, ancient and modern, into which we too easily fall. Because our technologies, the infrastructures we have built to escape our past, have turned instead to cancelling our future.
James writes beautifully about rates of change.
The greatest trick our utility-directed technologies have performed is to constantly pull us out of time: to distract us from the here and now, to treat time as a kind of fossil fuel which can be endlessly extracted in the service of a utopian future which never quite arrives. If information is the new oil, we are already, in the hyper-accelerated way of present things, well into the fracking age, with tremors shuddering through the landscape and the tap water on fire. But this is not enough; it will never be enough. We must be displaced utterly in time, caught up in endless imaginings of the future while endlessly neglecting the lessons and potential actions of the present moment.
Tuesday, June 18th, 2019
I don’t know how we got to a point where chatting and sharing with friends means having to pick through adverts, and agreeing to being tracked and marketed at, and risk being exposed to, or abused by, terrible people. Our conversations and holiday snaps have become darkly marketed events. You could say this is a fair exchange but it feels wrong to me. The things being exchanged are too different, a kind of category error. It’s a wonky kind of barter in which I feel powerless and used. It’s not why I came here, to the internet.
Monday, April 8th, 2019
Thursday, February 21st, 2019
Speculative fiction as a tool for change:
We need to think harder about the future and ask: What if our policies, institutions, and societies didn’t have to be organized as they are now? Good science fiction taps us into a rich seam of radical answers to this question.
Sunday, January 27th, 2019
Side by side screenshots of websites, taken ten years apart. The whitespace situation has definitely improved. It would be interesting to compare what the overall page weights were/are though.
Thursday, December 13th, 2018
This is the real challenge for service workers:
For 30 years, we taught billions of humans that you need to be connected to the internet to consume the web via a browser! This means web users need to unlearn that web sites can’t be used offline.
Friday, November 2nd, 2018
This instance of collective action from inside a tech company is important, not just for the specifics of Google, but in acting as an example to workers in other companies.
And of all the demands, this is the one that could have the biggest effect in the US tech world:
An end to Forced Arbitration.
Tuesday, August 7th, 2018
A great long-term perspective from Rachel on the pace of change in standards getting shipped in browsers:
The pace that things are shipping, and at which bugs are fixed is like nothing we have seen before. I know from sitting around a table with representatives from each browser vendor at the CSS Working Group how important interop is. No-one wants features to be implemented differently in browsers. This is what we were asking for with WaSP, and despite the new complexity of the platform, browsers rendering standard features in different ways is becoming increasingly rare. Bugs happen, sometimes in the browser and sometimes in the spec, but there is a commitment to avoid these and to create a stable platform we can all rely on. It is exciting to be part of it.
Thursday, August 2nd, 2018
Chris has written about switching code editors. I’m a real stick-in-the-mud when it comes to switching editors. Partly that’s because I’m generally pretty happy with whatever I’m using (right now it’s Atom) but it’s also because I just don’t get that excited about software like this. I probably should care more; I spend plenty of time inside a code editor. And I should really take the time to get to grips with features like keyboard shortcuts—I’m sure I’m working very inefficiently. But, like I said, I find it hard to care enough, and on the whole, I’m content.
I was struck by this observation from Chris:
When moving, I have to take time to make sure it works pretty much like the old one.
That reminded me of a recent switch I made, not with code editors, but with browsers.
I’ve been using Chrome for years. One day it started crashing a lot. So I decided to make the switch to Firefox. Looking back, I’m glad to have had this prompt—I think it’s good to shake things up every now and then, so I don’t get too complacent (says the hypocrite who can’t be bothered to try a new code editor).
Just as Chris noticed with code editors, it was really important that I could move bookmarks (and bookmarklets!) over to my new browser. On the whole, it went pretty smoothly. I had to seek out a few browser extensions but that was pretty much it. And because I use a password manager, logging into all my usual services wasn’t a hassle.
Of all the pieces of software on my computer, the web browser is the one where I definitely spend the most time: reading, linking, publishing. At this point, I’m very used to life with Firefox as my main browser. It’s speedy and stable, and the dev tools are very similar to Chrome’s.
Maybe I’ll switch to Safari at some point. Like I said, I think it’s good to shake things up and get out of my comfort zone.
Now, if I really wanted to get out of my comfort zone, I’d switch operating systems like Dave did with his move to Windows. And I should really try using a different phone OS. Again, this is something that Dave tried with his switch to Android (although that turned out to be unacceptably creepy), and Paul did it ages ago using a Windows phone for a week.
There’s probably a balance to be struck here. I think it’s good to change code editors, browsers, even operating systems and phones every now and then, but I don’t want to feel like I’m constantly in learning mode. There’s something to be said for using tools that are comfortable and familiar, even if they’re outdated.
Friday, July 20th, 2018
There are of course things worth your time and deep consideration, and there are distractions. Profound new thinking and movements within our industry - the kind that fundamentally shifts the way we work in a positive new direction are worth your time and attention. Other things are distractions. I put new industry gossip, frameworks, software and tools firmly in the distractions category. This is the sort of content that exists in the padding between big movements. It’s the kind of stuff that doesn’t break new ground and it doesn’t make or break your ability to do your job.
Monday, June 18th, 2018
This really, really resonates with me:
I think the thing I struggle the most with right now is determining when something new is going to change the way our industry works for the better (like responsive web design did 5 or 6 years ago), and when it’s just a fad that will fade away in a year or three (which is how I feel about our obsession with things like Angular and React).
I try to avoid jumping from fad to fad, but I also don’t want to be that old guy who misses out on something that’s an important leap forward for us. I spend a lot of time thinking about the longer term impact of the things we make (and make with).
Thursday, June 7th, 2018
I think being simultaneously curious and skeptical of new technology is healthy attitude to have.
I want to learn new things in order to keep making good websites. I also think there’s a lot of value in talking about the difficulty in learning new things.
Tuesday, May 29th, 2018
The headline is terrible but this interview is an insightful look at evaluating technology.
I remember Kevin Kelly referring to the Amish as “slow geeks”, and remarking that we could all become a little more amish-ish.
It’s not that the Amish view technology as inherently evil. No rules prohibit them from using new inventions. But they carefully consider how each one will change their culture before embracing it. And the best clue as to what will happen comes from watching their neighbors.
Saturday, May 26th, 2018
The bet to make is that we’re going to see more use of specialized languages. And HTML and CSS are the grandaddy specialized languages that have enough social consensus and capital investment to be the seeds of the next generation.
Thursday, May 10th, 2018
My publishers asked me some questions. My answers turned out to be more revealing of my inner demons than I was expecting. I hope this isn’t too much oversharing, but I found it quite cathartic.
My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.
Wednesday, May 9th, 2018
Choosing tools for scaling design
Tools and processes are intertwined. A company or a department or an individual has a way of doing things—that’s the process. They also have software to carry out the process—those are the tools.
Ideally, they should be loosely coupled. You should be able to change your tools without necessarily changing your process. So swapping out, say, one framework or library for another shouldn’t involve fundamentally changing the way you work. Likewise, trying a new way of working shouldn’t require you to use unfamiliar tools.
When it comes to scaling design within organisations, the challenges are almost always around switching processes (well, really it’s about trying to change culture, but that starts with changing processes—any sufficiently advanced process is indistinguishable from culture). All too often, though, I see people getting hung up on the tools.
We need to get more efficient in how we deliver designs …so let’s switch over to this particular design tool.
I understand this desire to shortcut the work of figuring out processes and jump straight to production solutions. For one thing, it allows you to create an easy list of requirements when it comes to recruiting talent: “Join our company—you must demonstrate experience and proficiency in this tool or that library.”
But when tools and processes become tightly coupled like this, there’s a real danger of stagnation. If a process can be defined as “the way we do things around here”, that’s not something you want to tie to any particular tool or technology. Otherwise, before you know it, you’re in the frustrating situation of using outdated tools, but you can’t swap them out for newer or better-suited technologies without disrupting everyone’s work.
This is technical debt (although it applies just as much to design). You’re paying a penalty in the present because of a decision that somebody made in the past. The problem isn’t so much with the decision itself, but with the longevity of its effects.
I think it’s important to remember what a tool is: it’s a piece of technology that enables you to work faster or better. You should enjoy using your tools, but you shouldn’t be utterly dependent on any particular one. Otherwise, the tail starts wagging the dog—you are now in service to the tool, instead of the other way around.
Treat your tools like cattle, not pets. Don’t get too attached to any one technology to the detriment of missing out on others.
The tools you choose at any particular time should be suited to what you’re trying to accomplish at that time. In other words, you’ve got to figure out what you’re trying to accomplish first (the vision), then figure out how you’re going to accomplish it (the process), and only then figure out which tools are the best fit. If you jump straight to choosing tools, you could end up trying to tighten a screw with a hammer.
Alas, I’ve seen plenty of consultants who conflate strategy with tooling. They’re brought in to solve process problems and, surprise, surprise, the solution always seems to involve purchasing the software that their company sells. I’ve been guilty of this myself: I see an organisation struggling to systemise their design patterns, and I think “Oh, they should use Fractal!” …but that’s jumping the gun. They might be better served with something simpler, or something more complex (I mean, Fractal is very, very flexible but it’s still just one option—there are plenty of other pattern library tools out there).
Once you separate out the tools from the process, there’s an added benefit. Making the right technology choice is no longer a life-or-death decision. You can suck it and see. Try out the technology and see if it works. If it’s working, great! Carry on using it. If it’s not working, that’s okay too. Try something different.
I realise I’m oversimplifying things, but I honestly believe that the real challenge is not choosing the right tools, but figuring out the right process for your team.