If only our digital social networks were to exhibit this kind of faded grandeur when they no longer exist.
Sunday, January 14th, 2018
Friday, January 5th, 2018
A nice overview of the Payment Request API, which is getting more and more browser support.
Friday, December 15th, 2017
I’m giving a workshop in Hong Kong on February 21st. If you’re in the area, I’d love to see you there. If you know anyone in Hong Kong, please spread the word.
This workshop will teach you how to think in a progressive way. Together we’ll peel back the layers of the web and build upwards, creating experiences that work for everyone. From URL design to Progressive Web Apps, this journey will cover each stage of technological advancement.
Monday, October 23rd, 2017
I love what Ben is doing with this single-serving site (similar to my design principles collection)—it’s a collection of handy links and resources around voice UI:
Designing a voice interface? Here’s a useful list of lists: as many guiding principles as we could find, all in one place. List compiled and edited by Ben Sauer @bensauer.
BONUS ITEM: Have him run a voice workshop for you!
Monday, October 2nd, 2017
Sunday, August 20th, 2017
Fortune magazine published a list of all the companies who say hate groups can’t use their services anymore:
- Discover Financial Services,
- Discord, and
Digital Ocean aren’t listed in the article but they’ve also cut off the oxygen to hate groups that were using their platform.
There’s another company that I wish were on that list: Shopify. They provide Breitbart with its online store. That’s despite clause three of their Acceptable Usage Policy:
Hateful Content: You may not offer goods or services, or post or upload Materials, that condone or promote violence against people based on race, ethnicity, color, national origin, religion, age, gender, sexual orientation, disability, medical condition or veteran status.
The flimsy free speech defence looks even more spineless in light of the actions of other companies.
I’m incredibly disappointed in Shopify. I’m starting to have misgivings about appearing at events or on podcasts sponsored by Shopify—being two degrees of separation away from the hatefulness of Breitfart doesn’t sit well with me.
I sincerely hope that Shopify will change their stance, enforce their own terms of service, and dropify hate speech.
Monday, July 17th, 2017
I really like this “evil” design exercise that Jared has documented on Ev’s blog.
I broke them up into small groups of three, spreading each role across separate groups. I then asked each person to grab a sheet of paper and make their own list of ways they imagined the product’s user experience could be made worse.
Monday, July 3rd, 2017
Wednesday, May 24th, 2017
A workshop on evaluating technology
After hacking away at Indie Web Camp Düsseldorf, I stuck around for Beyond Tellerrand. I ended up giving a talk, stepping in for Ellen. I was a poor substitute, but I hope I entertained the lovely audience for 45 minutes.
After Beyond Tellerrand, I got on a train to Nuremberg …along with a dozen of my peers who were also at the event.
I arrived right in the middle of Web Week Nürnberg. Among the many events going on was a workshop that Joschi arranged for me to run called Evaluating Technology. The workshop version of my Beyond Tellerrand talk, basically.
This was an evolution of a workshop I ran a while back. I have to admit, I was a bit nervous going into this. I had no tangible material prepared; no slides, no handouts, nothing. Instead the workshop is a collaborative affair. In order for it to work, the attendees needed to jump in and co-create it with me. Luckily for me, I had a fantastic and enthusiastic group of people at my workshop.
We began with a complete braindump. “Name some tools and technologies,” I said. “Just shout ‘em out.” Shout ‘em out, they did. I struggled to keep up just writing down everything they said. This was great!
The next step was supposed to be dot-voting on which technologies to cover, but there were so many of them, we introduced an intermediate step: grouping the technologies together.
Once the technologies were grouped into categories like build tools, browser APIs, methodologies etc., we voted on which categories to cover, only then diving deeper into specific technologies.
I proposed a number of questions to ask of each technology we covered. First of all, who benefits from the technology? Is it a tool for designers and developers, or is it a tool for the end user? Build tools, task runners, version control systems, text editors, transpilers, and pattern libraries all fall into the first category—they make life easier for the people making websites. Browser features generally fall into the second category—they improve the experience for the end user.
Looking at user-facing technologies, we asked: how well do they fail? In other words, can you add this technology as an extra layer of enhancement on top of what you’re building or do you have to make it a foundational layer that’s potentially a single point of failure?
For both classes of technologies, we asked the question: what are the assumptions? What fundamental philosophy has been baked into the technology?
Now, the point of this workshop is not for me to answer those questions. I have a limited range of experience with the huge amount of web technologies out there. But collectively all of us attending the workshop will have a good range of experience and knowledge.
Interesting then that the technologies people voted for were:
- service workers,
- progressive web apps,
- web components,
- pattern libraries and design systems.
Those are topics I actually do have some experience with. Lots of the attendees had heard of these things, they were really interested in finding out more about them, but they hadn’t necessarily used them yet.
And so I ended up doing a lot of the talking …which wasn’t the plan at all! That was just the way things worked out. I was more than happy to share my opinions on those topics, but it was of a shame that I ended up monopolising the discussion. I felt for everyone having to listen to me ramble on.
Still, by the end of the day we had covered quite a few topics. Better yet, we had a good framework for categorising and evaluating web technologies. The specific technologies we covered were interesting enough, but the general approach provided the lasting value.
All in all, a great day with a great group of people.
I’m already looking forward to running this workshop again. If you think it would be valuable for your company, get in touch.
Monday, May 22nd, 2017
Calum’s write-up of the workshop I ran in Nuremberg last week.
Wednesday, April 26th, 2017
1 day public speaking workshop in Brighton for digital professionals - £95 + VAT Tickets, Thu, 18 May 2017 at 10:00 | Eventbrite
I’m not going to be around for this, but I wish I could go. If you’re in Brighton, I highly recommend this one-day workshop from Matt. He’s been doing some internal workshops at Clearleft and he’s pretty great.
Sunday, September 25th, 2016
Val Head and Sarah Drasner have teamed up to offer a two-day workshop on web animation. If you have a chance to attend, do it!
Wednesday, August 24th, 2016
I giggled at quite of few of these mashups.
Monday, July 25th, 2016
A workshop for codebar students: Build a portfolio or blog site | Charlotte Jackson, Front-end developer
Charlotte did a fantastic job putting this workshop together on the weekend. It was inspiring!
Wednesday, October 28th, 2015
It was only last week that myself and Ellen were brainstorming ideas for a combined workshop. Our enthusiasm got the better of us, and we said “Let’s just do it!” Before we could think better of it, the room was booked, and the calendar invitations were sent.
The topic was “story.”
No wait, maybe it was …”narrative.”
That’s not quite right either.
Basically, here’s the issue: at some point everyone at Clearleft needs to communicate something by telling a story. It might be a blog post. It might be a conference talk. It might be a proposal for a potential client. It might be a case study of our work. Whatever form it might take, it involves getting a message across …using words. Words are hard. We wanted to make them a little bit easier.
We did two workshops. Ellen’s was yesterday. Mine was today. They were both just about two hours in length.
Get out of my head!
Ellen’s workshop was all about getting thoughts out of your head and onto paper. But before we could even start to do that, we had to confront our first adversary: the inner critic.
You know the inner critic. It’s that voice inside you that says “You’ve got nothing new to say”, or “You’re rubbish at writing.” Ellen encouraged each of us to drag this inner critic out into the light—much like Paul Ford did with his AnxietyBox.
Each of us drew a cartoon of our inner critic, complete with speech bubbles of things our inner critic says to us.
In a bizarre coincidence, Chloe and I had exactly the same inner critic, complete with top hat and monocle.
With that foe vanquished, we proceeded with a mind map. The idea was to just dump everything out of our heads and onto paper, without worrying about what order to arrange things in.
I found it to be an immensely valuable exercise. Whenever I’ve tried to do this before, I’d open up a blank text file and start jotting stuff down. But because of the linear nature of a text file, there’s still going to be an order to what gets jotted down; without meaning to, I’ve imposed some kind of priority onto the still-unformed thoughts. Using a mind map allowed me get everything down first, and then form the connections later.
There were plenty of other exercises, but the other one that really struck me was a simple framework of five questions. Whatever it is that you’re trying to say, write down the answers to these questions about your audience:
- What are they sceptical about?
- What problems do they have?
- What’s different now that you’ve communicated your message?
- Paint a pretty picture of life for them now that you’ve done that.
- Finally, what do they need to do next?
They’re straightforward questions, but the answers can really help to make sure you’re covering everything you need to.
There were many more exercises, and by the end of the two hours, everyone had masses of raw material, albeit in an unstructured form. My workshop was supposed to help them take that content and give it some kind of shape.
The structure of stories
Ellen and I have been enjoying some great philosophical discussions about exactly what a story is, and how does it differ from a narrative structure, or a plot. I really love Ellen’s working definition: Narrative. In Space. Over Time.
This led me to think that there’s a lot that we can borrow from the world of storytelling—films, novels, fairy tales—not necessarily about the stories themselves, but the kind of narrative structures we could use to tell those stories. After all, the story itself is often the same one that’s been told time and time again—The Hero’s Journey, or some variation thereof.
So I was interested in separating the plot of a story from the narrative device used to tell the story.
To start with, I gave some examples of well-known stories with relatively straightforward plots:
- Star Wars,
- Little Red Riding Hood,
- Your CV,
- Jurassic Park, and
I asked everyone to take a story (either from that list, or think of another one) and write the plot down on post-it notes, one plot point per post-it. Before long, the walls were covered with post-its detailing the plot lines of:
- Toy Story,
- Back To The Future,
- The Three Little Pigs, and
- Pretty Woman.
Okay. That’s plot. Next we looked at narrative frameworks.
Begin at a crucial moment, then back up to explain how you ended up there.
e.g. Citizen Kane “Rosebud!”
Instead of describing the action directly, have characters tell it to one another.
In Media Res
Begin in the middle of the action. No exposition allowed, but you can drop hints.
e.g. Mad Max: Fury Road (or Star Wars, if it didn’t have the opening crawl).
Begin with a looooong zooooom into the past before taking up the story today.
e.g. 2001: A Space Odyssey.
Just the facts with no embellishment.
e.g. A police report.
You get the idea.
In a random draw, everyone received a card with a narrative device on it. Now they had to retell the story they chose using that framing. That led to some great results:
- Toy Story, retold as a conversation between Andy and his psychiatrist (dialogue),
- E.T., retold as a missing person’s report on an alien planet (distancing effect),
- Elf, retold with an introduction about the very first Christmas (backstory),
- Robocop, retold with Murphy already a cyborg, remembering his past (flashback),
- The Three Little Pigs, retold with the wolf already at the door and no explanation as to why there’s straw everywhere (in media res).
Once everyone had the hang of it, I asked them to revisit their mind maps and other materials from the previous day’s workshop. Next, they arranged the “chunks” of that story into a linear narrative …but without worrying about getting it right—it’s not going to stay linear for long. Then, everyone is once again given a narrative structure. Now try rearranging and restructuring your story to use that framework. If something valuable comes out of that, great! If not, well, it’s still a fun creative exercise.
And that was pretty much it. I had no idea what I was doing, but it didn’t matter. It wasn’t really about me. It was about helping others take their existing material and play with it.
That said, I’m glad I finally got this process out into the world in some kind of semi-formalised way. I’ve been preparing talks and articles using these narrative exercises for a while, but this workshop was just the motivation I needed to put some structure on the process.
I think I might try to create a proper deck of cards—along the lines of Brian Eno’s Oblique Strategies or Stephen Andersons’s Mental Notes—so that everyone has the option of injecting a random narrative structural idea into the mix whenever they’re stuck.
At the very least, it would be a distraction from listening to that pesky inner critic.
Wednesday, August 26th, 2015
Whatever works for you
It’s an interesting idea that I could certainly imagine being useful in certain situations such as dynamically updating an interface in real time (it feels a bit more “close to the metal” to reflect the state updates directly rather than doing it via class swapping). But there are many, many other situations where the cascade is very useful indeed.
In short, my response was “hey, like, whatever, it’s cool, each to their own.” There are many, many different kinds of websites and many, many different ways to make them. I like that.
I find that a little disheartening. Chris has written about the confidence of youth:
Discussions are always worth having. Weighing options is always interesting. Demonstrating what has worked (and what hasn’t) for you is always useful. There are ways to communicate that don’t resort to dogmatism.
There are big differences between saying:
- You can do this,
- You should do this, and
- You must do this.
My take on the inline styles discussion was that it fits firmly in the “you can do this” slot. It could be a very handy tool to have in your toolbox for certain situations. But ideally your toolbox should have many other tools. When all you have is a hammer, yadda, yadda, yadda, nail.
Like I said on the podcast, it’s a big web out there. The idea that there is “one true way” that would work on all possible projects seems unlikely—and undesirable.
“A ha!”, you may be thinking, “But you yourself talk about progressive enhancement as if it’s the one try way to build on the web—hoisted by your own petard.” Actually, I don’t. There are certainly situations where progressive enhancement isn’t workable—although I believe those cases are rarer than you might think. But my over-riding attitude towards any questions of web design and development is:
Monday, June 22nd, 2015
This one-day workshop that Cennydd is running in London on July 22nd looks like it’s going to be really good.
Saturday, May 30th, 2015
100 words 069
I made mention already of an exercise that myself and Charlotte came up with to help developers to think in terms of granular components: using a humble pair of scissors to cut up screenshots or mockups into their constituent parts.
Recently we repeated and added to this exercise. Once the groups of components are gathered together—buttons, form elements, icons, whatever—we go through each group. Everyone writes on a post-it what name they would give this component—button, formField, icon, etc. Then everyone slaps down their post-it notes at the same time. See any overlap? That’s your class name.