Wednesday, August 3rd, 2022
Saturday, April 3rd, 2021
Always refreshing to see some long-term thinking applied to the web.
Monday, September 14th, 2020
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.
Monday, March 30th, 2020
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.
Tuesday, March 3rd, 2020
A ludicrously useful grab-bag of prioritisation techniques from Chris—so, so handy for workshops and sprint planning.
Monday, February 24th, 2020
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.
Sunday, June 16th, 2019
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.
Tuesday, May 28th, 2019
Krystal compares two styles of writing and applies them to onboarding.
Friday, December 28th, 2018
Well, this an interesting format experiment—the latest Black Mirror just dropped, and it’s a PDF.
Wednesday, November 21st, 2018
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.
Monday, September 24th, 2018
Procedurally generated medieval town plans. Pick a size and then have some fun with the “warp” option.
Saturday, August 11th, 2018
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.
Monday, May 21st, 2018
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
Thursday, May 3rd, 2018
A useful design strategy exercise from Marty Neumeier.
Sunday, January 14th, 2018
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.
Saturday, December 23rd, 2017
Ubiquity and consistency
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:
- Use the HTML
The advantage of the first choice is that it’s lightweight, it works everywhere, and the browser does all the hard work for you.
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.
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:
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.
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.
- The user needs to select an item from a list of options.
- Use a
- The user needs to navigate to another page.
- Use an
aelement with an
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:
- Start with user needs.
- Build an under-engineered solution—one that might not offer you much control, but that works for everyone.
- Layer on a more over-engineered solution—one that might not work for everyone, but that offers you more control.
Ubiquity, then consistency.
Monday, November 27th, 2017
The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts
Harry cautions against making assumptions about the network when it comes to front-end development:
Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.
Planning for the worst-case scenario is never a wasted effort:
If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.
Wednesday, August 9th, 2017
Monday, July 3rd, 2017
Paul has published the slides and transcript of his knock-out talk at Patterns Day. This a must-read: superb stuff!
Design systems are an attempt to add a layer of logic and reasoning over a series decisions made by complex, irrational, emotional human beings. As such, they are subject to individual perspectives, biases, and aspirations.
How does the culture in which they are made effect the resulting design?
Monday, March 20th, 2017
Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.
If you missed the other parts of this series, they are: