Journal

Something we often talk about in our Design System team is that components should not be like Swiss Army Knives. It’s better for them to be laser-focused because by limiting their scope to a single task they are more reusable and support a more extensible system through composition.

Discussions often arise when we consider the flip-side – components which do too much, know too much, or care too much! When they cover too much ground or make assumptions about their context, things go wrong. Here are some examples.

Card

In websites where many elements have a “rounded panel”-like appearance so as to pop off the background, you can run into problems. Because of the somewhat Card-like appearance, people start to regard many semantically distinct things as “Cards” (rather than limiting the meaning of Card to a more conventional definition). Here are some of the problems this can cause:

• If the name covers a million use cases, then how can you describe it sensibly, or define its boundaries?
• When do you stop piling on different things it can mean? How do you stop it growing? How do you avoid bloat?
• Ongoing naming/confusion issues: you’re setting yourself up for continued confusion and code disparity. If something is “semantically” a note, or a comment, or a message etc then you can expect that future staff are gonna describe it as that rather than a Card! They’ll likely (understandably) write code that feels appropriate too. The problem will continue.

I appreciate that often we need pragmatic solutions, so if our designs have lots of similar-looking elements then there is still something we can do. If the repeated thing is more of a “shape” than a something with common-purpose, then just call it out as that! That could either be by name – for example Every Layout have a Box layout which could be a starting point – or by categorisation i.e. by moving the non-ideally named thing into a clearly demarcated Utilities (or similar) category in your Design System.

Flex

It seems that a number of Design Systems have a Flex component. My feeling, though, is that these represent an early reaction to the emergence of CSS’s Flexbox, rather than necessarily being sensible system-friendly or consumer-friendly components. CSS layout covers a lot and I think breaking this down into different smaller tools (Stack, Inline, Grid etc) works better.

Button

I’ve talked before about the “Everything is a button” mindset and how it’s harmful. Buttons and links are fundamentally different HTML elements with totally different purposes, and bundling them together has various ill effects that I see on a regular basis.

References

• Shifting left: how introducing accessibility earlier helps the BBC’s design system (by Sophie Beaumont)

Getting to profitability is no longer a distant, post-IPO nice-to-have, but a short-term necessity for survival. But how to do that without cutting off the legs of the product team? By using better tools and techniques, that's how.

DHH of 37 Signals and Basecamp offers three pieces of advice for productivity and profitability.

1: Unless market conditions demand otherwise, delay native app development for as long as possible.

2: Hire full-stack developers, and don't let them split the frontend and backend into separate jurisdictions.

3: Hire designers who work natively with the web.

I’m not a fan of the term “full-stack” and also think it underestimates the complexity/speciality required to work (properly) as a front-end developer. However that aside, I think there is sense in these, even though others I know would disagree.

Me, Clair and Rudy just enjoyed a lovely weekend break. We stayed at Drinkbetween cottage on Banchory Farm. While only 70 minutes drive from home it provided some lovely countryside isolation, with the bonus of nice nearby towns to visit nearby too.

The cottage has recently been restored by the farm owners and was the perfect environment to relax.

Our nearest neighbours were some colourful pheasants, a flock of sheep and three highland cows grazing in the fields opposite. Beyond them, there was a view onto the firth of forth and Forth bridges.

On the Saturday we enjoyed a short trip to the nearby towns of Aberdour via Burntisland, and moseyed down to the lovely Silver beach where we stopped for a coffee at Sands.

Clair brought and made beautiful food and at night we watched Captain Fantastic.

It was a reminder of just how great a well-needed change of pace and scenery you can get in a short distance and space of time.

Clair and I loved this story of Viggo Mortensen’s Ben Cash and family temporarily leaving their off-grid existence in the Pacific Northwest to enter civilisation. It poses some interesting questions about parenting, lifestyle and morality but mainly, it’s just a lot of fun.

Judging by his movie review for The Guardian, Mark Kermode seemed to like Captain Fantastic too.

Having pre-recorded previous shows, I recently made a first visit to Clyde Built Radio’s station at the Barras market for a live show and really enjoyed it. It’s such a great location and it was a nice change to spin records on a Sunday morning.

I started off gently with atmospheric music from Detroit’s Ian Finklestein followed by a modern take on Steve Reich from Bitchin Bajas. From there it was into some hazy electronics and a dash of 80s boogie before landing on sounds from house music legends Abacus and Larry Heard.

Listen to the show.

Here’s the tracklist:

1. Ian Finklestein – Ago-ra
2. Bitchin Bajas – Amorpha
3. Isotope 217 – Audio Boxing
4. Coral D & PST – Send it
5. Komiko – Feel Alright
6. Visions of Tomorrow – Galaxy
7. Wheelup – Infinity feat. Abacus
8. Cy Gorman – Dewy Drip
9. Peech Boys – Don’t make me wait (Dub)
10. Purelink – Dozen Sunbeams (Nice Girl version)
11. Abacus – The Lower End Theory
12. Ossie – I hurt you
13. Fingers Inc – Bye Bye

Thanks to Amy for the invite, and Brandon, the engineer on the day.

Responsive design for tables is tricky. Sure, you can just make the table’s container horizontally scrollable but that’s more a developer convenience than a great user experience. And if you instead try to do something more clever, you can run into challenges as I did in the past. Still, we should strive to design good narrow screen user experiences for tables, alongside feasible technical solutions to achieve them.

In terms of UI design, I was interested to read Erik Kennedy’s recent newsletter on The best way to display tables on mobile. Erik lists three different approaches, which are (in reverse order of his preference):

1. Hide the least important columns
2. Cards with rows of Label-Value pairs
3. More radical “remix” as a “Mobile List”

Another article worth checking is Andrew Coyle’s The Responsive Table. He describes the following approaches:

1. Horizontal overflow table (inc. fixed first column)
2. Transitional table
3. Priority responsive table

For the transitional table, Andrew links to Charlie Cathcart’s Responsive & Accessible Data Table codepen. It looks similar (perhaps better looking but not quite as accessible) to Adrian Roselli’s Responsive Accessible Table.

I’ve started reading some entries from Manuel Matuzovic’s 100 days of (more or less) modern CSS series, and began with the excellent Day 99: Native Nesting. It clearly explains how to use the now-agreed syntax for various common scenarios.

The syntax is pretty close to what we’re used to doing with Sass, which is great!

Also, I’m now also clear that nested selectors must always start with a symbol rather than a letter. Often they would naturally do so anyway, for example when nesting a class since that already starts with a symbol (a full stop). But in cases where they wouldn’t – essentially only when nesting an “element selector” – we start it with an “&”. So:

main { & article { ... } }

Straightforward enough!

Regarding browser support for CSS nesting, at the time of writing it is available in Chrome and Safari Technology Preview only.

I would therefore only use it for demos and for the most non-essential enhancements. We’ll need to hold off any full-scale switch from Sass nesting to CSS nesting for large and important production websites until this is in Firefox and standard Safari, and until a sufficient percentage of users has the up-to-date versions. So a little while away yet, but given the current rate of browser updates, likely sooner than we might think!

Adam Silver’s collection of accessible form-related components – a companion to his book Form Design Patterns – is a brilliant reference.

In there you’ll find Autocomplete, date fields, validation and lots of other tricky components and patterns.

The component gallery is an up-to-date list of interface component examples. It’s really helpful for looking up existing naming conventions. It also contains a list of Design Systems.

Here’s an important update on native modal dialogues. TL;DR – it’s now OK to use dialog.

Last year I posted that Safari now supported the HTML dialog element meaning that we were within touching distance of being able to adopt it with confidence. My caveat was:

However first I think we’d need to make an informed decision regarding our satisfaction with support, based on the updated advice in Scott O’Hara’s article Having an Open Dialog.

(Accessibility expert Scott O’Hara has been diligently testing the dialog element for years.)

However the happy day has arrived. The other day Scott posted Use the dialog element (reasonably). It includes this advice:

I personally think it’s time to move away from using custom dialogs, and to use the dialog element instead.

That’s an important green-light!

And this of course means that we can stop DIYing modal dialogues from divs plus super-complicated scripting and custom ARIA, and instead let a native HTML element do most of the heavy lifting for us.

From a Design System perspective, I’d previously suggested to my team that when we revisit our Modal component we should err toward a good custom dialogue library first, however I’m now likely to recommend we go for native dialog instead. Which is great!