You can think of flying to Mars like one of those art films where the director has to shoot the movie in a single take. Even if no scene is especially challenging, the requirement that everything go right sequentially, with no way to pause or reshoot, means that even small risks become unacceptable in the aggregate.
A terrific interview with Deb Chachra. Her new book, How Infrastructure Works sounds excellent!
It me (or at least, this is what I like to tell myself):
A lot of the time, it looks like I’m fucking about, but I’m really just internalising the problem at hand, and clearing space for it in my brain.
Just one more sleep until dConstruct—squee!
Not that I anticipate getting much sleep. My sleepnessness will partly be like that of a child on the night before Christmas. But my sleepnessness will also inevitably be that of an adult neurotically worrying about trifling details.
In reality, everything is all set. Thanks to the stellar Clearleft events team, I don’t need to lose any sleep. But my stupid brain can’t help but run a conveyer belt of potential problems through my mind: what about dongles? Power? Timings? What if there’s an impromptu rail strike? A deluge? Other emergencies you can’t even imagine?
I try to ignore those pestering pointless questions and instead think about the fantastic talks we’re going to get. I’m genuinely excited about each and every speaker. I’m pretty sure that once the day begins, I’ll forget all my worries and bliss out to the mind-expanding presentations.
The day before a conference feels kind of like the build-up to a battle. All the strategic decisions have been made, everything is in place, and now there’s nothing to do but wait.
I’ve communicated (or maybe over-communicated) all the relevant details to the speakers. And one week ago I sent one final email to the attendees with details of the schedule and some suggestions for lunch.
I also included this request:
Could you do me a favour? Would you mind getting a hold of a Covid test sometime in the next week and taking a test a day or two before dConstruct? (And if you test positive, please don’t come to the event.)
If you can’t get hold of a test (I know it can be tricky), then could you please bring a mask to wear when inside the venue?
I think asking everyone to take a test is a reasonable request, and nobody has objected to it. I worry that it’s yet another form of hygiene theatre (like providing anti-bacterial handwash for an airborne virus). After all, the antigen tests are most effective when you’ve already got symptoms. Taking a test when you don’t have symptoms might well give a negative result, but it doesn’t necessarily mean you don’t have Covid. Still, it’s a little intervention that might catch an infection that otherwise would’ve spread further.
I’m assuming that everyone coming to dConstruct is vaccinated. Maybe that’s naive on my part, but I figure if you’re intelligent enough to get a dConstruct ticket, you’re intelligent enough to protect yourself and others. So we won’t be requesting proof of vaccination. I hope my naivety aligns with reality.
See, this is all one more thing for my brain to gnaw on when I should be thinking about what a fantastic day of talks I’ve got ahead of me. Roll on tomorrow!
This is very generous of Anna! She has a deck of cards with questions she asks in product planning meetings. You can download the pack for free.
Always refreshing to see some long-term thinking applied to the web.
Trys ponders home repair projects and Postel’s Law.
As we build our pages, components, and business logic, establish where tolerance should be granted. Consider how flexible each entity should be, and on what axis. Determine which items need to be fixed and less tolerant. There will be areas where the data or presentation being accurate is more important than being flexible - document these decisions.
Over the past few years, I’ve given quite a few workshops and talks on evaluating technology. This methodical approach to evaluation and prioritisation from Trys is right up my alley!
In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.
Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.
I feel like there’s a connection here to having good design principles—the kind that explicitly value one facet over another.
A ludicrously useful grab-bag of prioritisation techniques from Chris—so, so handy for workshops and sprint planning.
Through planning and architectural design, Le Corbusier hoped to create a scientifically rational and comprehensive solution to urban problems in a way that would both promote democracy and quality of life. For him, the factory production process applied to high-rise buildings with prefabricated and standardized components is the most modern and egalitarian of urban forms.
Something something top-down design systems.
As part of the BBC’s ongoing series on deep time, Alexander Rose describes the research he’s been doing for the clock of the long now—materials, locations, ideas …all the pieces that have historically combined to allow artifacts to survive.
Krystal compares two styles of writing and applies them to onboarding.
Well, this an interesting format experiment—the latest Black Mirror just dropped, and it’s a PDF.
The terrific Hugo-winning short story about inequality, urban planning, and automation, written by Hao Jinfang and translated by Ken Liu (who translated The Three Body Problem series).
Hao Jinfang also wrote this essay about the story:
I’ve been troubled by inequality for a long time. When I majored in physics as an undergraduate, I once stared at the distribution curve for American household income that showed profound inequality, and tried to fit the data against black-body distribution or Maxwell–Boltzmann distribution. I wanted to know how such a curve came about, and whether it implied some kind of universality: something as natural as particle energy distribution functions, so natural it led to despair.
Procedurally generated medieval town plans. Pick a size and then have some fun with the “warp” option.
I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.
Some ideas on the best of use of time in sprint zero of an agile project.
- Understand your context
- Identify risks
- Understand the business process
- Get testing infrastructure
- Understand quality attributes
- Get to know the people
- Prepare an initial product backlog
- Build a walking skeleton/spike
- Build a learning backlog
A useful design strategy exercise from Marty Neumeier.
An initiative by David Brin and the Arthur C. Clarke Center For Human Imagination at UC San Diego. You are confronted with a what-if scenario, and your task is to recall any works of speculative fiction that have covered it.
Accessing more than a hundred years of science fiction thought experiments, TASAT taps into a passionate, global community of writers, scholars, librarians, and fans. We aim to curate a reading list applicable to problems and possibilities of tomorrow.
I keep thinking about this post from Baldur Bjarnason, Over-engineering is under-engineering. It took me a while to get my head around what he was saying, but now that (I think) I understand it, I find it to be very astute.
Let’s take a single interface element, say, a dropdown menu. This is the example Laura uses in her article for 24 Ways called Accessibility Through Semantic HTML. You’ve got two choices, broadly speaking:
select element.divs and spans).The advantage of the first choice is that it’s lightweight, it works everywhere, and the browser does all the hard work for you.
But…
You don’t get complete control. Because the browser is doing the heavy lifting, you can’t craft the details of the dropdown to look identical on different browser/OS combinations.
That’s where the second option comes in. By scripting your own dropdown, you get complete control over the appearance and behaviour of the widget. The disadvantage is that, because you’re now doing all the work instead of the browser, it’s up to you to do all the work—that means lots of JavaScript, thinking about edge cases, and making the whole thing accessible.
This is the point that Baldur makes: no matter how much you over-engineer your own custom solution, there’ll always be something that falls between the cracks. So, ironically, the over-engineered solution—when compared to the simple under-engineered native browser solution—ends up being under-engineered.
Is it worth it? Rian Rietveld asks:
It is impossible to style select option. But is that really necessary? Is it worth abandoning the native browser behavior for a complete rewrite in JavaScript of the functionality?
The answer, as ever, is it depends. It depends on your priorities. If your priority is having consistent control over the details, then foregoing native browser functionality in favour of scripting everything yourself aligns with your goals.
But I’m reminded of something that Eric often says:
The web does not value consistency. The web values ubiquity.
Ubiquity; universality; accessibility—however you want to label it, it’s what lies at the heart of the World Wide Web. It’s the idea that anyone should be able to access a resource, regardless of technical or personal constraints. It’s an admirable goal, and what’s even more admirable is that the web succeeds in this goal! But sometimes something’s gotta give, and that something is control. Rian again:
The days that a website must be pixel perfect and must look the same in every browser are over. There are so many devices these days, that an identical design for all is not doable. Or we must take a huge effort for custom form elements design.
So far I’ve only been looking at the micro scale of a single interface element, but this tension between ubiquity and consistency plays out at larger scales too. Take page navigations. That’s literally what browsers do. Click on a link, and the browser fetches that URL, displaying progress at it goes. The alternative, as exemplified by single page apps, is to do all of that for yourself using JavaScript: figure out the routing, show some kind of progress, load some JSON, parse it, convert it into HTML, and update the DOM.
Personally, I tend to go for the first option. Partly that’s because I like to apply the rule of least power, but mostly it’s because I’m very lazy (I also have qualms about sending a whole lotta JavaScript down the wire just so the end user gets to do something that their browser would do for them anyway). But I get it. I understand why others might wish for greater control, even if it comes with a price tag of fragility.
I think Jake’s navigation transitions proposal is fascinating. What if there were a browser-native way to get more control over how page navigations happen? I reckon that would cover the justification of 90% of single page apps.
That’s a great way of examining these kinds of decisions and questioning how this tension could be resolved. If people are frustrated by the lack of control in browser-native navigations, let’s figure out a way to give them more control. If people are frustrated by the lack of styling for select elements, maybe we should figure out a way of giving them more control over styling.
Hang on though. I feel like I’ve painted a divisive picture, like you have to make a choice between ubiquity or consistency. But the rather wonderful truth is that, on the web, you can have your cake and eat it. That’s what I was getting at with the three-step approach I describe in Resilient Web Design:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
- Enhance!
Like, say…
select element.Or…
a element with an href attribute.The pushback I get from people in the control/consistency camp is that this sounds like more work. It kinda is. But honestly, in my experience, it’s not that much more work. Also, and I realise I’m contradicting the part where I said I’m lazy, but that’s why it’s called work. This is our job. It’s not about what we prefer; it’s about serving the needs of the people who use what we build.
Anyway, if I were to rephrase my three-step process in terms of under-engineering and over-engineering, it might look something like this:
Ubiquity, then consistency.