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.
Saturday, August 11th, 2018
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:
Thursday, March 2nd, 2017
Friday, January 27th, 2017
A practical guide to Progressive Web Apps for organisations who don’t know anything about Progressive Web Apps : Records Sound the Same
Sally gives a really good introduction to using service workers as a progressive enhancement.
Friday, January 6th, 2017
Paul is turning his excellent talk on design systems into a three part series. Here’s part one, looking at urban planning from Brasília to London.
Saturday, November 21st, 2015
We’ve been doing a lot of soul-searching at Clearleft recently; examining our values; trying to make implicit unspoken assumptions explicit and spoken. That process has unearthed some activities that have been at the heart of our company from the very start—sharing, teaching, and nurturing. After all, Clearleft would never have been formed if it weren’t for the generosity of people out there on the web sharing with myself, Andy, and Richard.
One of the values/mottos/watchwords that’s emerging is “Share what you learn.” I like that a lot. It echoes the original slogan of the World Wide Web project, “Share what you know.” It’s been a driving force behind our writing, speaking, and events.
By the way—and this should go without saying, but apparently it still needs to be said—the internships are always, always paid. I know that there are other industries where unpaid internships are the norm. I’ve even heard otherwise-intelligent people defend those unpaid internships for the experience they offer. But what kind of message does it send to someone about the worth of their work when you withhold payment for it? Our industry is young. Let’s not fall foul of the pernicious traps set by older industries that have habitualised exploitation.
In the past couple of years, Andy concocted a new internship scheme:
So this year we decided to try a different approach by scouring the end of year degree shows for hot new talent. We found them not in the interaction courses as we’d expected, but from the worlds of Product Design, Digital Design and Robotics. We assembled a team of three interns , with a range of complementary skills, gave them a space on the mezzanine floor of our new building, and set them a high level brief.
This time ‘round, the three young graduates were Chloe, Chris and Monika. They each have differing but complementary skill sets: Chloe is a user interface designer; Chris is a product designer; Monika is an artist who knows her way around hardware hacking and coding.
Once again, they were set a fairly loose brief. They should come up with something “to enrich the lives of local residents” and it should have a physical and digital component to it.
They got stuck in to researching and brainstorming ideas. At the end of each week, we’d all gather together to get a playback of what they were coming up with. It was at these playbacks that the interns were introduced to a concept that they will no doubt encounter again in their professional lives: seagulling AKA the swoop and poop. For once, it was the Clearlefties who were in the position of being swoop-and-poopers, rather than swoop-and-poopies.
As the midway point of the internship approached, there were some interesting ideas, but no clear “winner” to pursue. Something else was happening around this time too: dConstruct 2015.
There was also plenty of inspiration to be had from the dConstruct talks themselves. One talk in particular struck a chord: Dan Hill’s The City Of Things …especially the bit where he railed against the terrible state of planning application notices:
Most of the time, it ends up down the bottom of the lamppost—soiled and soggy and forgotten. This should be an amazing thing!
Hmm… sounds like something that could enrich the lives of local residents.
Not long after that, Matt Webb came to visit. He encouraged the interns to focus in on just the two ideas that really excited them rather then the 5 or 6 that they were considering. So at the next playback, they presented two potential projects—one about biking and the other about city planning. They put it to a vote and the second project won by a landslide.
That was the genesis of Notice. After that, they pulled out all the stops.
Not content with designing one device, they came up with a range of three devices to match the differing scope of planning applications. They set about making a working prototype of the device intended for the most common applications.
Last week marked the end of the project and the grand unveiling.
They’ve done a great job. All the details are on the website, including this little note I wrote about the project:
This internship programme was an experiment for Clearleft. We wanted to see what would happen if you put through talented young people in a room together for three months to work on a fairly loose brief. Crucially, we wanted to see work that wasn’t directly related to our day-to-day dealings with web design.
We offered feedback and advice, but we received so much more in return. Monika, Chloe, and Chris brought an energy and enthusiasm to the Clearleft office that was invigorating. And the quality of the work they produced together exceeded our wildest expectations.
We hereby declare this experiment a success!
Personally, I think the work they’ve produced is very strong indeed. It would be a shame for it to end now. Perhaps there’s a way that it could be funded for further development. Here’s hoping.
As impressed as I am with the work, I’m even more impressed with the people. They’re not just talented and hard work—they’re a jolly nice bunch to have around.
Monday, October 27th, 2014
I’m at Disney World for a special edition of An Event Apart, so this lightning talk from Dan Williams seems appropriate to revisit.
Monday, September 22nd, 2014
A deeply thoughtful piece (as always) by Wilson, on the mindset needed for a sustainable way of working.
When we start with the assumption that optimizing for rapid, unbounded growth is a goal, we immediately narrow the possibility space. There are only so many choices we can make that will get us there. The same choices that made annual monoculture and the shopping mall the most efficient engines for short-term growth and profit are the same qualities that made them unsustainable in the long term.
There are more ways to scale than growth. There are more ways to deepen our impact than just reaching more people. What if we put just as much effort into scaling the impact of our work over time? Can we build digital products around sustainable systems that survive long enough to outlive us, that are purpose-built to thrive without our constant cultivation?
Friday, November 30th, 2012
I wish to cover the entire Brighton Pavilion in Bakelite for my own amusement.
I really like these thoughts on the importance of design systems for the web. It’s not about providing a few perfect deliverables that won’t survive once they go live; it’s about designing for the unexpected, the unpredictable:
Design for every state, not the best state.
Thursday, July 29th, 2010
Soon the trilogy will be complete: a documentary on urban planning sounds like the perfect way for Gary Hustwit to follow up Helvetica and Objectified.
Wednesday, December 3rd, 2008
Starbucks has opened a branch in Brighton by disregarding planning permission, ignoring planning laws, and by asserting is not in fact a cafÃ© or coffee shop but a retail outlet.
Sunday, October 19th, 2008
A comprehensive set of sketches, diagrams and screenshots from Soxiam showing the evolution and iteration of interfaces on Vimeo and other sites.