Journal tags: medium

614

sparkline

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.

Alt writing

I made the website for this year’s UX London by hand.

Well, that’s not entirely true. There’s exactly one build tool involved. I’m using Sergey to include global elements—the header and footer—something that’s still not possible in HTML.

So it’s minium viable static site generation rather than actual static files. It’s still very hands-on though and I enjoy that a lot; editing HTML and CSS directly without intermediary tools.

When I update the site, it’s usually to add a new speaker to the line-up (well, not any more now that the line up is complete). That involves marking up their bio and talk description. I also create a couple of different sized versions of their headshot to use with srcset. And of course I write an alt attribute to accompany that image.

By the way, Jake has an excellent article on writing alt text that uses the specific example of a conference site. It raises some very thought-provoking questions.

I enjoy writing alt text. I recently described how I updated my posting interface here on my own site to put a textarea for alt text front and centre for my notes with photos. Since then I’ve been enjoying the creative challenge of writing useful—but also evocative—alt text.

Some recent examples:

But when I was writing the alt text for the headshots on the UX London site, I started to feel a little disheartened. The more speakers were added to the line-up, the more I felt like I was repeating myself with the alt text. After a while they all seemed to be some variation on “This person looking at the camera, smiling” with maybe some detail on their hair or clothing.

  • Videha Sharma
    The beaming bearded face of Videha standing in front of the beautiful landscape of a riverbank.
  • Candi Williams
    Candi working on her laptop, looking at the camera with a smile.
  • Emma Parnell
    Emma smiling against a yellow background. She’s wearing glasses and has long straight hair.
  • John Bevan
    A monochrome portrait of John with a wry smile on his face, wearing a black turtleneck in the clichéd design tradition.
  • Laura Yarrow
    Laura smiling, wearing a chartreuse coloured top.
  • Adekunle Oduye
    A profile shot of Adekunle wearing a jacket and baseball cap standing outside.

The more speakers were added to the line-up, the harder I found it not to repeat myself. I wondered if this was all going to sound very same-y to anyone hearing them read aloud.

But then I realised, “Wait …these are kind of same-y images.”

By the very nature of the images—headshots of speakers—there wasn’t ever going to be that much visual variation. The experience of a sighted person looking at a page full of speakers is that after a while the images kind of blend together. So if the alt text also starts to sound a bit repetitive after a while, maybe that’s not such a bad thing. A screen reader user would be getting an equivalent experience.

That doesn’t mean it’s okay to have the same alt text for each image—they are all still different. But after I had that realisation I stopped being too hard on myself if I couldn’t come up with a completely new and original way to write the alt text.

And, I remind myself, writing alt text is like any other kind of writing. The more you do it, the better you get.

Pace layers and design principles

I think it was Jason who once told me that if you want to make someone’s life a misery, teach them about typography. After that they’ll be doomed to notice all the terrible type choices and kerning out there in the world. They won’t be able to unsee it. It’s like trying to unsee the arrow in the FedEx logo.

I think that Stewart Brand’s pace layers model is a similar kind of mind virus, albeit milder. Once you’ve been exposed to it, you start seeing in it in all kinds of systems.

Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.

Last month I sent out an edition of the Clearleft newsletter that was all about pace layers. I gathered together examples of people who have been infected with the pace-layer mindworm who were applying the same layered thinking to other areas:

My own little mash-up is applying pace layers to the World Wide Web. Tom even brought it to life as an animation.

See the Pen Web Layers Of Pace by Tom (@webrocker) on CodePen.

Recently I had another flare-up of the pace-layer pattern-matching infection.

I was talking to some visiting Austrian students on the weekend about design principles. I explained my mild obsession with design principles stemming from the fact that they sit between “purpose” (or values) and “patterns” (the actual outputs):

Purpose » Principles » Patterns

Your purpose is “why?”

That then influences your principles, “how?”

Those principles inform your patterns, “what?”

Hey, wait a minute! If you put that list in reverse order it looks an awful lot like the pace-layers model with the slowest moving layer at the bottom and the fastest moving layer at the top. Perhaps there’s even room for an additional layer when patterns go into production:

  • Production
  • Patterns
  • Principles
  • Purpose

Your purpose should rarely—if ever—change. Your principles can change, but not too frequently. Your patterns need to change quite often. And what you’re actually putting out into production should be constantly updated.

As you travel from the most abstract layer—“purpose”—to the most concrete layer—“production”—the pace of change increases.

I can’t tell if I’m onto something here or if I’m just being apopheniac. Again.

The complete line-up for UX London

The line-up for UX London is now complete!

Two thematically-linked talks have been added to day one. Emma Parnell will be talking about the work she did with NHS Digital on the booking service for Covid-19 vaccinations. Videha Sharma—an NHS surgeon!—will be talking about co-designing and prototyping in healthcare.

There’s a bunch of new additions to day three. Amir Ansari will be talking about design systems in an enterprise setting and there’ll be two different workshops on design systems from John Bevan and Julia Belling.

But don’t worry; if design systems aren’t your jam, you’ve got options. Also on day three, Alastair Somerville will be getting tactile in his workshop on sensory UX. And Trenton Moss will be sharing his mind-control tricks in his workshop, “How to sell in your work to anyone.”

You can peruse the full schedule at your leisure. But don’t wait too long before getting your tickets. Standard pricing ends in ten days on Friday, June 3rd.

And don’t forget, you get quite a discount when you buy five or more tickets at a time so bring the whole team. UX London should be your off-site.

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.

UX London should be your off-site

Check out the line up for this year’s UX London. I know I’m biased, but damn! That’s objectively an excellent roster of smart, interesting people.

When I was first putting that page together I had the name of each speaker followed by their job title and company. But when I stopped and thought about it—not to be too blunt—I realised “who cares?”. What matters is what they’ll be talking about.

And, wow, what they’ll be talking about sounds great! Designing for your international audiences, designing with the autistic community, how to win stakeholders and influence processes, the importance of clear writing in product development, designing good services, design systems for humans, and more. Not to mention workshops like designing your own research methods for a very diverse audience, writing for people who hate writing, and harnessing design systems.

You can peruse the schedule—which is almost complete now—to get a feel for how each day will flow.

But I’m not just excited about this year’s UX London because of the great talks and workshops. I’m also really, really excited at the prospect of gathering together—in person!—over the course of three days with my peers. That means meeting new and interesting people, but frankly, it’s going to be just as wonderful to hang out with my co-workers.

Clearleft has been a remote-only company for the past two years. We’ve still got our studio and people can go there if they like (but no pressure). It’s all gone better than I thought it would given how much of an in-person culture we had before the pandemic hit. But it does mean that it’s rare for us all to be together in the same place (if you don’t count Zoom as a place).

UX London is going to be like our off-site. Everyone from Clearleft is going to be there, regardless of whether “UX” or “design” appears in their job title. I know that the talks will resonate regardless. When I was putting the line-up together I made sure that all the talks would have general appeal, regardless of whether you were a researcher, a content designer, a product designer, a product manager, or anything else.

I’m guessing that the last two years have been, shall we say, interesting at your workplace too. And even if you’ve also been adapting well to remote work, I think you’ll agree that the value of having off-site gatherings has increased tenfold.

So do what we’re doing. Make UX London your off-site gathering. It’ll be a terrific three-day gathering in the sunshine in London from Tuesday, June 28th to Thursday, June 30th at the bright and airy Tobacco Dock.

If you need to convince your boss, I’ve supplied a list of reasons to attend. But you should get your tickets soon—standard pricing ends in just over two weeks on Friday, June 3rd. After that there’ll only be last-chance tickets available.

Image previews with the FileReader API

I added a “notes” section to this website eight years ago. I set it up so that notes could be syndicated to Twitter. Ever since then, that’s the only way I post to Twitter.

A few months later I added photos to my notes. Again, this would get syndicated to Twitter.

Something’s bothered me for a long time though. I initially thought that if I posted a photo, then the accompanying text would serve as a decription of the image. It could effectively act as the alt text for the image, I thought. But in practice it didn’t work out that way. The text was often a commentary on the image, which isn’t the same as a description of the contents.

I needed a way to store alt text for images. To make it more complicated, it was possible for one note to have multiple images. So even though a note was one line in my database, I somehow needed a separate string of text with the description of each image in a single note.

I eventually settled on using the file system instead of the database. The images themselves are stored in separate folders, so I figured I could have an accompanying alt.txt file in each folder.

Take this note from yesterday as an example. Different sizes of the image are stored in the folder /images/uploaded/19077. Here’s a small version of the image and here’s the original. In that same folder is the alt text.

This means I’m reading a file every time I need the alt text instead of reading from a database, which probably isn’t the most performant way of doing it, but it seems to be working okay.

Here’s another example:

In order to add the alt text to the image, I needed to update my posting interface. By default it’s a little textarea, followed by a file upload input, followed by a toggle (a checkbox under the hood) to choose whether or not to syndicate the note to Twitter.

The interface now updates automatically as soon as I use that input type="file" to choose any images for the note. Using the FileReader API, I show a preview of the selected images right after the file input.

Here’s the code if you ever need to do something similar. I’ve abstracted it somewhat in that gist—you should be able to drop it into any page that includes input type="file" accept="image/*" and it will automatically generate the previews.

I was pleasantly surprised at how easy this was. The FileReader API worked just as expected without any gotchas. I think I always assumed that this would be quite complex to do because once upon a time, it was quite complex (or impossible) to do. But now it’s wonderfully straightforward. Story of the web.

My own version of the script does a little bit more; it also generates another little textarea right after each image preview, which is where I write the accompanying alt text.

I’ve also updated my server-side script that handles the syndication to Twitter. I’m using the /media/metadata/create method to provide the alt text. But for some reason it’s not working. I can’t figure out why. I’ll keep working on it.

In the meantime, if you’re looking at an image I’ve posted on Twitter and you’re judging me for its lack of alt text, my apologies. But each tweet of mine includes a link back to the original note on this site and you will most definitely find the alt text for the image there.

Agile design principles

I may have mentioned this before, but I’m a bit of a nerd for design principles. Have I shown you my equivalent of an interesting rock collection lately?

If you think about design principles for any period of time, it inevitably gets very meta very quickly. You start thinking about what makes for good design principles. In other words, you start wondering if there are design principles for design principles.

I’ve written before about how I think good design principles should encode some level of prioritisation. The classic example is the HTML design principle called the priority of consitituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

It’s wonderfully practical!

I realised recently that there’s another set of design princples that put prioritisation front and centre—the Agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And there’s this excellent explanation which could just as well apply to the priorty of constituencies:

That is, while there is value in the items on the right, we value the items on the left more.

Yes! That’s the spirit!

Ironically, the Agile manifesto also contains a section called principles behind the Agile manifesto which are …less good (at least they’re less good as design principles—they’re fine as hypotheses to be tested).

Agile is far from perfect. See, for example, Miriam Posner’s piece Agile and the Long Crisis of Software. But where Agile isn’t fulfilling its promise, I’d say it’s not because of its four design principles. If anything, I think the problems arise from organisations attempting to implement Agile without truly internalising the four principles.

Oh, and that’s another thing I like about the Agile manifesto as a set of design principles—the list of prioritised principles is mercifully short. Just four lines.

UX London speaker updates

If you’ve signed up to the UX London newsletter then this won’t be news to you, but more speakers have been added to the line-up.

Steph Troeth will be giving a workshop on day one. That’s the day with a strong focus on research, and when it comes to design research, Steph is unbeatable. You can hear some of her words of wisdom in an episode of the Clearleft podcast all about design research.

Heldiney Pereira will be speaking on day two. That’s the day with a focus on content design. Heldiney previously spoke at our Content By Design event and it was terrific—his perspective on content design as a product designer is invaluable.

Lauren Pope will also be on day two. She’ll be giving a workshop. She recently launched a really useful content audit toolkit and she’ll be bringing that expertise to her UX London workshop.

Day three is going to have a focus on design systems (and associated disciplines like design engineering and design ops). Both Laura Yarrow and Inayaili León will be giving talks on that day. You can expect some exciting war stories from the design system trenches of HM Land Registry and GitHub.

I’ve got some more speakers confirmed but I’m going to be a tease and make you wait a little longer for those names. But check out the line-up so far! This going to be such an excellent event (I know I’m biased, but really, look at that line-up!).

June 28th to 30th. Tobacco Dock, London. Get your ticket if you haven’t already.

Eventing

In person events are like buses. You go two years without one and then three come along at once.

My buffer is overflowing from experiencing three back-to-back events. Best of all, my participation was different each time.

First of all, there was Leading Design New York, where I was the host. The event was superb, although it’s a bit of a shame I didn’t have any time to properly experience Manhattan. I wasn’t able to do any touristy things or meet up with my friends who live in the city. Still the trip was well worth it.

Right after I got back from New York, I took the train to Edinburgh for the Design It Build It conference where I was a speaker. It was a good event. I particularly enjoyed Rafaela Ferro talk on accessibility. The last time I spoke at DIBI was 2011(!) so it was great to make a return visit. I liked that the audience was seated cabaret style. That felt safer than classroom-style seating, allowing more space between people. At the same time, it felt more social, encouraging more interaction between attendees. I met some really interesting people.

I got from Edinburgh just in time for UX Camp Brighton on the weekend, where I was an attendee. I felt like a bit of a moocher not giving a presentation, but I really, really enjoyed every session I attended. It’s been a long time since I’ve been at a Barcamp-style event—probably the last Indie Web Camp I attended, whenever that was. I’d forgotten how well the format works.

But even with all these in-person events, online events aren’t going anywhere anytime soon. Yesterday I started hosting the online portion of Leading Design New York and I’ll be doing it again today. The post-talk discussions with Julia and Lisa are lots of fun!

So in the space of just of a couple of weeks I’ve been a host, a speaker, and an attendee. Now it’s time for me to get my head back into one other event role: conference curator. No more buses/events are on the way for the next while, so I’m going to be fully devoted to organising the line-up for UX London 2022. Exciting!

Hosting Leading Design New York

I went to New York to host the Leading Design conference. It was weird and wonderful.

Weird, because it felt strange and surreal to be back in a physical space with other people all sharing the same experience.

Wonderful, for exactly the same reasons.

Leading Design

This was a good way to ease back into live events. It wasn’t a huge conference. Just over a hundred people. So it felt intimate, while still allowing people to quite literally have space to themselves.

I can’t tell you much about the post-talk interviews I conducted with the speakers. That’s because what happens at Leading Design stays at Leading Design, at least when it comes to the discussions after the talks. We made it clear that Leading Design was a safe place for everyone to share their stories, even if—especially if—those were stories you wouldn’t want to share publicly or at work.

I was bowled over by how generous and open and honest all the speakers were. Sure, there were valuable lessons about management and leadership, but there were also lots of very personal stories and insights. Time and time again I found myself genuinely moved by the vulnerability that the speakers displayed.

Leadership can be lonely. Sometimes very lonely. I got the impression that everyone—speakers and attendees alike—really, really appreciated having a non-digital space where they could come together and bond over shared travails. I know it’s a cliché to talk about “connecting” with others, but at this event it felt true.

The talks themselves were really good too. I loved seeing how themes emerged and wove themselves throughout the two days. Rebecca did a fantastic job of curating the line-up. I’ve been to a lot of events over the years and I’ve seen conference curation of varying degrees of thoughtfulness. Leading Design New York 2022 is right up there with the best of them. It was an honour to play the part of the host (though I felt very guilty when people congratulated me on such a great event—“Don’t thank me”, I said, “Thank Rebecca—I’m just the public face of the event; she did all the work!”)

My hosting duties aren’t over. This week we’ve got the virtual portion of Leading Design New York. There’ll be two days of revisiting some of the conference talks, and one day of workshops.

For the two days of talks, I’m going to be joined by two brilliant panelists for post-talk discussions—Julia Whitney and Lisa Welchman. This should be fun!

Best of all, for this portion of the event I don’t need to get into an airplane and cross the Atlantic.

That said, the journey was totally worth it for Leading Design New York. Also, by pure coincidence, the event coincided with St. Patrick’s Day. For the first time in two years, New York hosted its legendary parade and it was just a block or two away from the conference venue.

I nipped out during the lunch break to cheer on the marching bands. Every county was represented. When the representatives from county Cork went by, there’d be shouts of “Up Cork!” When the county Donegal delegation went by, it was “Up Donegal!”

It’s just a shame I couldn’t stick around for the representatives from county Down.

Going to New York

I’m flying to New York on Monday. That still sounds a little surreal to me, but it’s happening.

I’ll be hosting Leading Design New York. Even a month ago it wasn’t clear if the in-person event would even be going ahead. But there was a go/no-go decision and it was “go!” Now, as New York relaxes its mandates, it’s looking more and more like the right decision. It’s still probably going to feel a bit weird to be gathering together with other people …but it’s also going to feel long overdue.

Rebecca has put together a fantastic line-up of super-smart design leaders. My job will be to introduce them before they speak and then interview them afterwards, also handling questions from the audience.

I’m a little nervous just because I want to do a really good job. But I’ve been doing my homework. And given how well the hosting went for UX Fest, I’m probably being uneccesarily worried. I need to keep reminding myself to enjoy it. It’s a real privilege that I get to spend two days in the company of such erudite generous people. I should make the most of it.

If you’re going to be at Leading Design New York, I very much look forward to seeing you there.

If you’re not coming to Leading Design but you’re in the neighbourhood, let me know if you’ve got any plans for St. Patrick’s Day. I’ve already got my green paisley shirt picked out for my on-stage duties that day.

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!

A bug with progressive web apps on iOS

Dave recently wrote some good advice about what to do—and what not to do—when it comes to complaining about web browsers. I wrote something on this topic a little while back:

If there’s something about a web browser that you’re not happy with (or, indeed, if there’s something you’re really happy with), take the time to write it down and publish it

To summarise Dave’s advice, avoid conspiracy theories and snark; stick to specifics instead.

It’s very good advice that I should heed (especially the bit about avoiding snark). In that spirit, I’d like to document what I think is a bug on iOS.

I don’t need to name the specific browser, because there is basically only one browser allowed on iOS. That’s not snark; that’s a statement of fact.

This bug involves navigating from a progressive web app that has been installed on your home screen to an external web view.

To illustrate the bug, I’ll use the example of The Session. If you want to recreate the bug, you’ll need to have an account on The Session. Let me know if you want to set up a temporary account—I can take care of deleting it afterwards.

Here are the steps:

  1. Navigate to thesession.org in Safari on an iOS device.
  2. Add the site to your home screen.
  3. Open the installed site from your home screen—it will launch in standalone mode.
  4. Log in with your username and password.
  5. Using the site menu, navigate to the links section of the site.
  6. Click on any external link.
  7. After the external link opens in a web view, tap on “Done” to close the web view.

Expected behaviour: you are returned to the page you were on with no change of state.

Actual behaviour: you are returned to the page you were on but you are logged out.

So the act of visiting an external link in a web view while in a progressive web app in standalone mode seems to cause a loss of cookie-based authentication.

This isn’t permanent. Clicking on any internal link restores the logged-in state.

It is surprising though. My mental model for opening an external link in a web view is that it sits “above” the progressive web app, which remains in stasis “behind” it. But the page must actually be reloading, either when the web view is opened or when the web view is closed. And that reload is behaving like a fetch event without credentials.

Anyway, that’s my bug report. It may already be listed somewhere on the WebKit Bugzilla but I lack the deductive skills to find it. I’m not even sure if that’s the right place for this kind of bug. It might be specific to the operating system rather than the rendering engine.

This isn’t a high priority bug, but it is one of those cumulatively annoying software paper cuts.

Hope this helps!

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.

Curating UX London 2022

The first speakers are live on the UX London 2022 site! There are only five people announced for now—just enough to give you a flavour of what to expect. There will be many, many more.

Putting together the line-up of a three-day event is quite challenging, but kind of fun too. On the one hand, each day should be able to stand alone. After all, there are one-day tickets available. On the other hand, it should feel like one cohesive conference, not three separate events.

I’ve decided to structure the three days to somewhat mimic the design process…

The first day is all about planning and preparation. This is like the first diamond in the double-diamond process: building the right thing. That means plenty of emphasis on research.

The second day is about creation and execution. It’s like that second diamond: building the thing right. This could cover potentially everything but this year the focus will be on content design.

The third day is like the third diamond in the double dia— no, wait. The third day is about growing, scaling, and maintaining design. That means there’ll be quite an emphasis on topics like design systems and design engineering, maybe design ops.

But none of the days will be exclusively about a single topic. There are evergreen topics that apply throughout the process: product design, design ethics, inclusive design.

It’s a lot to juggle! But I’m managing to overcome choice paralysis and assemble a very exciting line-up indeed. Trust me—you won’t want to miss this!

Early bird tickets are available until February 28th. That’s just a few days away. I recommend getting your tickets now—you won’t regret it!

Quite a few people are bringing their entire teams, which is perfect. UX London can be both an educational experience and a team-bonding exercise. Let’s face it, it’s been too long since any of us have had a good off-site.

If you’re one of those lucky people who’s coming along (or if you’re planning to), I’m curious: given the themes mentioned above, are there specific topics that you’d hope to see covered? Drop me a line and let me know.

Also, if you read the description of the event and think “Oh, I know the perfect speaker!” then I’d love to hear from you. Maybe that speaker is you. (Although, cards on the table; if you look like me—another middle-age white man—I may take some convincing.)

Right. Time to get back to my crazy wall of conference curation.

02022-02-22

Eleven years ago, I made a prediction:

The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.

One year later, Matt called me on it and the prediction officially became a bet:

We’re playing for $1000. If I win, that money goes to the Bletchley Park Trust. If Matt wins, it goes to The Internet Archive.

I’m very happy to lose this bet.

When I made the original prediction eleven years ago that a URL on the longbets.org site would no longer be available, I did so in a spirit of mischief—it was a deliberately meta move. But it was also informed by a genuine feeling of pessimism around the longevity of links on the web. While that pessimism was misplaced in this case, it was informed by data.

The lifetime of a URL on the web remains shockingly short. What I think has changed in the intervening years is that people may have become more accustomed to the situation. People used to say “once something is online it’s there forever!”, which infuriated me because the real problem is the exact opposite: if you put something online, you have to put in real effort to keep it online. After all, we don’t really buy domain names; we just rent them. And if you publish on somebody else’s domain, you’re at their mercy: Geocities, MySpace, Facebook, Medium, Twitter.

These days my view towards the longevity of online content has landed somewhere in the middle of the two dangers. There’s a kind of Murphy’s Law around data online: anything that you hope will stick around will probably disappear and anything that you hope will disappear will probably stick around.

One huge change in the last eleven years that I didn’t anticipate is the migration of websites to HTTPS. The original URL of the prediction used HTTP. I’m glad to see that original URL now redirects to a more secure protocol. Just like most of the World Wide Web. I think we can thank Let’s Encrypt for that. But I think we can also thank Edward Snowden. We are no longer as innocent as we were eleven years ago.

I think if I could tell my past self that most of the web would using HTTPS by 2022, my past self would be very surprised …’though not as surprised at discovering that time travel had also apparently been invented.

The Internet Archive has also been a game-changer for digital preservation. While it’s less than ideal that something isn’t reachable at its original URL, knowing that there’s probably a copy of the content at archive.org lessens the sting considerably. I couldn’t be happier that this fine institution is the recipient of the stakes of this bet.

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.