Jeremy Keith's Blog, page 24

Talks and workshops at UX London 2023

Back in November of last year I announced that UX London would be returning in 2023 and that I���d be curating the line-up again. That���s where I���ve been putting a lot of my energy over the last six months.

The line-up is complete. If I step back and try to evaluate it objectively, I���ve gotta say ���hot damn, that���s a fine roster of speakers!

Imran Afzal, Vimla Appadoo, Daniel Burka, Trine Falbe, Vitaly Friedman, Mansi Gupta, Stephen Hay, Asia Hoe, Amy Hupe, Paul Robert Lloyd, Stacey Mendez, Ignacia Orellana, Stefanie Posavec, Hannah Smith, and David Dylan Thomas.

Take a look at the complete schedule���a terrific mix of thought-provoking talks and practical hands-on workshops.

On day one, you���ve got these talks:

Designing your design process,Thinking differently about digital sustainability,Let���s choose empathy,The lies we tell ourselves about design systems, andWhat if people weren���t the product? Building a web that loves humanity.

Then on day two:

The necessity and practice of women-centric design,Time team: Documenting decisions and marking milestones,User experience beyond screens,Can designers save lives? Not by themselves, andGhosts in the machine: AI, design, and ethics.

And that���s just the talks! You���ve also got these four excellent workshops on both days:

Practical, ethical design,Designing for complex UIs,Strategies for creating and evolving design systems, andDataviz sketching session.

That���s a lot of great stuff packed into two days!

In case you haven���t guessed, I am very excited about this year���s UX London. I would love to see you there.

As an appreciation for you putting up with my child-like excitement, I���d like to share a discount code with you. You can get 20%���that���s one fifth!���off the ticket price using the code CLEARLEFT20.

But note that the standard ticket pricing ends on Friday, May 26th so use that code in the next week to get the most bang for your buck. After that, there���ll only be last-chance tickets, which cost more.

Looking forward to seeing you at Tobacco Dock on June 22nd and 23rd!

Nailspotting

I���m sure you���ve heard the law of the instrument: when all you have is a hammer, everything looks like a nail.

There���s another side to it. If you���re selling hammers, you���ll depict a world full of nails.

Recent hammers include cryptobollocks and virtual reality. It wasn���t enough for blockchains and the metaverse to be potentially useful for some situations; they staked their reputations on being utterly transformative, disrupting absolutely every facet of life.

This kind of hype is a terrible strategy in the long-term. But if you can convince enough people in the short term, you can make a killing on the stock market. In truth, the technology itself is superfluous. It���s the hype that matters. And if the hype is over-inflated enough, you can even get your critics to do your work for you, broadcasting their fears about these supposedly world-changing technologies.

You���d think we���d learn. If an industry cries wolf enough times, surely we���d become less trusting of extraordinary claims. But the tech industry continues to cry wolf���or rather, ���hammer!������at regular intervals.

The latest hammer is machine learning, usually���incorrectly���referred to as Artificial Intelligence. What makes this hype cycle particularly infuriating is that there are genuine use cases. There are some nails for this hammer. They���re just not as plentiful as the breathless hype���both positive and negative���would have you believe.

When I was hosting the DiBi conference last week, there was a little section on generative ���AI��� tools. Matt Garbutt covered the visual side, demoing tools like Midjourney. Scott Salisbury covered the text side, showing how you can generate code. Afterwards we had a panel discussion.

During the panel I asked some fairly straightforward questions that nobody could answer. Who owns the input (the data used by these generative tools)? Who owns the output?

On the whole, it stayed quite grounded and mercifully free of hyperbole. Both speakers were treating the current crop of technologies as tools. Everyone agreed we were on the hype cycle, probably the peak of inflated expectations, looking forward to reaching the plateau of productivity.

Scott explicitly warned people off using generative tools for production code. His advice was to stick to side projects for now.

Matt took a closer look at where these tools could fit into your day-to-day design work. Mostly it was pretty sensible, except when he suggested that there could be any merit to using these tools as a replacement for user testing. That���s a terrible idea. A classic hammer/nail mismatch.

I think I moderated the panel reasonably well, but I have one regret. I wish I had first read Baldur Bjarnason���s new book, The Intelligence Illusion. I started reading it on the train journey back from Edinburgh but it would have been perfect for the panel.

The Intelligence Illusion is very level-headed. It is neither pro- nor anti-AI. Instead it takes a pragmatic look at both the benefits and the risks of using these tools in your business.

It has excellent advice for spotting genuine nails. For example:

Generative AI has impressive capabilities for converting and modifying seemingly unstructured data, such as prose, images, and audio. Using these tools for this purpose has less copyright risk, fewer legal risks, and is less error prone than using it to generate original output.

Think about transcripts of videos or podcasts���an excellent use of this technology. As Baldur puts it:

The safest and, probably, the most productive way to use generative AI is to not use it as generative AI. Instead, use it to explain, convert, or modify.

He also says:

Prefer internal tools over externally-facing chatbots.

That chimes with what I���ve been seeing. The most interesting uses of this technology that I���ve seen involve a constrained dataset. Like the way Luke trained a language model on his own content to create a useful chat interface.

Anyway, The Intelligence Illusion is full of practical down-to-earth advice based on plenty of research backed up with copious citations. I���m only halfway through it and it���s already helped me separate the hype from the reality.

Hosting DIBI

I was up in Edinburgh for the past few days at the Design It; Build It conference.

I was supposed to come back on Saturday but then the train strikes were announced so I changed my travel plans to avoid crossing a picket line, which gave me an extra day to explore Auld Reekie.

I spoke at DIBI last year so this time I was there in a different capacity. I was the host. That meant introducing the speakers and asking them questions after their talks.

I���m used to hosting events now, what with UX London and Leading Design. But I still get nervous beforehand. At least with a talk you can rehearse and practice. With hosting, it���s all about being nimble and thinking on your feet.

I had to pay extra close attention to each talk, scribbling down potential questions to ask. It���s similar to the feeling I get when I���m liveblogging talks.

There were some line-up changes and schedule adjustments along the way, but everything went super smoothly. I pride myself on running a tight ship so the timings were spot-on.

When it came to the questions, I tried to probe under the skin of each presentation. For some talks, that involved talking shop���the finer points of user research or the design process, say. But for the big-picture talks, I made sure to get each speaker to defend their position. So after Dan Makoski���s kumbaya-under-capitalism talk, I gave him a good grilling. Same with Philip Lockwood-Holmes who gave me permission beforehand to be merciless with him.

It was all quite entertaining. Alas, I think I may have put the fear of God into the other speakers who saw me channeling my inner Jeremy Paxman. But they needn���t have worried. I also lobbed some softballs. Like when I asked Levon Sharrow from Patagonia if there was such thing as ethical consumption under capitalism.

I had fun, but I was also aware of that fine line between being clever and being an asshole. Even though part of my role was to play devil���s advocate, I tried to make sure I was never punching down.

All in all, an excellent couple of days spent in good company.

Hosting was hard work, but very rewarding. I���ve come to realise it���s one of those activities that comes relatively easy to me, but it is very hard (and stressful) for others. And I���m pretty gosh-darned good at it too, false modesty bedamned.

So if you���re running an event but the thought of hosting it fills you with dread, we should talk.

Tragedy

There are two kinds of time-travel stories.

There are time-travel stories that explore the many-worlds hypothesis. Going back in time and making a change forks the universe. But the universe is constantly forking anyway. So effectively the time travel is a kind of universe-hopping (there���s a big crossover here with the alternative history subgenre).

The problem with multiverse stories is that there���s always a reset available. No matter how bad things get, there���s a parallel universe where everything is hunky dory.

The other kind of time travel story explores the idea of a block universe. There is one single timeline.

This is what you���ll find in Tenet, for example, or for a beautiful reduced test case, the Ted Chiang short story What���s Expected Of Us. That gets straight to the heart of the biggest implication of a block universe���the lack of free will.

There���s no changing what has happened or what will happen. In fact, the very act of trying to change the past often turns out to be the cause of what you���re trying to prevent in the present (like in Twelve Monkeys).

I���ve often referred to these single-timeline stories as being like Greek tragedies. But only recently���as I���ve been reading quite a bit of Greek mythology���have I realised that the reverse is also true:

Greek tragedies are time-travel stories.

Hear me out���

Time-travel stories aren���t actually about physically travelling in time. That���s just a convenience for the important part���information travelling in time. That���s at the heart of most time-travel stories; informaton from the future travelling back to the past.

William Gibson���s The Peripheral���very much a many-worlds story with its alternate universe ���stubs������takes this to its extreme. Nothing phyiscal ever travels in time. But in an age of telecommuting, nothing has to. Our time travellers are remote workers.

That book also highlights the power dynamics inherent in information wealth. Knowledge of the future gives you an advantage that you can exploit in the past. This is what Mark Twain���s Connecticut yankee does in King Arthur���s court.

This power dynamic is brilliantly inverted in Octavia Butler���s brilliant Kindred. No amount of information can help you if your place in society is determined by the colour of your skin.

Anyway, the point is that information flow is what matters in time-travel stories. Therefore any story where information travels backwards in time is a time-travel story.

That includes any story with a prophecy. A prophecy is information about the future, like:

Oedipus will kill his father and marry his mother.

You can try to change your fate, but you���ll just end up triggering it instead.

Greek tragedies are time-travel stories.

Innovation

I did an episode of the Clearleft podcast on innovation a while back:

Everyone wants to be innovative ���but no one wants to take risks.

The word innovation is often bandied about in an unquestioned positive way. But if we acknowledge that innovation is���by definition���risky, then the exhortations sound less positive.

���We provide innovative solutions for businesses!��� becomes ���We provide risky solutions for businesses!���

I was reminded of this when I saw the website for the Podcast Standards Project. The original text on the website described the project as:

���a grassroots coalition working to establish modern, open standards, to enable innovation in the podcast industry.

I pushed back on that wording (partly because I���ve seen the word ���innovation��� used as a smoke screen for user-hostile practices like tracking and surveillance). The wording has since changed to:

���a grassroots coalition dedicated to creating standards and practices that improve the open podcasting ecosystem for both listeners and creators.

That���s better. It���s more precise.

Am I nitpicking? Only if you think that ���innovation��� and ���improvement��� are synonyms. I don���t think they are.

Innovation implies change. Improvement implies positive change.

Not all change is positive. Not all innovation is positive.

Innovation goes hand in hand with disruption. Again, disruption involves change. But not necessarily positive change.

Think about the antonyms of change and disruption: stasis and stability. Those words don���t sound very exciting, but in some arenas they���re exactly what you should be aiming for; arenas like infrastructure or standards.

Not to get all pace layers-y here, but it seems to me that every endeavour has a sweet spot for innovation. For some projects, too little innovation is bad. For others, too much innovation is worse.

The trick is knowing which kind of project you���re working on.

(As a side note, I think some people use the word innovation to describe the generative, divergent phase of a design project: ���how might we come up with innovative new approaches?��� But we already have a word to describe the practice of generating novel and interesting ideas. That word isn���t innovation. It���s creativity.)

The intersectionality of web performance

Web performance is an unalloyed good. No one has ever complained that a website is too fast.

So the benefit is pretty obvious. Users like fast websites. But there are other benefits to web performance. And they don���t all get equal airtime.

Business

A lot of good web performance practices come down to the first half of Postel���s Law: be conservative in what send. Images, fonts, JavaScript ���remove what you don���t need and optimise the hell out of what���s left.

That can translate to savings. If you���re paying for the bandwidth every time a hefty file is downloaded, your monthly bill could get pretty big.

So apart from the indirect business benefits of happy users converting to happy customers, there can be a real nuts���n���bolts bottom-line saving to be made by having a snappy website.

Sustainability

This is related to the cost-savings benefit. If you���re shipping less stuff down the wire, and you���re optimising what you do send, then there���s less energy required.

Whether less energy directly translates to a smaller carbon footprint depends on how the energy is being generated. If your servers are running on 100% renewable energy sources, then reducing the output of your responses won���t reduce your carbon footprint.

But there���s an energy cost at the other end too. Think of all the devices making requests to your server. If you���re making those devices work hard���by downloading, parsing, executing lots of JavaScript, for example���then you���re draining battery life. And you can���t guarantee that the battery will be replenished from renewable energy sources.

That���s why sites like the website carbon calculator have so much crossover with web performance:

From data centres to transmission networks to the billions of connected devices that we hold in our hands, it is all consuming electricity, and in turn producing carbon emissions equal to or greater than the global aviation industry. Yikes!

Inclusivity

There comes a point when a slow website isn���t just inconvenient, it���s inaccessible.

I���ve always liked the German phrase for accessible: barrierefrei���free of barriers. With every file you add to a website���s dependencies, you���re adding one more barrier. Eventually the barrier is insurmountable for people with older devices or slower internet connections. If they can no longer access your website, your website is quite literally inaccessible.

Making the case

I���ve noticed that when it comes to making the argument in favour of better web performance, people often default to the business benefits.

I get it. We���re always being told to speak the language of business. The psychology seems pretty straightforward; if you think that the people you���re trying to convince are mostly concerned with the bottom line, use the language of commerce to change their minds.

But that���s always felt reductive to me.

Sure, those people almost certainly do care about the business. Who doesn���t? But they���re also humans. I feel like if really want to convince them, speak to their hearts. Show them the bigger picture.

Eliel Saarinen said:

Always design a thing by considering it in its next larger context; a chair in a room, a room in a house, a house in an environment, an environment in a city��plan.

I think the same could apply to making the case for web performance. Don���t stop at the obvious benefits. Go wider. Show the big-picture implications.

Spring

Spring is arriving. It���s just taking its time.

There are little signs. Buds on the trees. The first asparagus of the year. Daffodils. Changing the clocks. A stretch in the evenings. But the weather remains, for the most part, chilly and grim.

Reality is refusing to behave like a fast-forward montage leading up to to a single day when you throw open the curtains and springtime is suddenly there in all its glory.

That���s okay. I can wait. I���ve had a lot of practice over the past three years. We all have. Staying home, biding time, saving lives.

But hunkering down during The Situation isn���t like taking shelter during an air raid. There isn���t a signal that sounds to indicate ���all clear!��� It���s more like going from Winter to Spring. It���s slow, almost impercetible. But it is happening.

I���ve noticed a subtle change in my risk assessment over the past few months. I still think about COVID-19. I still factor it into my calculations. But it���s no longer the first thing I think of.

That���s a subtle change. It doesn���t seem like that long ago when COVID was at the forefront of my mind, especially if I was weighing up an excursion. Is it worth going to that restaurant? How badly do I want to go to that gig? Should I go to that conference?

Now I find myself thinking of COVID as less of a factor in my decision-making. It���s still there, but it has slowly slipped down the ranking.

I know that other people feel differently. For some people, COVID slipped out of their minds long ago. For others, it���s still very much front and centre. There isn���t a consensus on how to evaluate the risks. Like I said:

It���s like when you���re driving and you think that everyone going faster than you is a maniac, and everyone going slower than you is an idiot.

COVID-19 isn���t going away. But perhaps The Situation is.

The Situation has been gradually fading away. There isn���t a single moment where, from one day to the next, we can say ���this marks the point where The Situation ended.��� Even if there were, it would be a different moment for everyone.

As of today, the COVID-19 app officially stops working. Perhaps today is as good a day as any to say Spring has arrived. The season of rebirth.

Assumption

While I���m talking about the SVGs on The Session, I thought I���d share something else related to the rendering of the sheet music.

Like I said, I use the brilliant abcjs JavaScript library. It converts ABC notation into sheet music on the fly, which still blows my mind.

If you view source on the rendered SVG, you���ll see that the path and rect elements have been hard-coded with a colour value of #000000. That makes sense. You���d want to display sheet music on a light background, probably white. So it seems like a safe assumption.

Ah, but when it comes to front-end development, assumptions are like little hidden bombs just waiting to go off!

I got an email the other day:

Hi Jeremy,

I have vision problems, so I need to use high-contrast mode (using Windows 11). In high-contrast mode, the sheet-music view is just black!

Doh! All my CSS adapts just fine to high-contrast mode, but those hardcoded hex values in the SVG aren���t going to be affected by high-contrtast mode.

Stepping back, the underlying problem was that I didn���t have a full separation of concerns. Most of my styling information was in my CSS, but not all. Those hex values in the SVG should really be encoded in my style sheet.

I couldn���t remove the hardcoded hex values���not without messing around with JavaScript beyond my comprehension���so I made the fix in CSS:

[fill="#000000"] { fill: currentColor;}[stroke="#000000"] { stroke: currentColor;}

That seemed to do the trick. I wrote back to the person who had emailed me, and they were pleased as punch:

Well done, Thanks!�� The staff, dots, etc. all appear as white on a black background.�� When I click “Print”, it looks like it still comes out black on a white background, as expected.

I���m very grateful that they brought the issue to my attention. If they hadn���t, that assumption would still be lying in wait, preparing to ambush someone else.

Workaround

Two weeks ago, I wrote:

I woke up today to a very annoying new bug in Firefox. The browser shits the bed in an unpredictable fashion when rounding up single pixel line widths in SVG. That���s quite a problem on The Session where all the sheet music is rendered in SVG. Those thin lines in sheet music are kind of important.

Paul Rosen, who makes abcjs, the JavaScript library that renders sheet music on The Session, managed to get a fix out pretty quickly. But I use an older version of the library and updating it would introduce some side-effects that would take me a while to work around. So that option wasn���t available to me.

In this situation, when the problem is caused by a browser bug, the correct course of action is to file a bug with the browser. That had already been done. Now all I could do was twiddle my thumbs and wait for the next release of the browser, which would hopefully ship with the fix.

But I figured I may as well try to find a temporary workaround in the meantime.

At first, I looked at diving into the internals of the JavaScript���that���s where the instructions are given for drawing the SVGs.

But then I stopped and thought, ���If the problem is with the rendering of the SVG, maybe CSS can help.���

I started messing around with SVG-specific CSS properties like stroke, fill, and so on. With dev tools open, I started targeting the paths that acted as bar lines in the sheet music, playing around with widths, opacities, and fills.

It was the debugging equivalent of throwing spaghetti at the wall. Remarkably, it actually worked.

I found a solution with this nonsensical bit of CSS:

stroke: currentColor;stroke-opacity: 0;

For some reason, rather than making all the barlines disappear, this ensured they were visible.

It���s the worst kind of hacky fix���the kind where you have no idea why it works, but it does.

So I shipped it.

And at pretty much exactly the same time, a new version of Firefox dropped …with the bug fixed.

I can���t deny that there was a certain satisfaction in being able to work around a browser bug. But there���s much more satisfaction in deleting the hacky workaround when it���s no longer needed.

Remote

Before The Situation, I used to work in the Clearleft studio quite a bit. Maybe I���d do a bit of work at home for an hour or two before heading in, but I���d spend most of my working day with my colleagues.

That all changed three years ago:

Clearleft is a remote-working company right now. I mean, that���s hardly surprising���just about everyone I know is working from home.

Clearleft has remained remote-first. We���ve still got our studio space, though we���ve cut back to just having one floor. But most of the time people are working from home. I still occasionally pop into the studio���I���m actually writing this in the studio right now���but mostly I work out of my own house.

It���s funny how the old ways of thinking have been flipped. If I want to get work done, I stay home. If I want to socialise, I go into the studio.

For a lot of the work I do���writing, podcasting, some video calls, maybe some coding���my home environment works better than the studio. In the Before Times I���d have to put on headphones to block out the distractions of a humming workplace. Of course I miss the serendipitous chats with my co-workers but that���s why it���s nice to still have the option of popping into the studio.

Jessica has always worked from home. Our flat isn���t very big but we���ve got our own separate spaces so we don���t disturb one another too much.

For a while now we���ve been thinking that we could just as easily work from another country. I was inspired by a (video) chat I had with Luke when he casually mentioned that he was in Cypress. Why not? As long as the internet connection is good, the location doesn���t make any difference to the work.

So Jessica and I spent the last week working in Ortygia, Sicily.

It was pretty much the perfect choice. It���s not a huge bustling city. In fact it was really quiet. But there was still plenty to explore���winding alleyways, beautiful old buildings, and of course plenty of amazing food.

The time difference was just one hour. We used the extra hour in the morning to go to the market to get some of the magnificent local fruits and vegetables to make some excellent lunches.

We made sure that we found an AirBnB place with a good internet connection and separate workspaces. All in all, it worked out great. And because we were there for a week, we didn���t feel the pressure to run around to try to see everything.

We spent the days working and the evenings having a nice sundowner appertivo followed by some pasta or seafood.

It was simultaneously productive and relaxing.