Jeremy Keith's Blog, page 17

adactio.com on Mastodon

I���ve been on Mastodon since 2017, but now my website is on there too. I���m @adactio@mastodon.social. My website is @adactio.com@adactio.com���search for adactio.com in your Mastodon client of choice.

What���s the difference? Well, with my mastodon.social account, I���m syndicating stuff���most of my notes, and all of my journal���and including a link back to the original source here on my site. With the adactio.com account, it is the original source.

I thought about migrating over to my adactio.com account from my mastodon.social account, but I actually like having a separate profile. I browse Mastodon a lot more than I post, and browsing is a lot easier to do with a regular account.

If you���d like your website to be available on Mastodon, Bridgy Fed is the magic tool that makes it available. You���ll need to be able to send webmentions, and you���ll need to configure some .well-known directives. If you���ve you���ve already got webmention-sending set up, it���s all quite straightforward (though you will also need to update your HTML to include a link back to fed.brid.gy in each entry you want syndicated).

For some reason the syndication didn���t seem to be working at first, but then when I followed @adactio.com@adactio.com from my @adactio@mastodon.social account, it started working. Maybe there needs to be at least one follower.

Also, my links don���t seem to be showing up on Mastodon even though it looks like everything is posting okay. Not sure what that is about.

Anyway, if you want to follow me on Mastodon, you now have a choice. There���s me, @adactio@mastodon.social, or there���s my website, @adactio.com@adactio.com.

Sessions

Brighton has a thriving Irish music scene. Some sessions are weekly���every Sunday afternoon in The Bugle and every Wednesday evening in The Jolly Brewer. Some are every two weeks, like the session in The Fiddler���s Elbow. Others are monthly, like the session in The Dover Castle and the session in The Lord Nelson.

So it sometimes happens that if the calendar aligns just right, there are many sessions in one week. This was one of those weeks. I managed a streak of five sessions in a row.

The first was the regular Sunday afternoon session in The Bugle.

Then on Monday, it was The Fiddler’s Elbow.

The night after that there was a one-off session in the Hand in Hand, which will hopefully become a regular monthly occurrence.

On Wednesday it was the regular session at The Jolly Brewer.

Finally on Thursday it was the monthly session at The Lord Nelson.

I’m very lucky to have so many opportunities to play the music I love with my fellow musicians. I don’t take it for granted.

Lost in calculation

As well as her personal site, wordridden.com, Jessica also has a professional site, lostintranslation.com.

Both have been online for a very long time. Jessica���s professional site pre-dates the Sofia Coppola film of the same name, which explains how she was able to get that domain name.

Thanks to the internet archive, you can see what lostintranslation.com looked like more than twenty years ago. The current iteration of the site still shares some of that original design DNA.

The most recent addition to the site is a collection of images on the front page: the covers of books that Jessica has translated during her illustrious career. It���s quite an impressive spread!

I used a combination of CSS grid and responsive images to keep the site extremely performant. That meant using a combination of the picture element, source elements, srcset attributes, and the sizes attribute.

That last part always feels weird. I have to tell the browser what sizes the images will displayed at, which can change depending on the viewport width. But I���ve already given that information in the CSS! It feels weird to have to repeat that information in the HTML.

It���s not just about the theoretical niceties of DRY: Don���t Repeat Yourself. There���s the very practical knock-on effects of having to update the same information in two places. If I update the CSS, I need to remember to update the HTML too. Those concerns no longer feel all that separate.

But I get it. Browsers use a look-ahead parser to start downloading images as soon as possible, so I understand why I need to explicitly state what size the images will be displayed at. Still, it feels like something that a computer should be calculating, not something for a human to list out by hand.

But wait! Most of the images on that page also have a loading attribute with a value of ���lazy���. That tells browsers they don���t have to download the images immediately. That sort of negates the look-ahead parser.

That���s why the HTML spec now includes a value for the sizes attribute of ���auto���. It���s only supposed to be used in conjunction with loading="lazy" (otherwise it means 100vw).

Browser makers are on board with this. You can track the implementation progress for Chromium, WebKit, and Firefox.

I would very much like to see this become a reality!

How green is my server?

The Session does very well in terms of performance. You can see the data from the Chrome UX Report (CRUX).

What���s good for performance is good for the environment. Sure enough, The Session gets a very high score from the website carbon calculator:

Hurrah! This web page achieves a carbon rating of A+

This is cleaner than 99% of all web pages globally

But under the details about hosting it says:

Oh no, it looks like this web page uses bog standard energy

The Session is hosted on DigitalOcean, who tend to be quite tight-lipped about their energy suppliers. Fortunately others have done some sleuthing to figure out which facilities are running on green energy.

One of the locations to get the green thumnbs up is the Amsterdam facility housed by Equinix. That���s where The Session is hosted.

I���m glad that I was able to find out that the site is running on 100% renewable energy, but I wish I didn���t need to go searching to find this out. DigitalOcean need to be a lot more transparent about the energy sources for their hosting facilities.

The complete line-up for Patterns Day ���and a workshop!

The line-up for Patterns Day is complete! You���ll be hearing from eight fantastic speakers on March 7th 2024 here in Brighton.

I really like the mix of speakers we���ve got���

Half of the speakers will be sharing what they���ve learned from design systems in their organisations: D��bora from LEGO, Mary from the Financial Times, Yolijn from the Dutch government, and Samantha from University College London. That���s a good spread of deep dives.

The other half of the speakers can go broad across design systems in general: Vitaly on design patterns, Rich on typography, Geri on accessibility, and Jina on ���well, absolutely everything to do with design systems!

I���m so happy that I could get the line-up to have this mix. If you have any interest in design systems at all���whether it���s as a designer, a developer, a product manager, or anything else���you won���t want to miss this. Early bird tickets are ��225.

But wait! That���s not all. If you really want to dive deep into interface design patterns, then stick around. The day after Patterns Day, Vitaly is running a one-day workshop:

In this in-person workshop with Vitaly Friedman, UX consultant and creative lead behind Smashing Magazine, we���ll dive deep into dissecting how to solve complex design problems. Whether you���re working on a complex nested multi-level navigation or creating enterprise grade tables, this workshop will give you the tools you need to excel at your work.

Places are limited. There isn���t room for everyone who���s going to be at Patterns Day, so if you���and your team���want to learn design pattern kung-fu from the master, get your workshop ticket now! Workshop tickets are ��445.

UX London returns in 2024

Put the dates in your dairy: UX London 2024 will be on June 18th, 19th, and 20th.

Better yet, grab a ticket right now. There are super early-bird tickets available until this Friday.

If you want a flavour of what to expect, check out the speakers that are already confirmed: Brad!, Ben!, Tshili!, and more!

It���s early days but I can tell you what to expect from each day. The first day will be themed around research. The second will have a focus on product design. The third day will be themed around design systems and design ops.

As usual, there���ll be a mix of talks and workshops: a single track of inspirational talks in the morning, followed by a choice of practical workshops in the afternoon.

We���ll be in a new venue next year too���right in the heart of London.

See you there!

HTML web components

Web components have been around for quite a while, but it feels like they���re having a bit of a moment right now.

It turns out that the best selling point for web components was ���wait and see.��� For everyone who didn���t see the benefit of web components over being locked into a specific framework, time is proving to be a great teacher.

It���s not just that web components are portable. They���re also web standards, which means they���ll be around as long as web browsers. No framework can make that claim. As Jake Lazaroff puts it, web components will outlive your JavaScript framework.

At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to build on React are doing it largely out of habit.

Others are making more sensible judgements and, having been bitten by lock-in in the past, are now giving web components a go.

If you���re one of those people making the move from React to web components, there���ll certainly be a bit of a learning curve, but that would be true of any technology change.

I have a suggestion for you if you find yourself in this position. Try not to bring React���s mindset with you.

I���m talking about the way React components are composed. There���s often lots of props doing heavy lifting. The actual component element itself might be empty.

If you want to apply that model to web components, you can. Lots of people do. It���s not unusual to see web components in the wild that look like this:

The custom element is just a shell. All the actual power is elsewhere. It���s in the JavaScript that does all kinds of clever things with the shadow DOM, templates, and slots.

There is another way. Ask, as Robin does, ���what would HTML do?���

Think about composibility with existing materials. Do you really need to invent an entirely new component from scratch? Or can you use HTML up until it reaches its limit and then enhance the markup?

Robin writes:

I don���t think we should see web components like the ones you might find in a huge monolithic React app: your Button or Table or Input components. Instead, I���ve started to come around and see Web Components as filling in the blanks of what we can do with hypertext: they���re really just small, reusable chunks of code that extends the language of HTML.

Dave talks about how web components can be HTML with superpowers. I think that���s a good attitude to have. Instead of all-singing, all-dancing web components, it feels a lot more elegant to use web components to augment your existing markup with just enough extra behaviour.

Where does the shadow DOM come into all of this? It doesn���t. And that���s okay. I���m not saying it should be avoided completely, but it should be a last resort. See how far you can get with the composibility of regular HTML first.

Eric described his recent epiphany with web components. He created a super-slider custom element that wraps around an existing label and input type="range":

You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS!�� Everything���s of the Light Side of the Web.�� No need to pierce the Vale of Shadows or whatever.

When you wrap some existing markup in a custom element and then apply some new behaviour with JavaScript, technically you���re not doing anything you couldn���t have done before with some DOM traversal and event handling. But it���s less fragile to do it with a web component. It���s portable. It obeys the single responsibility principle. It only does one thing but it does it well.

Jim created an icon-list custom element that wraps around a regular ul populated with li elements. But he feels almost bashful about even calling it a web component:

Maybe I shouldn���t be using the term ���web component��� for what I���ve done here. I���m not using shadow DOM. I���m not using the templates or slots. I���m really only using custom elements to attach functionality to a specific kind of component.

I think what Eric and Jim are doing is exemplary. See also Zach���s web components.

At the end of his post, Eric says he���d like a nice catchy term for these kinds of web components. In Dave���s catalogue of web components, they���re called ���element extensions.��� I like that. It���s pretty catchy.

Or we could call them ���HTML web components.��� If your custom element is empty, it���s not an HTML web component. But if you���re using a custom element to extend existing markup, that���s an HTML web component.

React encouraged a mindset of replacement: ���forgot what browsers can do; do everything in a React component instead, even if you���re reinventing the wheel.���

HTML web components encourage a mindset of augmentation instead.

Creativity

It���s like a little mini conference season here in Brighton. Tomorrow is ffconf, which I���m really looking forward to. Last week was UX Brighton, which was thoroughly enjoyable.

Maybe it���s because the theme this year was all around creativity, but all of the UX Brighton speakers gave entertaining presentations. The topics of innovation and creativity were tackled from all kinds of different angles. I was having flashbacks to the Clearleft podcast episode on innovation���have a listen if you haven���t already.

As the day went on though, something was tickling at the back of my brain. Yes, it���s great to hear about ways to be more creative and unlock more innovation. But maybe there was something being left unsaid: finding novel ways of solving problems and meeting user needs should absolutely be done ���once you���ve got your basics sorted out.

If your current offering is slow, hard to use, or inaccessible, that���s the place to prioritise time and investment. It doesn���t have to be at the expense of new initiatives: this can happen in parallel. But there���s no point spending all your efforts coming up with the most innovate lipstick for a pig.

On that note, I see that more and more companies are issuing breathless announcements about their new ���innovative��� ���AI��� offerings. All the veneer of creativity without any of the substance.

In the margins

John Willshire has been pondering web marginilia AKA stuff you put in your sidebar.

He has a particular fondness for the good ol��� blogroll. I���ve still got my analogue equivalent on my homepage���the bedroll. It���s a list of links to people who���ve stayed over. Maybe I should also have a regular blogroll, but I suspect it would just be a reproduction of feeds I���m subscribed to.

Then there���s marginalia at the level of a blog post, rather than a whole blog. Kevin Marks points out that this is something that Vannevar Bush described his theoretical memex doing���a device I was just talking about. Kevin created a proof of concept showing outbound and inbound links.

Outbound links are annoted versions of the A elements in a blog post. Inbound links are webmentions (which should now include this post of mine).

Kevin has those links in the margins on either side of the blog post. I���ve also got links that go with my blog posts, but they���re displayed linearly:

the post itself,any responses (webmentions),related posts, something I only recently added, andposts from the same day further back in time.

Do they still count as marginalia when they���re presented vertically rather than alongside? For mobile devices, I���m not sure there���s any alternative.

A memex in every web browser

When Mathew Modine���s character first shows up in Christopher Nolan���s Oppenheimer, I figured the rest of the cinema audience wouldn���t have appreciated me shouting out ���VANNEVAR BUSH IN THE HOUSE!��� so I screamed it on the inside.

The Manhattan Project was not his only claim to fame or infamy. When it comes to the world we now live in, Bush���s idea of the memex has been almost equally influential. His article As We May Think became a touchstone for Douglas Engelbart and later Tim Berners-Lee.

But as Matt Thompson points out:

���the device he describes does not resemble the internet or anything I���ve ever found on it.

Then he says:

What Bush was describing sounds to me like what you might get if you turned a browser history ��� the most neglected piece of the software ��� into a robust and fully featured machine of its own. It would help you map the path you charted through a web of knowledge, refine those maps, order them, and share them

Yes! This!! I 100% agree with the description of browser history as ���the most neglected piece of the software.��� While I wouldn���t go as far as Chris when he says web browsers kind of suck, I���m kind of amazed that there hasn���t been more innovation and competition in this space.

If anything we���ve outsourced the management of our browsing history to services like Delicious and Pinboard, or to tools like Obsidian and Roam Research. Heck, the links section of my website is my attempt to manage and annotate my own associative trails.

Imagine if that were baked right into a web browser. Then imagine how beautiful such a rich source of data might look.

Like Matt says:

I don���t think anything like this exists. So Bush���s essay still transfixes me.