Journal tags: us

246

sparkline

Control

In two of my recent talks—In And Out Of Style and Design Principles For The Web—I finish by looking at three different components:

  1. a button,
  2. a dropdown, and
  3. a datepicker.

In each case you could use native HTML elements:

  1. button,
  2. select, and
  3. input type="date".

Or you could use divs with a whole bunch of JavaScript and ARIA.

In the case of a datepicker, I totally understand why you’d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.

In the case of a dropdown, it’s less clear-cut. Personally, I’d use a select element. While it’s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That’s good enough for me.

Still, I can understand why that wouldn’t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you’re going to have to break out the JavaScript and ARIA.

Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling select elements. That’s one of the reasons why the work being done by the Open UI group is so important.

But there’s one more component: a button.

Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.

Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.

I’ve been trying to understand the mindset of a developer who wouldn’t use a native button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.

I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.

When I hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).

But I now understand that someone else might hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.

I get it. I don’t agree. But I get it.

If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren’t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.

But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It’s not what I would do, but I think I understand the motivation a bit better now.

Scale

A few years back, Jessica got a ceiling fan for our living room. This might seem like a strange decision, considering we live in England. Most of the time, the problem in this country is that it’s too cold.

But then you get situations like this week, when the country experienced the hottest temperatures ever recorded. I was very, very grateful for that ceiling fan. It may not get used for most of the year, but on the occasions when it’s needed, it’s a godsend. And it’s going to get used more and more often, given the inexorable momentum of the climate emergency.

Even with the ceiling fan, it was still very hot in the living room. I keep my musical instruments in that room, and they all responded to the changing temperature. The strings on my mandolin, bouzouki, and guitar went looser in the heat. The tuning dropped by at least a semitone.

I tuned them back up, but then I had to be careful when the extreme heat ended and the temperature began to drop. The strings began to tighten accordingly. My instruments went up a semitone.

I was thinking about this connection between sound and temperature when I was tuning the instruments back down again.

The electronic tuner I use shows the current tone in relation to the desired note: G, D, A, E. If the string is currently producing a tone that’s lower than, say, A, the tuner displays the difference on its little screen as lines behind the ideal A position. If the string is producing a tone higher than A, the lines appear in front of the desired note.

What if we thought about temperature like this? Instead of weather apps showing the absolute temperature in degrees, what if they showed the relative distance from a predefined ideal? Then you could see at a glance whether it’s a little cooler than you’d like, or a little hotter than you’d like.

Perhaps an interface like that would let you see at a glance how out of the tune the current temperature is.

Negative

I no longer have Covid. I am released from isolation.

Alas, my negative diagnosis came too late for me to make it to UX London. But that’s okay—by the third and final day of the event, everything was running smooth like buttah! Had I shown up, I would’ve just got in the way. The Clearleft crew ran the event like a well-oiled machine.

I am in the coronaclear just in time to go away for a week. My original thinking was this would be my post-UX-London break to rest up for a while, but it turns out I’ve been getting plenty of rest during UX London.

I’m heading to the west coast of Ireland for The Willie Clancy Summer School, a trad music pilgrimage.

Jessica and I last went to Willie Week in 2019. We had a great time and I distinctly remember thinking “I’m definitely coming back next year!”

Well, a global pandemic put paid to that. The event ran online for the past two years. But now that it’s back for real, I wouldn’t miss it for the world.

My mandolin and I are bound for Miltown Malbay!

UX FOMO

Today is the first day of UX London 2022 …and I’m not there. Stoopid Covid.

I’m still testing positive although I’m almost certainly near the end of my infection. But I don’t want to take any chances. Much as I hate to miss out on UX London, I would hate passing this on even more. So my isolation continues.

Chris jumped in at the last minute to do the hosting duties—thanks, Chris!

From the buzz I’m seeing on Twitter, it sounds like everything is going just great without me, which is great to see. Still, I’m experiencing plenty of FOMO—even more than the usual levels of FOMO I’d have when there’s a great conference happening that I’m not at.

To be honest, nearly all of my work on UX London was completed before the event. My number one task was putting the line-up together, and I have to say, I think I nailed it.

If I were there to host the event, it would mostly be for selfish reasons. I’d get a real kick out of introducing each one of the superb speakers. I’d probably get very tedious, repeatedly saying “Oh, you’re going to love this next one!” followed by “Wasn’t that great‽”

But UX London isn’t about me. It’s about the inspiring talks and practical workshops.

I wish I were there to experience it in person but I can still bask in the glow of a job well done, hearing how much people are enjoying the event.

Positive

That event in Berlin last week was by far the largest gathering of humans I’ve been with in over two years. If I was going to finally succumb to the ’rona, this was likely to be the place and time.

Sure enough, on my last day in Berlin I had a bit of a scratchy throat. I remained masked for the rest of the day for the travel back to England. Once I was back home I immediately tested and …nothing.

I guess it was just a regular sore throat after all.

Over the weekend the sore throat was accompanied by some sniffles. Just your typical cold symptoms. But I decided to be prudent and test again yesterday.

This time a very clear result was revealed. It was Covid-19 after all.

Today I was supposed to be travelling to Lille on the Eurostar to speak at a private event. Instead I’m isolating at home. My symptoms are quite mild. I feel worse about letting down the event organisers.

Still, better to finally get the novel coronavirus now rather than later in the month. I would hate to miss UX London. But I’m confident I’ll be recovered and testing negative by then.

For now I’ll be taking it easy and letting those magnificent vaccines do their work.

dConstruct 2022 is happening!

dConstruct is back!

No, really, for real this time.

We had plans to do a one-off dConstruct anniversary event in 2020. It would’ve been five years since the event ran its ten year course from 2005 to 2015.

We all know what happened next. Not only was there no dConstruct in 2020, there were no live events at all. So we postponed the event. 2021 was slightly better than 2020 for live events, but still not safe enough for us.

Now, finally, the fifteenth anniversary edition of dConstruct is happening, um, on the seventeeth anniversary of dConstruct.

It’s all very confusing, I know. But this is the important bit:

dConstruct 2022 is happening on Friday, September 9th in the Duke of York’s picture house in Brighton.

Tickets are available now.

Or, at least some tickets are available now. Quite a lot of eager folks bought tickets when the 2020 event was announced and those tickets are still good for this 2022 event …which is the 2020 event, but postponed by two years.

I’m currently putting the line-up together. I’m not revealing anything just yet, but trust me, you will want to be there.

If you haven’t been to a dConstruct event before, it’s kind of hard to describe. It’s not a practical hands-on conference where you learn design or development skills. It’s brain food. It’s about technology, culutre, design, society, the future …well, like I said, it’s kind of hard to describe. Have a poke around the dConstruct archive and listen to the audio from previous talks to get some idea of what might be in store.

dConstruct 2022 is a one-off event. I wouldn’t want you to regret missing out, so grab your ticket now.

Situational awereness

There was a week recently where I was out and about nearly every night.

One night, Jessica and I went to the cinema. There was a double bill of Alien and Aliens in the beautiful Duke of York’s picture house. We booked one of the comfy sofas on the balcony.

The next night we were out at the session in The Jolly Brewer, playing trad Irish tunes all evening. Bliss!

Then on the third night, we went to see Low playing in a church. Rich and Ben were there too.

It really felt like The Before Times. Of course in reality it wasn’t quite like old times. There’s always an awareness of relative risk. How crowded is the cinema likely to be? Will they have the doors open at The Jolly Brewer to improve the airflow? Will people at the Low gig comply with the band’s request to wear masks?

Still, in each case, I weighed the risk and decided the evening was worth it. If I caught Covid because of that cinematic double bill, or that tune-filled gathering, or that excellent gig, that price would be acceptable.

Mind you, I say that without having experienced the horribleness of having a nasty bout of coronavirus. And the prospect of long Covid is genuinely scary.

But there’s no doubt that the vaccines have changed the equation. There’s still plenty of risk but it’s on a different scale. The Situation isn’t over, but it has ratcheted down a notch to something more manageable.

Now with the weather starting to get nice, there’ll be more opportunities for safer outdoor gatherings. I’m here for it.

Actually, I’m not going to literally be here for all of it. I’m making travel plans to go and speak at European events—another positive signal of the changing situation. Soon I’ll be boarding the Eurostar to head to Amsterdam, and not long after I’ll be on the Eurostar again for a trip to Lille. And then of course there’s UX London at the end of June. With each gathering, there’s an inevitable sense of calculated risk, but there’s also a welcome sense of normality seeping back in.

Suspicion

I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:

I would love it if someone could explain why they avoid native browser features but use third-party code.

Chris obliged:

I can’t speak for the industry, but I have a guess. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. jQuery was created to smooth over cross-browser JavaScript problems. That’s trust.

Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!

Charles Harries takes on my question in his post Libraries over browser features:

I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.

Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.

So again, it’s browser incompatibilities that made libraries attractive.

Jim Nielsen responds with the same message in his post Trusting Browsers:

We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.

For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.

Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.

I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.

Charles again:

This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.

I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.

Jim is glass-half-full kind of guy:

I’m optimistic that trust in browser-native features and APIs is being restored.

He also points to a very sensible mindset when it comes to third-party libraries and frameworks:

In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).

Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).

I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.

I like Jim’s proposed design princple:

Where available, default to browser-native features over third party code, abstractions, or idioms.

(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)

Trust

I’ve noticed a strange mindset amongst front-end/full-stack developers. At least it seems strange to me. But maybe I’m the one with the strange mindset and everyone else knows something I don’t.

It’s to do with trust and suspicion.

I’ve made no secret of the fact that I’m suspicious of third-party code and dependencies in general. Every dependency you add to a project is one more potential single point of failure. You have to trust that the strangers who wrote that code knew what they were doing. I’m still somewhat flabbergasted that developers regularly add dependencies—via npm or yarn or whatever—that then pull in even more dependencies, all while assuming good faith and competence on the part of every person involved.

It’s a touching expression of faith in your fellow humans, but I’m not keen on the idea of faith-based development.

I’m much more trusting of native browser features—HTML elements, CSS features, and JavaScript APIs. They’re not always perfect, but a lot of thought goes into their development. By the time they land in browsers, a whole lot of smart people have kicked the tyres and considered many different angles. As a bonus, I don’t need to install them. Even better, end users don’t need to install them.

And yet, the mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.

When I write and talk about using service workers, I often come across scepticism from developers about writing the service worker code. “Is there a library I can use?” they ask. “Well, yes” I reply, “but then you’ve got to understand the library, and the time it takes you to do that could be spent understanding the native code.” So even though a library might not offer any new functionality—just a different idion—many developers are more likely to trust the third-party library than they are to trust the underlying code that the third-party library is abstracting!

Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.

On the one hand, I get it. Bootstrap and React are very popular. That popularity speaks volumes. If lots of people use a technology, it must be a safe bet, right?

But if we’re talking about popularity, every single browser today ships with support for features like grid, custom properties, service workers and web components. No third-party framework can even come close to that install base.

And the fact that these technologies have shipped in stable browsers means they’re vetted. They’ve been through a rigourous testing phase. They’ve effectively got a seal of approval from each individual browser maker. To me, that seems like a much bigger signal of trustworthiness than the popularity of a third-party library or framework.

So I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.

Is it because of the job market? When recruiters are looking for developers, their laundry list is usually third-party technologies: React, Vue, Bootstrap, etc. It’s rare to find a job ad that lists native browser technologies: flexbox, grid, service workers, web components.

I would love it if someone could explain why they avoid native browser features but use third-party code.

Until then, I shall remain perplexed.

Upcoming events

I see that Russell is planning to bring back Interesting this year. This makes me happy. Just seeing the return of in-person gatherings—run safely—is giving me life.

I don’t think I’m alone in this. I think that lots of people are yearning for some in-person contact after two years of online events. The good news is that there are some excellent in-person web conferences on the horizon.

Beyond Tellerrand is back in Düsseldorf on May 2nd and 3rd. Marc ran some of the best online events during lockdown with his Stay Curious cafés, but there’s nothing beats the atmosphere of Beyond Tellerrand on its home turf.

If you can’t make it Düsseldorf—I probably can’t because I’m getting my passport renewed right now—there’s All Day Hey in Leeds on May 5th. Harry has put a terrific line-up together for this one-day, very affordable event.

June is shaping up to be a good month for events too. First of all, there’s CSS Day in Amsterdam on June 9th and 10th. I really, really like this event. I’m not just saying that because I’m speaking at this year’s CSS Day. I just love the way that the conference treats CSS with respect. If you self-identigy as a CSS person, then this is the opportunity to be with your people.

But again, if you can’t make it Amsterdam, never fear. The Pixel Pioneers conference returns to Bristol on June 10th. Another one-day event in the UK with a great line-up.

Finally, there’s the big one at the end of June. UX London runs from June 28th to June 30th:

Bringing the UX community back together

Yes, I’m biased because I’m curating the line-up but this is shaping up to be unmissable! It’s going to be so good to gather with our peers and get our brains filled by the finest of design minds.

When should there be a declarative version of a JavaScript API?

I feel like it’s high time I revived some interest in my proposal for button type="share". Last I left it, I was gathering use cases and they seem to suggest that the most common use case for the Web Share API is sharing the URL of the current page.

If you want to catch up on the history of this proposal, here’s what I’ve previously written:

Remember, my proposal isn’t to replace the JavaScript API, it’s to complement it with a declarative option. The declarative option doesn’t need to be as fully featured as the JavaScript API, but it should be able to cover the majority use case. I think this should hold true of most APIs.

A good example is the Constraint Validation API. For the most common use cases, the required attribute and input types like “email”, “url”, and “number” have you covered. If you need more power, reach for the JavaScript API.

A bad example is the Geolocation API. The most common use case is getting the user’s current location. But there’s no input type="geolocation" (or button type="geolocation"). Your only choice is to use JavaScript. It feels heavy-handed.

I recently got an email from Taylor Hunt who has come up with a good litmus test for JavaScript APIs that should have a complementary declarative option:

I’ve been thinking about how a lot of recently-proposed APIs end up having to deal with what Chrome devrel’s been calling the “user gesture/activation budget”, and wondering if that’s a good indicator of when something should have been HTML in the first place.

I think he’s onto something here!

Think about any API that requires a user gesture. Often the documentation or demo literally shows you how to generate a button in JavaScript in order to add an event handler to it in order to use the API. Surely that’s an indication that a new button type could be minted?

The Web Share API is a classic example. You can’t invoke the API after an event like the page loading. You have to invoke the API after a user-initiated event like, oh, I don’t know …clicking on a button!

The Fullscreen API has the same restriction. You can’t make the browser go fullscreen unless you’re responding to user gesture, like a click. So why not have button type="fullscreen" in HTML to encapsulate that? And again, the fallback in non-supporting browsers is predictable—it behaves like a regular button—so this is trivial to polyfill. I should probably whip up a polyfill to demonstrate this.

I can’t find a list of all the JavaScript APIs that require a user gesture, but I know there’s more that I’m just not thinking of. I’d love to see if they’d all fit this pattern of being candidates for a new button type value.

The only potential flaw in this thinking is that some APIs that require a user gesture might also require a secure context (either being served over HTTPS or localhost). But as far as I know, HTML has never had the concept of features being restricted by context. An element is either supported or it isn’t.

That said, there is some prior art here. If you use input type="password" in a non-secure context—like a page being served over HTTP—the browser updates the interface to provide scary warnings. Perhaps browsers could do something similar for any new button types that complement secure-context JavaScript APIs.

Web notifications on iOS

I’ve mentioned before that I don’t enable notifications on my phone. Text messages are the only exception. I don’t want to get notified if a new email arrives (I avoid email on my phone completely) and I certainly don’t want some social media app telling me somebody liked or faved something.

But the number one feature I’d like to see in Safari on iOS is web notifications.

It’s not for me personally, see. It’s because it’s the number one reason why people are choosing not to go all in progressive web apps.

Safari on iOS is the last holdout. But that equates to enough marketshare that many companies feel they can’t treat notifications as a progressive enhancement. While I may not agree with that decision myself, I get it.

When I’m evangelising the benefits of building on the open web instead of making separate iOS and Android apps, I inevitably get asked about notifications. As long as mobile Safari doesn’t support them—even though desktop Safari does—I’m somewhat stumped. There’s no polyfill for this feature other than building an entire native app, which is a bit extreme as polyfills go.

And of course, unlike on your Mac, you don’t have the option of using a different browser on your iPhone. As long as mobile Safari doesn’t support web notifications, nothing on iOS can support web notifications.

I’ve got progressive web apps on the home screen of my phone that match their native equivalents feature-for-feature. Twitter. Instagram. They’re really good. In some ways they’re superior to the native apps; the Twitter website is much calmer, and the Instagram website has no advertising. But if I wanted to get notifications from any of those sites, I’d have to keep the native apps installed just for that one feature.

So in the spirit of complaining about web browsers in a productive way, I just want to throw this plea out there: Apple, please support web notifications in mobile Safari!

The good news is that web notifications on iOS might be on their way. Huzzah!

Alas, we’re reliant on Maximiliano’s detective work to even get a glimpse of a future feature like this. Apple has no public roadmap for Safari. There’s this status page on the Webkit blog but it’s incomplete—web notifications don’t appear at all. In any case, WebKit and Safari aren’t the same thing. The only way of knowing if a feature might be implemented in Safari is if it shows up in Safari Technology Preview, at which point it’s already pretty far along.

So while my number one feature request for mobile Safari is web notifications, a close second would be a public roadmap.

It only seems fair. If Apple devrels are asking us developers what features we’d like to see implemented—as they should!—then shouldn’t those same developers also be treated with enough respect to share a roadmap with them? There’s not much point in us asking for features if, unbeknownst to us, that feature is already being worked on.

But, like I said, my number one request remains: web notifications on iOS …please!

Both plagues on your one house

February is a tough month at the best of times. A February during The Situation is particularly grim.

At least in December you get Christmas, whose vibes can even carry you through most of January. But by the time February rolls around, it’s all grim winteriness with no respite in sight.

In the middle of February, Jessica caught the ’rona. On the bright side, this wasn’t the worst timing: if this had happened in December, our Christmas travel plans to visit family would’ve been ruined. On the not-so-bright side, catching a novel coronavirus is no fun.

Still, the vaccines did their job. Jessica felt pretty crap for a couple of days but was on the road to recovery before too long.

Amazingly, I did not catch the ’rona. We slept in separate rooms, but still, we were spending most of our days together in the same small flat. Given the virulence of The Omicron Variant, I’m counting my blessings.

But just in case I got any ideas about having some kind of superhuman immune system, right after Jessica had COVID-19, I proceeded to get gastroenteritis. I’ll spare you the details, but let me just say it was not pretty.

Amazingly, Jessica did not catch it. I guess two years of practicing intense hand-washing pays off when a stomach bug comes a-calling.

So all in all, not a great February, even by February’s already low standards.

The one bright spot that I get to enjoy every February is my birthday, just as the month is finishing up. Last year I spent my birthday—the big five oh—in lockdown. But two years ago, right before the world shut down, I had a lovely birthday weekend in Galway. This year, as The Situation began to unwind and de-escalate, I thought it would be good to reprieve that birthday trip.

We went to Galway. We ate wonderful food at Aniar. We listened to some great trad music. We drink some pints. It was good.

But it was hard to enjoy the trip knowing what was happening elsewhere in Europe. I’d blame February for being a bastard again, but in this case the bastard is clearly Vladimar Putin. Fucker.

Just as it’s hard to switch off for a birthday break, it’s equally challenging to go back to work and continue as usual. It feels very strange to be spending the days working on stuff that clearly, in the grand scheme of things, is utterly trivial.

I take some consolation in the fact that everyone else feels this way too, and everyone is united in solidarity with Ukraine. (There are some people in my social media timelines who also feel the need to point out that other countries have been invaded and bombed too. I know it’s not their intention but there’s a strong “all lives matter” vibe to that kind of whataboutism. Hush.)

Anyway. February’s gone. It’s March. Things still feel very grim indeed. But perhaps, just perhaps, there’s a hint of Spring in the air. Winter will not last forever.

Announcing UX London 2022

For the past two years, all of Clearleft’s events have been online. Like everyone else running conferences, we had to pivot in the face of The Situation.

In hindsight, it’s remarkable how well those online events went. This was new territory for everyone—speakers, attendees, and organisers.

UX Fest was a real highlight. I had the pleasure of hosting the event, giving it my Woganesque best. It was hard work, but it paid off.

Still, it’s not quite the same as gathering together with your peers in one place for a shared collective experience. I’ve really been missing in-person events (and from what I’ve seen in people’s end-of-year blog posts, I’m not alone).

That’s why I’m absolutely thrilled that UX London is back in 2022! Save the dates; June 28th to 30th. We’ve got a new venue too: the supremely cool Tobacco Dock.

This is going to be a summertime festival of design. It’ll be thought-provoking, practical, fun, and above all, safe.

It feels kind of weird to be planning an in-person event now, when we’re just emerging from The Omicron Variant, but putting on UX London 2022 isn’t just an act of optimism. It’s a calculated move. While nothing is certain, late June 2022 should be the perfect time to safely gather the UX community again.

It’s a particularly exciting event for me. Not only will I be hosting it, this time I’m also curating the line-up.

I’ve curated conference line-ups before: dConstruct, Responsive Day Out, and Patterns Day. But those were all one-day events. UX London is three times as big!

It’s a lot of pressure, but I’m already extremely excited about the line-up. If my plan comes together, this is going to be an unmissable collection of mindbombs. I’ve already got some speakers confirmed so keep an eye on the website, Twitter or sign up for the newsletter to get the announcements as when they happen.

The format of UX London has been honed over the years. I think it’s got just the right balance.

Each day has a morning of inspiring talks—a mixture of big-picture keynotes and punchy shorter case studies. The talks are all on a single track; everyone shares that experience. Then, after lunch, there’s an afternoon of half-day workshops. Those happen in parallel, so you choose which workshop you want to attend.

I think this mixture of the inspirational and the practical is the perfect blend. Your boss can send you to UX London knowing that you’re going to learn valuable new skills, but you’ll also leave with your mind expanded by new ideas.

Like I said, I’m excited!

Naturally, I’m nervous too. Putting on an event is a risky endeavour at the best times. Putting an event after a two-year pandemic is even more uncertain. What if no one comes? Maybe people aren’t ready to return to in-person events. But I can equally imagine the opposite situation. Maybe people are craving a community gathering after two years of sitting in front of screens. That’s definitely how I’m feeling.

If you’re feeling the same, then join me in London in June. Tickets are on sale now. You can get three-day early-bird pass, or you can buy a ticket for an individual day. But I hope you’ll join me for the whole event—I can’t wait to see you there!

2.5.6

The Competition and Markets Authority (CMA) recently published an interim report on their mobile ecosystems market study. It’s well worth reading, especially the section on competition in the supply of mobile browsers:

On iOS devices, Apple bans the use of alternative browser engines – this means that Apple has a monopoly over the supply of browser engines on iOS. It also chooses not to implement – or substantially delays – a wide range of features in its browser engine. This restriction has 2 main effects:

  • limiting rival browsers’ ability to differentiate themselves from Safari on factors such as speed and functionality, meaning that Safari faces less competition from other browsers than it otherwise could do; and
  • limiting the functionality of web apps – which could be an alternative to native apps as a means for mobile device users to access online content – and thereby limits the constraint from web apps on native apps. We have not seen compelling evidence that suggests Apple’s ban on alternative browser engines is justified on security grounds.

That last sentence is a wonderful example of British understatement. Far from protecting end users from security exploits, Apple have exposed everyone on iOS to all of the security issues of Apple’s Safari browser (regardless of what brower the user thinks they are using).

The CMA are soliciting responses to their interim report:

To respond to this consultation, please email or post your submission to:

Email: mobileecosystems@cma.gov.uk

Post: 


Mobile Ecosystems Market Study
Competition and Markets Authority

25 Cabot Square

London

E14 4QZ

Please respond by no later than 5pm GMT on 7 February 2022.

I encourage you to send a response before this coming Monday. This is the email I’ve sent.

Hello,

This response is regarding competition in the supply of mobile browsers and contains no confidential information.

I read your interim report with great interest.

As a web developer and the co-founder of a digital design agency, I could cite many reasons why Apple’s moratorium on rival browser engines is bad for business. But the main reason I am writing to you is as a consumer and a user of Apple’s products.

I own two Apple computing devices: a laptop and a phone. On both devices, I can install apps from Apple’s App Store. But on my laptop I also have the option to download and install an application from elsewhere. I can’t do this on my phone. That would be fine if my needs were met by what’s available in the app store. But clause 2.5.6 of Apple’s app store policy restricts what is available to me as a consumer.

On my laptop I can download and install Mozilla’s Firefox or Google’s Chrome browsers. On my phone, I can install something called Firefox and something called Chrome. But under the hood, they are little more than skinned versions of Safari. I’m only aware of this because I’m au fait with the situation. Most of my fellow consumers have no idea that when they install the app called Firefox or the app called Chrome from the app store on their phone, they are being deceived.

It is this deception that bothers me most.

Kind regards,

Jeremy Keith

To be fair to Apple, this deception requires collusion from Mozilla, Google, Microsoft, and other browser makers. Nobody’s putting a gun to their heads and forcing them to ship skinned versions of Safari that bear only cosmetic resemblance to their actual products.

But of course it would be commercially unwise to forego the app store as a distrubution channel, even if the only features they can ship are superficial ones like bookmark syncing.

Still, imagine what would happen if Mozilla, Google, and Microsoft put their monies where their mouths are. Instead of just complaining about the unjust situation, what if they actually took the financial hit and pulled their faux-browsers from the iOS app store?

If this unjustice is as important as representatives from Google, Microsoft, and Mozilla claim it is, then righteous indignation isn’t enough. Principles without sacrifice are easy.

If nothing else, it would throw the real situation into light and clear up the misconception that there is any browser choice on iOS.

I know it’s not going to happen. I also know I’m being a hypocrite by continuing to use Apple products in spite of the blatant misuse of monopoly power on display. But still, I wanted to plant that seed. What if Microsoft, Google, and Mozilla were the ones who walk away from Omelas.

2021

2020 was the year of the virus. 2021 was the year of the vaccine …and the virus, obviously, but still it felt like the year we fought back. With science!

Whenever someone writes and shares one of these year-end retrospectives the result is, by its very nature, personal. These last two years are different though. We all still have our own personal perspectives, but we also all share a collective experience of The Ongoing Situation.

Like, I can point to three pivotal events in 2021 and I bet you could point to the same three for you:

  1. getting my first vaccine shot in March,
  2. getting my second vaccine shot in June, and
  3. getting my booster shot in December.

So while on the one hand we’re entering 2022 in a depressingly similar way to how we entered 2021 with COVID-19 running rampant, on the other hand, the odds have changed. We can calculate risk. We’ve got more information. And most of all, we’ve got these fantastic vaccines.

I summed up last year in terms of all the things I didn’t do. I could do the same for 2021, but there’s only one important thing that didn’t happen—I didn’t catch a novel coronavirus.

It’s not like I didn’t take some risks. While I was mostly a homebody, I did make excursions to Zürich and Lisbon. One long weekend in London was particurly risky.

At the end of the year, right as The Omicron Variant was ramping up, Jessica and I travelled to Ireland to see my mother, and then travelled to the States to see her family. We managed to dodge the Covid bullets both times, for which I am extremely grateful. My greatest fear throughout The Situation hasn’t been so much about catching Covid myself, but passing it on to others. If I were to give it to a family member or someone more vulnerable than me, I don’t think I could forgive myself.

Now that we’ve seen our families (after a two-year break!), I’m feeling more sanguine about this next stage. I’ll be hunkering down for the next while to ride out this wave, but if I still end up getting infected, at least I won’t have any travel plans to cancel.

But this is meant to be a look back at the year that’s just finished, not a battle plan for 2022.

There were some milestones in 2021:

  1. I turned 50,
  2. TheSession.org turned 20, and
  3. Adactio.com also turned 20.

This means that my websites are 2/5ths of my own age. In ten years time, my websites will be 1/2 of my own age.

Most of my work activities were necessarily online, though I did manage the aforementioned trips to Switzerland and Portugal to speak at honest-to-goodness real live in-person events. The major projects were:

  1. Publishing season two of the Clearleft podcast in February,
  2. Speaking at An Event Apart Online in April,
  3. Hosting UX Fest in June,
  4. Publishing season three of the Clearleft podcast in September, and
  5. Writing a course on responsive design in November.

Outside of work, my highlights of 2021 mostly involved getting to play music with other people—something that didn’t happen much in 2020. Band practice with Salter Cane resumed in late 2021, as did some Irish music sessions. Both are now under an Omicron hiatus but this too shall pass.

Another 2021 highlight was a visit by Tantek in the summer. He was willing to undergo quarantine to get to Brighton, which I really appreciate. It was lovely hanging out with him, even if all our social activities were by necessity outdoors.

But, like I said, the main achievement in 2021 was not catching COVID-19, and more importantly, not passing it on to anyone else. Time will tell whether or not that winning streak will be sustainable in 2022. But at least I feel somewhat prepared for it now, thanks to those magnificent vaccines.

2021 was a shitty year for a lot of people. I feel fortunate that for me, it was merely uneventful. If my only complaint is that I didn’t get to travel and speak as much I’d like, well boo-fucking-hoo, I’ll take it. I’ve got my health. My family members have their health. I don’t take that for granted.

Maybe 2022 will turn out to be similar—shitty for a lot of people, and mostly unenventful for me. Or perhaps 2022 will be a year filled with joyful in-person activities, like conferences and musical gatherings. Either way, I’m ready.

Getting back

The three-part almost nine-hour long documentary Get Back is quite fascinating.

First of all, the fact that all this footage exists is remarkable. It’s as if Disney had announced that they’d found the footage for a film shot between Star Wars and The Empire Strikes Back.

Still, does this treasure trove really warrant the daunting length of this new Beatles documentary? As Terence puts it:

There are two problems with this Peter Jackson documentary. The first is that it is far too long - are casual fans really going to sit through 9 hours of a band bickering? The second problem is that it is far too short! Beatles obsessives (like me) could happily drink in a hundred hours of this stuff.

In some ways, watching Get Back is liking watching one of those Andy Warhol art projects where he just pointed a camera at someone for 24 hours. It’s simultaneously boring and yet oddly mesmerising.

What struck myself and Jessica watching Get Back was how much it was like our experience of playing with Salter Cane. I’m not saying Salter Cane are like The Beatles. I’m saying that The Beatles are like Salter Cane and every other band on the planet when it comes to how the sausage gets made. The same kind of highs. The same kind of lows. And above all, the same kind of tedium. Spending hours and hours in a practice room or a recording studio is simultaneously exciting and dull. This documentary captures that perfectly.

I suppose Peter Jackson could’ve made a three-part fly-on-the-wall documentary series about any band and I would’ve found it equally interesting. But this is The Beatles and that means there’s a whole mythology that comes along for the ride. So, yes, it’s like watching paint dry, but on the other hand, it’s paint painted by The Beatles.

What I liked about Get Back is that it demystified the band. The revelation for me was really understanding that this was just four lads from Liverpool making music together. And I know I shouldn’t be surprised by that—the Beatles themselves spent years insisting they were just four lads from Liverpool making music together, but, y’know …it’s The Beatles!

There’s a scene in the Danny Boyle film Yesterday where the main character plays Let It Be for the first time in a world where The Beatles have never existed. It’s one of the few funny parts of the film. It’s funny because to everyone else it’s just some new song but we, the audience, know that it’s not just some new song…

Christ, this is Let It Be! You’re the first people on Earth to hear this song! This is like watching Da Vinci paint the Mona Lisa right in front of your bloody eyes!

But truth is even more amusing than fiction. In the first episode of Get Back, we get to see when Paul starts noodling on the piano playing Let It Be for the first time. It’s a momentous occasion and the reaction from everyone around him is …complete indifference. People are chatting, discussing a set design that will never get built, and generally ignoring the nascent song being played. I laughed out loud.

There’s another moment when George brings in the song he wrote the night before, I Me Mine. He plays it while John and Yoko waltz around. It’s in 3/4 time and it’s minor key. I turned to Jessica and said “That’s the most Salter Cane sounding one.” Then, I swear at that moment, after George has stopped playing that song, he plays a brief little riff on the guitar that sounded exactly like a Salter Cane song we’re working on right now. Myself and Jessica turned to each other and said, “What was that‽”

Funnily enough, when we told this to Chris, the singer in Salter Cane, he mentioned how that was the scene that had stood out to him as well, but not for that riff (he hadn’t noticed the similarity). For him, it was about how George had brought just a scrap of a song. Chris realised it was the kind of scrap that he would come up with, but then discard, thinking there’s not enough there. So maybe there’s a lesson here about sharing those scraps.

Watching Get Back, I was trying to figure out if it was so fascinating to me and Jessica (and Chris) because we’re in a band. Would it resonate with other people?

The answer, it turns out, is yes, very much so. Everyone’s been sharing that clip of Paul coming up with the beginnings of the song Get Back. The general reaction is one of breathless wonder. But as Chris said, “How did you think songs happened?” His reaction was more like “yup, accurate.”

Inevitably, there are people mining the documentary for lessons in creativity, design, and leadership. There are already Medium think-pieces and newsletters analysing the processes on display. I guarantee you that there will be multiple conference talks at UX events over the next few years that will include footage from Get Back.

I understand how you could watch this documentary and take away the lesson that these were musical geniuses forging remarkable works of cultural importance. But that’s not what I took from it. I came away from it thinking they’re just a band who wrote and recorded some songs. Weirdly, that made me appreciate The Beatles even more. And it made me appreciate all the other bands and all the other songs out there.

4 + 3

I work a four-day week now.

It started with the first lockdown. Actually, for a while there, I was working just two days a week while we took a “wait and see” attitude at Clearleft to see how The Situation was going to affect work. We weathered that storm, but rather than going back to a full five-day week I decided to try switching to four days instead.

This meant taking a pay cut. Time is literally money when it comes to work. But I decided it was worth it. That’s a privileged position to be in, I know. I managed to pay off the mortgage on our home last year so that reduced some financial pressure. But I also turned fifty, which made me think that I should really be padding some kind of theoretical nest egg. Still, the opportunity to reduce working hours looked good to me.

The ideal situation would be to have everyone switch to a four-day week without any reduction in pay. Some companies have done that but it wasn’t an option for Clearleft, alas.

I’m not the only one working a four-day week at Clearleft. A few people were doing it even before The Situation. We all take Friday as our non-work day, which makes for a nice long three-day weekend.

What’s really nice is that Friday has been declared a “no meeting” day for everyone at Clearleft. That means that those of us working a four-day week know we’re not missing out on anything and it’s pretty nice for people working a five-day week to have a day free of appointments. We have our end-of-week all-hands wind-down on Thursday afternoons.

I haven’t experienced any reduction in productivity. Quite the opposite. There may be a corollay to Parkinson’s Law: work contracts to fill the time available.

At one time, a six-day work week was the norm. It may well be that a four-day work week becomes the default over time. That could dovetail nicely with increasing automation.

I’ve got to say, I’m really, really liking this. It’s quite nice that when Wednesday rolls around, I can say “it’s almost the weekend!”

A three-day weekend feels normal to me now. I could imagine tilting the balance even more over time. Maybe every few years I could reduce the working by a day or half a day. So instead of going from a full-on five-day working week straight into retirement, it would be more of a gentle ratcheting down over the years.

Four days

I had an extra long weekend recently. It was four days of being a culture vulture. It was also four days of ever-increasing risk assessment.

It began on Thursday morning with the first Salter Cane band practice in eighteen months. That was pretty safe—three of us in a room, reminding ourselves of how the songs go. I honestly thought it could’ve been a disaster and that I wouldn’t remember anything, but thanks to a little bit of last-minute revision the evening before, it actually went really well. And boy, did it feel good to plug in and play those songs again.

Later that day, Jessica went up to London. We spent that evening in the Royal Opera House, watching a ballet, The Dante Project. We wore masks. Not everyone else did.

Checked in at Royal Opera House. Ballet time! — with Jessica

The next day, the indoor gatherings continued. We went to the IMAX to see Dune. The opportunity was too good to pass up. It was wonderful! But again, while we wore masks for the duration, not everyone else did.

Checked in at ODEON BFI IMAX for Dune: The IMAX 2D Experience. D U N E — with Jessica

Still, I reckon the ventilation was reasonably good in both the Royal Opera House and the BFI’s IMAX cinema. But that evening we checked into the Clayton Crown Hotel in Cricklewood, venue for the Return To London Town festival of Irish traditional music.

Checked in at Clayton Crown Hotel. Return To London Town 🎶🎻 — with Jessica Checked in at Clayton Crown Hotel. Matt Molloy and Sean Keane 🎶 — with Jessica Checked in at Clayton Crown Hotel. Afternoon session 🎶☘️

That’s where we spent two days going to concerts, sessions, and workshops, all of them indoors. The music was great, and we had a lovely time, but I couldn’t help but feel a sense of nervousness throughout.

When we got back to Brighton, we both took lateral flow tests—thank goodness that these are freely available! We were both negative. We had dodged a viral bullet.

That was the last trip out of town we’ll be making for a while. But even for Brighton-based activities, this is the routine now: weigh up the risks, decide whether an activity is worth it, and if so, testing afterwards.

For example, the week after our trip to London, the Wednesday evening Irish music session at The Jolly Brewer pub started up again here in Brighton. It was one of the things I missed most during The Situation.

I wrote about this at the very start of the first lockdown:

I’m quite certain that one positive outcome of The Situation will be a new-found appreciation for activities we don’t have to do. I’m looking forward to sitting in a pub with a friend or two, or going to see a band, or a play or a film, and just thinking “this is nice.”

I certainly did find myself thinking “this is nice” during the session, which was as wonderful as I had remembered. But I was also thinking about ventilation, and distancing, and airflow. Like I said:

Risks. Benefits. Running the numbers. Making decisions. Trying to do the right thing. Trying to stay safe but also trying to live life.

Changing Situation

The Situation persists. But it has changed. There are no longer any official restrictions to speak of here in England. Instead it’s down to everyone to figure out individually what’s right.

Everyone is evaluating the risks, making calculations and coming to different conclusions. It’s only natural that everyone—myself incuded—thinks they’ve found the Goldilocks zone. “That person is being far too blasé! And that person is being far too cautious! But I’m doing exactly the right thing.”

With that in mind, I’m trying not to be judgemental about the decisions other people are making (apart from the decsion not to get vaccinated—I’m judgemental as hell about those selfish assholes). For example, I wear a mask when I’m on public transport. Other people don’t. I try not to judge them (although really, how hard is it to wear a piece of cloth for the duration of a bus ride? …sorry, that’s judgy).

This tendency to comparison extends to the country level too. Right now England has the highest case numbers for COVID-19 in Europe. I look at Ireland with its magnificentally low levels of vaccine hesistancy and I’m jealous: why can’t we be like that? But then I look to the United States and think, yowzah!, things could be worse.

Jessica and I have made a couple of trips to London. One involved indoor entertainment—the long-delayed premier of Akram Khan’s Creature at Sadlers Wells. We wore masks. Not everyone did. I tried not to judge. Others would judge me for just being inside the building.

The other trip to London was a dog-sitting visit, hanging out with Cider who is a very good boy.

After each excursion like that, we do a lateral flow test. So far, so negative. Having access to free testing makes a big difference to making post-hoc evaluations of risks. It boggles my mind that testing is pricy luxury in the States (there I go again, making comparisons).

We’ve also started playing tunes at a session in our local pub. We make sure to test ourselves before going. Spending an evening in a pub—even a nice chilled-out pub on a Monday evening—is still a risk. But it’s worth it. Each time we go I think “this is nice.”

This isn’t the first time we’ve had to make risk assessments. I remember it was like this last year between the first and second wave. Can we sit outside a restaurant? Can we go see the new Christopher Nolan film?

But it feels different this time because of our vaccinations. I know the Delta variant has altered the game, but the stakes certainly aren’t the same as pre-vaccine times. So while I’m still trying to avoid catching this damned disease, I’m also trying not to let it rule every decision the way it did last year.

It’s a balancing act. It’s the same balancing act that everyone is undertaking. We’re all walking our own individual tightropes. But at least being vaccinated, the tightrope doesn’t feel quite so high off the ground.

I’m speaking at a conference in Lisbon next week. That means going to an airport. That means getting on a plane. That means spending time inside a conference venue.

But it also means I’ll be travelling to a country with a wonderfully high vaccination rate, where I’ll be able to enjoy the sunny weather and dine outdoors in the evening.

Risks. Benefits. Running the numbers. Making decisions. Trying to do the right thing. Trying to stay safe but also trying to live life.

The Situation persists. But it has changed. I look forward to it changing more. I’m in line to get a booster shot before the year is out. That’ll be another factor in my calculations.

I look forward to a time when I won’t have to keep making these calculations. That time isn’t here yet.