Jeremy Keith's Blog, page 31

CSS Day 2022

I was in Amsterdam two weeks ago for CSS Day. It was glorious!

I mean, even without the conference it was just so nice to travel somewhere���by direct train, no less!���and spend some time in a beautiful European city enjoying the good weather.

And of course the conference was great too. I���ve been to CSS Day many times. I love it although technically it should be CSS days now���the conference runs for two days.

It���s an event that really treats CSS for what it is���a powerful language worthy of respect. Also, it has bitterballen.

This time I wasn���t just there as an attendee. I also had the pleasure of opening up the show. I gave a talk called In And Out Of Style, a look at the history���and alternative histories���of CSS.

The video is already online! I���ll get the talk transcribed and publish the text here soon. Meanwhile here���s a list of links to relevant material.

I really, really enjoyed giving this talk. It was so nice to be speaking to a room���or in this case, a church���with real people. I���m done giving talks to my screen. It���s just not the same. Giving this talk made me realise how much I need that feedback from the crowd���the laughs, the nods, maybe even the occasional lightbulb appearing over someone���s head.

As usual, my talk was broad and philosophical in nature. Big-picture pretentious talks are kind of my thing. In this case, I knew that I could safely brush over the details of all the exciting new CSS stuff I mentioned because other talks would be diving deep. And boy, did they ever dive deep!

It���s a clich�� to use the adjective ���inspiring��� to describe a conference, but given all that���s happening in the world of CSS right now, it was almost inevitable that CSS Day would be very inspiring indeed this year. Cascade layers, scoped styles, container queries, custom properties, colour spaces, animation and much much more.

If anything, it was almost too much. If I had one minor quibble with the event it would be that seven talks in a day felt like one talk too many to my poor brain (I think that Marc gets the format just right with Beyond Tellerrand���two days of six talks each). But what a great complaint to have���that there was a glut of great talks!

They���ve already announced the dates for next year���s CSS Day(s): June 8th and 9th, 2023. I strongly suspect that I���ll be there.

Thank you very much to ppk, Krijn, Martijn, and everyone involved in making this year���s CSS Day so good!

Declarative design systems

When I wrote about the idea of declarative design it really resonated with a lot of people.

I think that there���s a general feeling of frustration with the imperative approach to designing and developing���attempting to specify everything exactly up front. It just doesn���t scale. As Jason put it, the traditional web design process is fundamentally��broken:

This is the worst of all worlds���a waterfall process creating dozens of artifacts, none of which accurately capture how the design will look and behave in the browser.

In theory, design systems could help overcome this problem; spend a lot of time up front getting a component to be correct and then it can be deployed quickly in all sorts of situations. But the word ���correct��� is doing a lot of work there.

If you���re approaching a design system with an imperative mindset then ���correct��� means ���exact.��� With this approach, precision is seen as valuable: precise spacing, precise numbers, precise pixels.

But if you���re approaching a design system with a declarative mindset, then ���correct��� means ���resilient.��� With this approach, flexibility is seen as valuable: flexible spacing, flexible ranges, flexible outputs.

These are two fundamentally different design approaches and yet the results of both would be described as a design system. The term ���design system��� is tricky enough to define as it is. This is one more layer of potential misunderstanding: one person says ���design system��� and means a collection of very precise, controlled, and exact components; another person says ���design system��� and means a predefined set of boundary conditions that can be used to generate components.

Personally, I think the word ���system��� is the important part of a design system. But all too often design systems are really collections rather than systems: a collection of pre-generated components rather than a system for generating components.

The systematic approach is at the heart of declarative design; setting up the rules and ratios in advance but leaving the detail of the final implementation to the browser at runtime.

Let me give an example of what I think is a declarative approach to a component. I���ll use the ���hello world��� of design system components���the humble button.

Two years ago I wrote about programming CSS to perform Sass colour functions. I described how CSS features like custom properties and calc() can be used to recreate mixins like darken() and lighten().

I showed some CSS for declaring the different colour elements of a button using hue, saturation and lightness encoded as custom properties. Here���s a CodePen with some examples of different buttons.

See the Pen Button colours by Jeremy Keith (@adactio) on CodePen.

If these buttons were in an imperative design system, then the output would be the important part. The design system would supply the code needed to make those buttons exactly. If you need a different button, it would have to be added to the design system as a variation.

But in a declarative design system, the output isn���t as important as the underlying ruleset. In this case, there are rules like:

For the hover state of a button, the lightness of its background colour should dip by 5%.

That ends up encoded in CSS like this:

button:hover { background-color: hsl( var(--button-colour-hue), var(--button-colour-saturation), calc(var(--button-colour-lightness) - 5%) );}

In this kind of design system you can look at some examples to see the results of this rule in action. But those outputs are illustrative. They���re not the final word. If you don���t see the exact button you want, that���s okay; you���ve got the information you need to generate what you need and still stay within the pre-defined rules about, say, the hover state of buttons.

This seems like a more scalable approach to me. It also seems more empowering.

One of the hardest parts of embedding a design system within an organisation is getting people to adopt it. In my experience, nobody likes adopting something that���s being delivered from on-high as a pre-made sets of components. It���s meant to be helpful: ���here, use this pre-made components to save time not reinventing the wheel���, but it can come across as overly controlling: ���we don���t trust you to exercise good judgement so stick to these pre-made components.���

The declarative approach is less controlling: ���here are pre-defined rules and guidelines to help you make components.��� But this lack of precision comes at a cost. The people using the design system need to have the mindset���and the ability���to create the components they need from the systematic rules they���ve been provided.

My gut feeling is that the imperative mindset is a good match for most of today���s graphic design tools like Figma or Sketch. Those tools deal with precise numbers rather than ranges and rules.

The declarative mindset, on the other hand, increasingly feels like a good match for CSS. The language has evolved to allow rules to be set up through custom properties, calc(), clamp(), minmax(), and so on.

So, as always, there isn���t a right or wrong approach here. It all comes down to what���s most suitable for your organisation.

If your designers and developers have an imperative mindset and Figma files are considered the source of truth, than they would be better served by an imperative design system.

But if you���re lucky enough to have a team of design engineers that think in terms of HTML and CSS, then a declarative design system will be a force multiplier. A bicycle for the design engineering mind.

Re-evaluating technology

There���s a lot of emphasis put on decision-making: making sure you���re making the right decision; evaluating all the right factors before making a decision. But we rarely talk about revisiting decisions.

I think perhaps there���s a human tendency to treat past decisions as fixed. That���s certainly true when it comes to evaluating technology.

I���ve been guilty of this. I remember once chatting with Mark about something written in PHP���probably something I had written���and I made some remark to the effect of ���I know PHP isn���t a great language…��� Mark rightly called me on that. The language wasn���t great in the past but it has come on in leaps and bounds. My perception of the language, however, had not updated accordingly.

I try to keep that lesson in mind whenever I���m thinking about languages, tools and frameworks that I���ve investigated in the past but haven���t revisited in a while.

Andy talks about this as the tech tool carousel:

The carousel is like one of those on a game show that shows the prizes that can be won. The tool will sit on there until I think it���s gone through enough maturing to actually be a viable tool for me, the team I���m working with and the clients I���m working for.

Crucially a carousel is circular: tools and technologies come back around for re-evaluation. It���s all too easy to treat technologies as being on a one-way conveyer belt���once they���ve past in front of your eyes and you���ve weighed them up, that���s it; you never return to re-evaluate your decision.

This doesn���t need to be a never-ending process. At some point it becomes clear that some technologies really aren���t worth returning to:

It���s a really useful strategy because some tools stay on the carousel and then I take them off because they did in fact, turn out to be useless after all.

See, for example, anything related to cryptobollocks. It���s been well over a decade and blockchains remain a solution in search of problems. As Molly White put it, it���s not still the early days:

How long can it possibly be ���early days���? How long do we need to wait before someone comes up with an actual application of blockchain technologies that isn���t a transparent attempt to retroactively justify a technology that is inefficient in every sense of the word? How much pollution must we justify pumping into our atmosphere while we wait to get out of the ���early days��� of proof-of-work blockchains?

Back to the web (the actual un-numbered World Wide Web)���

Nolan Lawson wrote an insightful article recently about how he senses that the balance has shifted away from��single page apps. I���ve been sensing the same shift in the zeitgeist. That said, both Nolan and I keep an eye on how browsers are evolving and getting better all the time. If you weren���t aware of changes over the past few years, it would be easy to still think that single page apps offer some unique advantages that in fact no longer hold true. As Nolan wrote in a follow-up post:

My main point was: if the only reason you���re using an SPA is because ���it makes navigations faster,��� then maybe it���s time to re-evaluate that.

For another example, see this recent XKCD cartoon:

���You look around one day and realize the things you assumed were immutable constants of the universe have changed. The foundations of our reality are shifting beneath our feet. We live in a house built on sand.���

The day I discovered that Apple Maps is kind of good now

Perhaps the best example of a technology that warrants regular re-evaluation is the World Wide Web itself. Over the course of its existence it has been seemingly bettered by other more proprietary technologies.

Flash was better than the web. It had vector graphics, smooth animations, and streaming video when the web had nothing like it. But over time, the web caught up. Flash was the hare. The World Wide Web was the tortoise.

In more recent memory, the role of the hare has been played by native apps.

I remember talking to someone on the Twitter design team who was designing and building for multiple platforms. They were frustrated by the web. It just didn���t feel as fully-featured as iOS or Android. Their frustration was entirely justified …at the time. I wonder if they���ve revisited their judgement since then though.

In recent years in particular it feels like the web has come on in leaps and bounds: service workers, native JavaScript APIs, and an astonishing boost in what you can do with CSS. Most important of all, the interoperability between browsers is getting better and better. Universal support for new web standards arrives at a faster rate than ever before.

But developers remain suspicious, still prefering to trust third-party libraries over native browser features. They made a decision about those libraries in the past. They evaluated the state of browser support in the past. I wish they would re-evaluate those decisions.

Alas, inertia is a very powerful force. Sticking with a past decision���even if it���s no longer the best choice���is easier than putting in the effort to re-evaluate everything again.

What���s the phrase? ���Strong opinions, weakly held.��� We���re very good at the first part and pretty bad at the second.

Just the other day I was chatting with one of my colleagues about an online service that���s available on the web and also as a native app. He was showing me the native app on his phone and said it���s not a great app.

���Why don���t you add the website to your phone?��� I asked.

���You know,��� he said. ���The website���s going to be slow.���

He hadn���t tested this. But years of dealing with crappy websites on his phone in the past had trained him to think of the web as being inherently worse than native apps (even though there was nothing this particular service was doing that required any native functionality).

It has become a truism now. Native apps are better than the web.

And you know what? Once upon a time, that would���ve been true. But it hasn���t been true for quite some time …at least from a technical perspective.

But even if the technologies in browsers have reached parity with native apps, that won���t matter unless we can convince people to revisit their previously-formed beliefs.

The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That���s the hard part.

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:

Time to go play some songs with @SalterCane.

A close-up of a microphone in a practice room. In the background, a guitar player tunes up and a bass player waits to start.

Brighton in the sun.

People sitting around in the dappled sunshine on the green grass in a park with the distinctive Indian-inspired architecture of the Brighton Pavilion in the background, all under a clear blue sky.

Duck leg on white beans with sage, garlic, rosemary and olives.

Looking down on the crispy browned duck leg contrasting with the white beans, all with pieces of green fried herbs scattered throughout.

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:

Rich applied pace layers to career paths,Mark applied pace layers to the design process, andJorge Arango applied pace layers to reading.

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:

ProductionPatternsPrinciplesPurpose

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:

the original image,the alt.txt file, and the note itself.

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.