Container queries can’t be used in the sizes attribute for responsive images. Here, Jason breaks down why that is (spoiler: it’s the lookahead pre-parser) and segues into a truly long term solution: a “magical” image format.
If you’ve ever thought it felt weird to put media conditions inside the HTML for responsive images, this will resonate.
I’ve been redesigning UX London. I don’t mean the website. I mean the event itself.
Don’t worry, it’s nothing too radical. It’s not like we’re changing the focus of the event, which remains a nerdfest for all things design-related.
But there are plenty of other opportunities for tweaking a conference like this: the format, the timings, the location.
For 2023 we’re not changing the location. Tobacco Dock worked out well for last year’s event, although it is very expensive (then again, so is anywhere decent in London). Last year there were a lot of unknowns in play because it was our first time using the venue. It feels good that this year we don’t have to go through quite as much uncertainty.
The most obvious change to UX London this year is the length. The event will last for two days instead of three.
Running a three-day event was a lot of work, so this helps relieve the pressure. It was also asking a lot of attendees. That’s why we also offered one-day tickets. For the people who couldn’t commit to three days at a conference, there was the option to pick and choose.
But that brought its own issues. Instead of everyone having the same shared experience, the audience was a bit fractured.
Now that we’ve slimmed it down to two days, we’re selling the same two-day tickets for everyone. No more single-day tickets; no more partial attendance. Judging by the way ticket sales have been going, this is a very welcome move.
(Even before announcing any speakers, we had already sold a healthy amount of tickets. That’s probably testament to the great reputation that UX London has built up over the years. I need to make sure I don’t squander that good will. No pressure.)
On the subject of everyone having a shared experience, there’s something about the format of UX London that’s bothered me for a while…
Each day is split into two halves. In the morning, you’ve got inspirational talks. That’s one single track. Then in the afternoon, you’ve got hands-on practical workshops. They happen in parallel.
That makes for a great mix, but the one downside is that the day ends with the audience split across the different workshops.
This year I’m tweaking the format slightly. We’ll still have a single track of talks in the morning followed by multiple workshops in the afternoon, but I’m shortening the workshop length slightly to fit in one last talk at the end of the day. That way, everybody will come back together again after their workshops to participate in a shared experience.
The audience will converge at the beginning of the day, diverge in the afternoon, and this time we’ll converge again at day’s end.
The workshops are a big part of what makes UX London stand out. But they also pose a big design challenge. How do you ensure that everyone gets to attend the workshops they want?
We could make people pick their workshops in advance. But then you end up with the office Christmas dinner party problem—you know the one; everyone has to choose their meal way in advance, and then on the day, no one remembers what they ordered.
Besides, if we make people choose in advance, it’s not fair on people who buy their ticket close to the event.
In the end, using a first-come, first-served strategy on the day has worked out best. But it’s not ideal. You could miss out on attending your first choice of workshop if you’re not fast enough.
This year we’re trying something new. Each afternoon there’ll be a choice of workshops, as always. But this time, it’ll be the same workshops on both days. That way, every attendee gets a second chance to get to the workshops they want. And it’ll help reduce the FOMO—Fear Of Missing Out. It still won’t be possible to attend all the workshops without cloning yourself, but this way, you get to attend half of them.
To recap, here’s the redesigned format for UX London 2023:
The line-up is coming together nicely. I’ve got more confirmed speakers, who I don’t want to reveal just yet. But trust me, you won’t want to miss this!
Oh, and you should probably grab your ticket this week if you haven’t already: early-bird pricing ends on midnight on Friday, February 24th.
Mat has written this free course for you all about images on the web. Covering image formats, responsive images, and workflows, this is one to keep on speed dial.
I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?
That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.
This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.
Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:
/things/things/new/things/searchAnd then an idividual item can be found at:
things/IDThat’s all nice and predictable and the naming of the URLs matches what you’d expect to find:
Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:
When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.
Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.
So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.
Here’s my dilemma: if I update the label, should I also update the URL structure?
Right now, the section of the site with /tunes URLs is labelled “tunes”. The section of the site with /events URLs is labelled “events”. Currently the section of the site with /recordings URLs is labelled “recordings”, but may soon be labelled “discography”.
If you click on “tunes”, you end up at /tunes. But if you click on “discography”, you end up at /recordings.
Is that okay? Am I the only one that would be bothered by that?
I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:
/discography/discography/new/discography/search/discography/IDIt doesn’t seem as tidy as:
/recordings/recordings/new/recordings/search/recordings/IDBut if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.
I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.
Guess which format is going to outlast all these proprietary syndication formats. I’d say RSS, which I believe to be true, but really, it’s HTML.
A great write-up from Hidde on dConstruct 2022 and how the speakers tackled the theme of design transformation:
They talked about turning a series of penstrokes into art, lasers into fireworks, human experiences into novels and patient data collection into a minimal effort task.
A lot of our work in web design and technology has a power to transform and that is wonderful, especially when we manage to be intentional about the how and why.
Kevin takes my eleven-year old remark literally and points out at least you can emulate LaserDiscs:
So LaserDiscs aren’t the worst things to archive, networks of servers running code that isn’t available or archivable are, and we are building a lot more of those these days, whether on the web or in apps.
I love this: Terence takes eleven years to reflect on a comment I made on stage at an event here in Brighton. It’s all about the longevity of the web compared to native apps:
If you wrote an app for an early version of iOS or Android, it simply won’t run on modern hardware or software. APIs have changed, SDKs weren’t designed with forward compatibility, and app store requirements have evolved.
The web has none of that. The earliest websites are viewable on modern browsers.
As wrote at the time, I may have been juicing things up for entertainment:
Now here’s the thing when it comes to any discussion about mobile or the web or anything else of any complexity: an honest discussion would result in every single question being answered with “it depends”. A more entertaining discussion, on the other hand, would consist of deliberately polarised opinions. We went for the more entertaining discussion.
But I think this still holds true for me today:
The truth is that the whole “web vs. native” thing doesn’t interest me that much. I’m as interested in native iOS development as I am in native Windows development or native CD-ROM development. On a timescale measured in years, they are all fleeting, transient things. The web abides.
Here’s a really excellent, clearly-written case study that unfortunately includes this accurate observation:
In recent years the practice of information architecture has fallen out of fashion, which is a shame as you can’t design something successfully without it. If a user can’t find a feature, it’s game over - the feature may as well not exist as far as they’re concerned.
I also like this insight:
Burger menus are effective… at hiding things.
Shockingly little. So you should try it, too.
I was talking to someone recently about a forgotten battle in the history of the early web. It was a battle between search engines and directories.
These days, when the history of the web is told, a whole bunch of services get lumped into the category of “competitors who lost to Google search”: Altavista, Lycos, Ask Jeeves, Yahoo.
But Yahoo wasn’t a search engine, at least not in the same way that Google was. Yahoo was a directory with a search interface on top. You could find what you were looking for by typing or you could zero in on what you were looking for by drilling down through a directory structure.
Yahoo wasn’t the only directory. DMOZ was an open-source competitor. You can still experience it at DMOZlive.com:
The official DMOZ.com site was closed by AOL on February 17th 2017. DMOZ Live is committed to continuing to make the DMOZ Internet Directory available on the Internet.
Search engines put their money on computation, or to use today’s parlance, algorithms (or if you’re really shameless, AI). Directories put their money on humans. Good ol’ information architecture.
It turned out that computation scaled faster than humans. Search won out over directories.
Now an entire generation has been raised in the aftermath of this battle. Monica Chin wrote about how this generation views the world of information:
Catherine Garland, an astrophysicist, started seeing the problem in 2017. She was teaching an engineering course, and her students were using simulation software to model turbines for jet engines. She’d laid out the assignment clearly, but student after student was calling her over for help. They were all getting the same error message: The program couldn’t find their files.
Garland thought it would be an easy fix. She asked each student where they’d saved their project. Could they be on the desktop? Perhaps in the shared drive? But over and over, she was met with confusion. “What are you talking about?” multiple students inquired. Not only did they not know where their files were saved — they didn’t understand the question.
Gradually, Garland came to the same realization that many of her fellow educators have reached in the past four years: the concept of file folders and directories, essential to previous generations’ understanding of computers, is gibberish to many modern students.
We are finding a persistent issue with getting (undergrad, new to research) students to understand that a file/directory structure exists, and how it works. After a debrief meeting today we realized it’s at least partly generational.
We live in a world ordered only by search:
While some are quite adept at using labels, tags, and folders to manage their emails, others will claim that there’s no need to do because you can easily search for whatever you happen to need. Save it all and search for what you want to find. This is, roughly speaking, the hot mess approach to information management. And it appears to arise both because search makes it a good-enough approach to take and because the scale of information we’re trying to manage makes it feel impossible to do otherwise. Who’s got the time or patience?
There are still hold-outs. You can prise files from Scott Jenson’s cold dead hands.
More recently, Linus Lee points out what we’ve lost by giving up on directory structures:
Humans are much better at choosing between a few options than conjuring an answer from scratch. We’re also much better at incrementally approaching the right answer by pointing towards the right direction than nailing the right search term from the beginning. When it’s possible to take a “type in a query” kind of interface and make it more incrementally explorable, I think it’s almost always going to produce a more intuitive and powerful interface.
Directory structures still make sense to me (because I’m old) but I don’t have a problem with search. I do have a problem with systems that try to force me to search when I want to drill down into folders.
I have no idea what Google Drive and Dropbox are doing but I don’t like it. They make me feel like the opposite of a power user. Trying to find a file using their interfaces makes me feel like I’m trying to get a printer to work. Randomly press things until something happens.
Anyway. Enough fist-shaking from me. I’m going to ponder Linus’s closing words. Maybe defaulting to a search interface is a cop-out:
Text search boxes are easy to design and easy to add to apps. But I think their ease on developers may be leading us to ignore potential interface ideas that could let us discover better ideas, faster.
Everything old is new again:
In our current “information age,” or so the story goes, we suffer in new and unique ways.
But the idea that modern life, and particularly modern technology, harms as well as helps, is deeply embedded in Western culture: In fact, the Victorians diagnosed very similar problems in their own society.
Addy takes a deep dive into making sure your images are performant. There’s a lot to cover here—that’s why I ended up splitting it in two for the responsive design course: one module on responsive images and one on the picture element.
If you rely on Word, Evernote or Notion, for example, then you can’t work unless you have Word, Evernote, or Notion. You are helpless without them. You are dependent.
But if you only use plain text, you can use any program on any device, forever. It gives great flexibility and peace of mind.
A fascinating four-part series by Lisa Charlotte Muth on colour in data visualisations:
Caleb Scharf:
Wait a minute. There is no real difference between the dataome—our externalized world of books and computers and machines and robots and cloud servers—and us. That means the dataome is a genuine alternative living system here on the planet. It’s dependent on us, but we’re dependent on it too. And for me that was nerve-wracking. You get to the point of looking at it and going, Wow, the alien world is here, and it’s right under our nose, and we’re interacting with it constantly.
I like this Long Now view of our dataome:
We are constantly exchanging information that enables us to build a library for survival on this planet. It’s proven an incredibly successful approach to survival. If I can remember what happened 1,000 years ago, that may inform me for success today.
I’m terrible at taking my own advice.
Hana wrote a terrific article called You’re on mute: the art of presenting in a Zoom era. In it, she has very kind things to say about my process for preparing conference talks.
As it happens, I’m preparing a conference talk right now for delivery online. Am I taking my advice about how to put a talk together? I am on me arse.
Perhaps the most important part of the process I shared with Hana is that you don’t get too polished too soon. Instead you get everything out of your head as quickly as possible (probably onto disposable bits of paper) and only start refining once you’re happy with the rough structure you’ve figured out by shuffling those bits around.
But the way I’ve been preparing this talk has been more like watching a progress bar. I started at the start and even went straight into slides as the medium for putting the talk together.
It was all going relatively well until I hit a wall somewhere between the 50% and 75% mark. I was blocked and I didn’t have any rough sketches to fall back on. Everything was a jumbled mess in my brain.
It all came to a head at the start of last week when that jumbled mess in my brain resulted in a very restless night spent tossing and turning while I imagined how I might complete the talk.
This is a terrible way of working and I don’t recommend it to anyone.
The problem was I couldn’t even return to the proverbial drawing board because I hadn’t given myself a drawing board to return to (other than this crazy wall of connections on Kinopio).
My sleepless night was a wake-up call (huh?). The next day I forced myself to knuckle down and pump out anything even if it was shit—I could refine it later. Well, it turns out that just pumping out any old shit was exactly what I needed to do. The act of moving those fingers up and down on the keyboard resulted in something that wasn’t completely terrible. In fact, it turned out pretty darn good.
The idea here is to get everything out of my head.
I should’ve listened to that guy.
At this point, I think I’ve got the talk done. The progress bar has reached 100%. I even think that it’s pretty good. A giveaway for whether a talk is any good is when I find myself thinking “Yes, this has good points well made!” and then five minutes later I’m thinking “Wait, is this complete rubbish that’s totally obvious and doesn’t make much sense?” (see, for example, every talk I’ve ever prepared ever).
Now I just to have to record it. The way that An Event Apart are running their online editions is that the talks are pre-recorded but followed with live Q&A. That’s how the Clearleft events team have been running the conference part of the Leading Design Festival too. Last week there were three days of this format and it worked out really, really well. This week there’ll be masterclasses which are delivered in a more synchronous way.
It feels a bit different to prepare a talk for pre-recording rather than live delivery on stage. In fact, it feels less like preparing a conference talk and more like making a documentary. I guess this is what life is like for YouTubers.
I think the last time I was in a cinema before The Situation was at the wonderful Duke of York’s cinema here in Brighton for an afternoon showing of The Proposition followed by a nice informal chat with the screenwriter, one Nick Cave, local to this parish. It was really enjoyable, and that’s kind of what Leading Design Festival felt like last week.
I wonder if maybe we’ve been thinking about online events with the wrong metaphor. Perhaps they’re not like conferences that have moved online. Maybe they’re more like film festivals where everyone has the shared experience of watching a new film for the first time together, followed by questions to the makers about what they’ve just seen.
SETI—the Search for Extra Terrestrial Information processing:
What we get is a computational device surrounding the Asymptotic Giant Branch star that is roughly the size of our Solar System.
Shannon is not exactly a household name. He never won a Nobel Prize, and he wasn’t a celebrity like Albert Einstein or Richard Feynman, either before or after his death in 2001. But more than 70 years ago, in a single groundbreaking paper, he laid the foundation for the entire communication infrastructure underlying the modern information age.
It started using the magic spell of prominent results page display to get authors to use it. Nothing is left of the original lure of raising awareness for web performance, and nothing convincing is there to confirm it was, indeed, a usable “web component framework.”