Journal

Tetralogical are doing a great series of articles on running inclusive research. Their latest is about recruiting participants and covers whether you should recruit people with disabilities as part of your testing and if so who, and how many, and how to recruit them.

Previous articles addressed moderating usability testing sessions with people with disabilities, and analysing findings from inclusive user research.

Just had a memorable experience with Jason and Tom catching Herbie Hancock at the Edinburgh Festival. At 82 years old he still has amazing energy and capped his performance with a tour of the stage playing his keytar followed by a scissor jump!

Herbie’s piano playing was mesmerising – the solos really took me to another place and if this is how he plays in his eighties I can only imagine how good his gigs were in his prime. I also loved his warm anecdotes, including one about his friend Wayne Shorter just before treating us to a rendition of Footprints.

Other highlights included Cantaloupe Island, the mindbending Actual Proof and hearing guitarist Lionel Louke coax sounds from a guitar that you wouldn’t think possible.

Like most folks we didn’t holiday abroad during 2020 and 2021, when COVID was at its height. Trips abroad are a luxury and privilege so this was no hardship. However I’ll admit that once restrictions were lifted and things felt safer, we were pretty excited to head for some sun and good food, and set our sights on a first trip together to the south of France.

The location

We spent seven nights at Désir de Provence, hosted by owners Sylvie and Igor.

Dining out

La Bastide Bleue restaurant, Séguret.

Hotel Montmirail in Vacqueyras.

Beautiful local wine at Domaine Mathiflo in Suzette (right in the heart of the countryside).

Les Ramparts in Venasque – incredible nighttime view over the mountains

Monsieur Tu at L’isle sur la Sorgue, where we had a lovely meal of fish and wine by the canal.

Chez Serge in Carpentras.

Other highlights

Antiques market at Carpentras.

A day walking around the towns of Gigigondas, Seguret and Vaison La Romagne.

St Remy de Provence on a Wednesday morning for a fantastic market.

Carrieres Lumieres (caves featuring art installations) which was amazing.

Aix en Provence. Vasarely Foundation for Kinetic art. Lovely shops and vibe.

Chateau du Barroux was a stunning hilltop location with a castle, cobbled streets, a chapel and incredible panoramic views of the surrounding region including Mont Ventoux.

L’isle sur la sorgue – a lovely town which had an antiques market that blew Clair’s mind!

If we had more time

Hopefully on a future stay in the area we can visit Gord, Russelet (“the Colorado of Provence”), and Nimmes.

Our Design System team has recently received “new component requests” for some custom filtering controls. These look like custom-styled <select>s however their “options” appear more like checkboxes and radio buttons. I think the inspiration was Carbon Design System’s Dropdown component and the idea is to bring consistency to filtering controls in forms. Although it’s not yet time to fully explore this and make a yay/nay decision on the request, I’ve been doing some initial thinking.

(Note: this post is kinda a journey and work-in-progress. I’ll return to complete it and tidy up. For now it serves as a handy log of my research.)

When this was first mooted without guide designs, I assumed we’d be making a custom select. Filament Group have previously shown how to style one of those, although that only affects the “trigger” part. CSS can’t yet style the options. That then led me to check in on the progress of Open UI’s selectmenu element which does support styling the options however it appears that it’s far from road-ready.

However then I saw the designs and realised that while the outside looks like a select, the options look like a group of checkboxes or (kinda) like radio buttons, rather than typical <select> options. And of course the checkboxes and radio buttons themselves are custom-styled.

This led me to reading the following resources.

• Under-engineered multi-selects
• Under-engineered select menus
• Under-engineered custom radio buttons and checkboxen
• Inclusively Hiding & Styling Checkboxes and Radio Buttons

Léonie Watson’s post Perceived affordances and the functionality mismatch is also looming large in the back of my mind.

Ana demonstrates how to achieve a range slider effect accessibly, using web standards and without needing to reach for libraries.

As Ana’s tweet explains, this offers a number of features and benefits:

• can drag thumb with JS disabled
• receives focus
• keyboard navigation
• clicking track moves thumb there and changes slider value
• seen as slider in Accessibility panel
• no library needed, so less code in total

I really enjoyed The 15 Minute City by Natalie Whittle.

It presents the idea of modern cities in which residents can reach everything they need – shopping, work, school, green space, transport, exercise, culture etc – within 15 minutes on foot or by bike.

This idea is already working (or making good progress) in cities like Amsterdam and Paris.

And during periods of restriction during the Covid-19 pandemic it’s a way of life that people around the world have been forced to try.

There are numerous potential benefits of the idea – for example for physical and mental health, the environment, gaining more family and social time from less commuting, boosting neighbourhood economies through shopping local and so on.

On the other hand the 15-minute idea arguably favours the middle-class over the working-class, leads to diminished interpersonal skills, and ignores the important role of cities (such as London) in performing a wider, globally-connected role.

I enjoyed the thoughtful exploration of what are the important factors that give somewhere a sense of place. And I loved the chapter on Glasgow – Natalie’s home of the last 3 years and mine for much longer. It considers how past planning decisions in relation to new towns and the M8 motorway have become problematic for the city. It also looks at exciting modern projects such as the bridge to better connect the Sighthill estate on the outskirts to the city centre, and initiatives to revitalise the Clyde riverside.

Since reading this book I’m noticing more and more these matters being “in the air”. Just recently The Guardian’s Big Idea feature asked Should cars be banned from cities? If that gave one perspective on traffic in cities, I recently spoke to a taxi driver who offered another. Taxi drivers are being made to change their cars to hybrid models soon, but feel that the combination of increased outlays and lack of necessary technology and infrastructure make the move prohibitive. It was a reminder that we have to consider the potential effects on lots of different people when planning change.

Léonie tackles the prickly subject of “element re-purposing” in web development. This post follows a fantastic Twitter exchange started by Lea Verou regarding whether the common visual design request for “adjacent but mututally exclusive buttons” should be built as radio buttons or using <button> elements.

Using one element or set of elements (usually because of their functionality) and styling them to look like something else is a common pattern […but…] it creates a mismatch between the actions people expect they can take and the ones they actually can.

Relatedly, Lea has also gathered her post-discussion thoughts and decisions into a blog post What is the best way to mark up an exclusive button group? and shared a new button-group web component!

Meanwhile, Léonie already has a theme-toggle web component on her personal website which demonstrates the use of buttons and aria-pressed.

Thank you so much, Lea and Léonie.

(via @LeonieWatson)

Update July 19/7/22

I just had a twitter conversation with Adrian Roselli where I suggested that the reasons for developers considering radio inputs over buttons for Lea’s use case might be more nuanced than simply misunderstanding HTML. I’m not sure we agreed on that one in the end, however Adrian shared some helpful heuristics when choosing betweeen JS-powered buttons and forms:

A checkbox, radio button, select menu are meant to gather information. The submit button sends the form (whether get, post, or an AJAX call). A button (non-submit) causes a change on the page, such as toggling a control, showing or hiding something, etc. Different context/use.

I think it would help to think of form fields as for forms. Forms that users intentionally submit (no matter if processed client- or server-side). Forms that gather info. Buttons that have states (expanded, pressed, etc) are for manipulation of the current view.

Takeaways:

• Pick the HTML solution that is generally intended for your use case.
• Use a form if you’re gathering information but if you’re not, don’t. There will be exceptions like “filter forms” but that’s an edge case and most forms are not like that.
• Forms are ideally things that users intentionally submit, via a submit button. This helps rule out “clever forms” as an option.
• Use a button to cause a change on, or manipulate, the current page.

I’ve started trialling different HTML and technologies for the “simple” responsive images (i.e. not art-directed per breakpoint) used in blog articles on this site. I’m continuing to lean on Cloudinary as my free image host, CDN and format-conversion service. But at the HTML level I’ve moved from a complicated <img srcset> based approach that includes many resized versions of the same image. I now use a simpler <picture> and <source> based pattern that keeps the number of images and breakpoints low and instead – by using the source element’s type attribute – takes advantage of the performance gains offered by the new avif and webp image formats.

My new approach is based on advice in Jake Archibald’s brilliant article Halve the size of images by optimising for high density displays. Jake explains that the majority of your traffic likely consists of users with high density screens so when we can combine optimising for that and making performance gains in a progressively enhanced way, we should!

Jake offers a “lazy but generally good enough” approach:

Here's the technique I use for most images on this blog: I take the maximum size the image can be displayed in CSS pixels, and I multiply that by two, and I encode it at a lower quality, as it'll always be displayed at a 2x density or greater. Yep. That's it. For 'large' images in blog posts like this, they're at their biggest when the viewport is 799px wide, where they take up the full viewport width. So I encode the image 1,598 pixels wide.

<picture>
  <source type="image/avif" srcset="red-panda.avif" />
  <source type="image/webp" srcset="red-panda.webp" />
  <img src="red-panda.jpg" width="1598" height="1026" alt="A red panda" />
</picture>

So, if you want your images to be as sharp as possible, you need to target images at the user's device pixels, rather than their CSS pixels. To encode a 2x image, I throw it into Squoosh.app, and zoom it out until it's the size it'll be displayed on a page. Then I just drag the quality slider as low as it'll go before it starts looking bad.

Taking Jake’s guidance and tweaking it for my Cloudinary-based context, my recent post April 2022 mixtape included its image like so:

<figure>
  <picture>
    <source type="image/avif" srcset="https://res.cloudinary.com/…/f_avif,q_auto,w_1292/v1654433393/mato_1500_squooshed_mozjpg_xjrkhl.jpg" />
    <source type="image/webp" srcset="https://res.cloudinary.com/…/f_webp,q_auto,w_1292/v1654433393/mato_1500_squooshed_mozjpg_xjrkhl.jpg" />
      <img class="u-full-parent-width" src="https://res.cloudinary.com/…/f_jpg,q_auto,w_1292/v1654433393/mato_1500_squooshed_mozjpg_xjrkhl.jpg" width="1292" height="1292" alt="Side A of the 7-inch vinyl release of Mato’s “Summer Madness" loading="lazy" decoding="async" />
  </picture>
  <figcaption>Mato’s “Summer Madness”, as featured on the mix</figcaption>
</figure>

And my process was as follows:

1. Take a photo (for me, that’ll be on my phone). Without doing anything special it’ll already be wide enough.
2. Apple use the HEIC format. To get around that, do: Share, Copy, open Files > HEIC to JPG, paste and it’ll save as JPG.
3. Drop it into Squoosh and do the following:

• rotate it if necessary
• resize it to 1300 wide (in my current layout 1292 is twice as wide (2 × 646) as the image would need to go, and I just round up to 1300)
• reduce its quality a bit (stopping before it gets noticeably bad)

1. Encode that as a mozjpg which gave the best size reduction and as far as I can tell, is a safe approach to use.
2. Upload to my Cloudinary account then copy its new Cloudinary URL.
3. Prepare the image HTML per the above snippet. The first source tells Cloudinary to use format avif, while for the second source it’s webp, and for the fallback img it’s jpg.
4. Check the rendered image in a browser to confirm that the modern formats are being used.

I’ll DRY-up that HTML into an 11ty shortcode in due course.

I’ve no doubt that I’ll be getting some of this wrong – this stuff gets pretty complicated! For example I note my image file size is still quite large so I wonder if I should be manually creating the avif and webp versions in Squoosh myself to ensure getting the savings that make this approach worthwhile, rather than handing the conversion off to Cloudinary. (However this would mean having to host more images…)

In the meantime however, I’m happy that this approach has simplified the mental overhead of handling modern, responsive blog images, and optimising it can be a work in progress.

Additional references

• Browser support for avif on caiuse.com
• Twitter thread on forthcoming Safari support for avif, and related info

Recently I’ve noticed some developers recommending using the CSS aspect-ratio property directly on images. My understanding of aspect-ratio was that it’s not so much intended for elements like img which already have an intrinsic aspect ratio, but rather for the likes of div which do not. Furthermore, when the goal is to prevent the layout shift that can occur after an image loads we should supply our images with width and height HTML attributes rather than using CSS.

In this timely post, Jake helpfully explains how width and height attributes are used by CSS as presentation hints to automatically set an aspect-ratio that will also, in cases where the attributes were set wrongly, fall back to the image’s intrinsic aspect ratio. Therefore, concentrating on HTML alone is ideal for our content images. My previous approach seems sound but I now know a little more about why.

If I'm adding an image to an article on my blog, that's content. I want the reserved space to be the aspect ratio of the content. If I get the width and height attributes wrong, I'd rather the correct values were used from the content image. Therefore, width and height attributes feel like the best fit. This means I can just author content, I don't need to dip into inline styles.

If it's a design requirement that the layout of an image is a particular aspect ratio, enforcing that with aspect-ratio in CSS can be appropriate. For example, a hero image that must be 16 / 9 – if the image isn't quite 16 / 9 I don't want it messing up my design, I want the design to take priority. Although, if the image isn't actually that aspect ratio, it'll either end up stretched (object-fit: fill), letter-boxed (object-fit: contain), or cropped (object-fit: cover). None of which are ideal.

For a while now I’ve been enjoying this series of bite-sized travel guides from The Guardian, which puts the spotlight on a European town or city and hands over to a switched-on local to share food, shopping, cultural and green space highlights.

Some are more suited to my tastes and budget than others, but overall they’ve been good. And not just for far-flung places – on a recent day-trip east I checked out a number of the stops on their Edinburgh guide and it gave me a great basis for further exploration.