Journal

A tasty and healthy asian-style recipe from Gousto, which I enjoyed cooking and eating and would like to make again.

Ingredients (for two people)

• Diced chicken thigh (250g)
• Dried chilli flakes (0.5 tbsp)
• Fine egg noodle nests (2)
• Ginger and garilc paste (15g)
• Pho broth base (25g)
• Soy sauce (8ml)
• Spinach (80g)
• Toasted sesame oil (10ml)
• Vegetable oil

Instructions

Take chicken out of fridge, open the packet and let it air.

Boil a full kettle.

Heat a large, wide-based pan with a drizzle of veg oil over a high heat.

Once hot add your diced chicken thigh with your soy sauce and cook for an initial 5-6 min or until beginning to brown.

Was your spinach and pat it dry with kitchen paper.

Dissolve your pho broth paste in 600ml boiled water – this is your stock.

Reboil a kettle.

Add your fine egg noodles to a large bowl, cover them with boiled water and stir for 10 secs to separate the noodles. Set aside to soak for 4 min.

Once te chicken as ad an initial 5-6 min, add your ginger and garilc paste and half your chilli flakes and cook for a further 2-3 min or until fragrant.

Once fragrant add the stock to the pan with the chicken and bring to the boil over a high heat.

Once boiling, reduce the heat to medium and cook for a final 3 min or until the chicken is cooked through (no pink meat!).

Add the spinach to the pan and mix everything together until the spinach has slightly wilted – this is your fragrant chicken thigh and spinach broth.

Drain the soaked noodles.

Add the drained noodles to a bowl and pour in the fragrant chicken thigh and spinach broth.

Drizzle over your toasted sesame oil and sprinkle over the remaining chilli flakes.

Enjoy!

This interesting website from the GDS accessibility team sets out seven personas, each with different access needs.

You can use these profiles to experience the web from the perspective of the personas and gain more understanding of accessibility issues.

The site explains how to set up a device or browser to give each persona its own profile simulating the persona’s condition(s) and runs the assistive technology they use to help them.

Henny Swan, director at Tetralogical, with some great advice for those whom accessibility responsibility often falls to.

Henny advises:

On responsibility: accessibility is everyone’s responsibility all the time, not just your responsibility all the time. Establish that you can support accessibility, but others also need to do accessibility work and make accessibility-related decisions.

On relationship-building: build relationships with decision-makers with authority to embed accessibility and practitioners ready to build up their skills.

On sustainability and scalability: look for ways to scale what you do through demonstration and documentation.

On expectations: manage expectations and be clear about what you can do. You can give advice, but teams themselves need to make informed decsions. Also – you won’t know everyting, and sometimes you need the help of expert consultancy.

On having support to hand: build a support network through community groups and mentor programmes. I’ve also taken Henny’s advice and subscribed to the WebAIM accessibility discussion list.

This Design System reference website sports a smart architecture with some interesting sections.

The components are neatly organised into categories. And I like the Foundations area which includes a Design System Concepts section serving as a glossary of property and anatomical terms, plus an Accessibility section with neat diagrams.

I think what I like best about this site/system is its organisation and naming.

Working as a web developer, you’ll meet colleagues who don’t realise that accessibility should be non-negotiable. So I’m bookmarking for ready access Tim Berners-Lee’s oft-quoted but still powerful statement of intent from 1997.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

This particular W3C WAI page goes on to say:

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

Thus the impact of disability is radically changed on the Web because the Web removes barriers to communication and interaction that many people face in the physical world. However, when websites, applications, technologies, or tools are badly designed, they can create barriers that exclude people from using the Web.

Accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services.

A spicy but somewhat relatable thought from Adam Silver:

UX observation: I think there might be more devs who care about good design than there are designers. By “good” I mean works for everyone (is accessible) rather than looks nice. What do you think?

The ensuing conversation is pretty interesting. I particularly liked these contributions from Martin Hoyer:

Absolutely. Thinking about the design code-first and understanding how HTML works is so valuable. I don’t think designers should learn HTML but they shouldn’t be the first people to decide how something is built!

He goes on to describe how he thinks design should be done as follows:

In an ideal world (and I don’t think I’ve ever fully achieved this) I’d like to get some requirements (from product I guess), build a prototype in code, then collaboratively iterate on the design from there. Maybe call it a design sprint or whatever!

Applying opacity to an existing colour value is a pretty common design requirement, and here Chris presents five ways to achieve it.

I’ll admit that the explosion of colour models is one aspect of CSS that leaves me dizzy, so this explanation framed around a practical requirement really helps. The main approaches presented by Chris are:

• 8 digit hex code
• relative colour syntax (currently only supported in Safari)
• using a format other than hex such as HSL since it’s easier to apply transparency
• using (in a progressively enanced approach) HDR-display-friendly colours, via a new colour format such as oklch

My latest radio show is dedicated to Ryuichi Sakamoto, who sadly died recently. I played a couple of tracks by the great man alongside more of my favourite music.

Listen to the show on Soundcloud.

Here’s the tracklist:

1. Ryuichi Sakamoto & Alva Noto - Aurora
2. Matt Wilde - Who Cares
3. Kaidi Tatham - Funky Fool
4. Mac DeMarco - 20180702 2
5. Robert Ffrench - I am wondering
6. Ryuichi Sakamoto - Plastic Bamboo
7. Kraftwerk - Vitamin
8. Mac DeMarco - 20180924
9. Gal Costa - Relance (Bernhard Pinheiro edit)
10. Imagination - So good, so right (12″ mix then dub)
11. Romaal Kultan - Between Us, Part One
12. Jayme Marques - Berimbao
13. Souldrummers - Space And Time

I really enjoyed this one and I’m pleased with how it turned out. Thanks to Susan and Speedy for having me back.

Two lovely new websites (or website updates) appeared on my radar this last week that I wanted to note here for future front-end inspiration.

Vitaly Friedman’s Smart Interface Patterns has had some lovely animation and component work from Clearleft alumni Cassie Evans and Trys Mudford. Given Vitaly’s obsession with creating accessible, user-friendly components and the collaborators he has on board, I expect this site to be choc-full of well crafted nuggets for reference! It looks ace, too.

I noted a while ago that the W3C had a new Design System, and now the W3C has a new website in beta too. I imagine it might use components from that Design System alongside other carefully-considered patterns of markup, style and behaviour.

Nice job on these sites, to all concerned!

In responsive design we generally want a single component to get different styles in different contexts. Up until recently the prevailing method of context-awareness was to use a CSS media query to query the viewport size. This wasn’t ideal. For example you might want an component to be styled differently when in a narrow context such as a sidebar (regardless of the device size), and viewport-based queries don’t help with that.

But everything has changed. We can now use CSS to query the size of any given container and this feature is supported in all major browsers.

There’s a bit of new syntax to learn, so I recently had my first play with container queries on codepen.

My pen is pretty trivial, but the goal was specifically to do the most minimal test that lets me test-drive the key syntax. It turns out that it’s quite straightforward.

Define an element as a container:

.sidebar {
  container: ctr-sidebar / inline-size;
}

Change the styles of another element (.foo) when it’s inside that container and the container’s inline-size (the logical property name for width) matches a given query:

@container ctr-sidebar (max-width: 300px) {
  .foo {
    // context-specific styles go here 
  }
}

Note that you could also omit the ctr-sidebar context in the above query, if you wanted the change to apply in all defined containers.