Jeremy Keith's Blog, page 37

Measuring design on the Clearleft podcast

A new episode of the Clearleft podcast just dropped and I have to say, this is one of my favourites so far. It���s all about measuring design.

There was a bit of a theme running through UX Fest earlier this year. On the one hand, there was all the talk of designers learning to speak the language of business (to get that coveted seat at the table), which means talking in numbers. But on the other hand, isn���t there a real danger in reducing user experience to numbers in a spreadsheet?

For this episode I put the narrative together using lots of snippets from different talks, not just from UX Fest but from previous Clearleft events too. I also got some good hot takes from my colleagues Chris, Andy, and Maite. Oh, and it opens with former US Secretary of Defense, Robert McNamara. If you know, you know.

This episode comes in at 22 and a half minutes and I think it���s well worth your time. Have a listen.

This is the penultimate episode of season three. Just one more to go!

Twenty years of writing on my website

On this day twenty years ago I wrote the first entry in my online journal. In the intervening two decades I���ve written a further 2,817 entries.

I am now fifty years old, which means I���ve been blogging for two fifths of my lifetime.

My website has actually been around for longer than twenty years, but its early incarnations had no blog. That all changed when I relaunched the site on September 30th, 2001.

I wrote at the time:

I���m not quite sure what I will be saying here over the coming days, weeks, months and years.

Honestly I still feel like that.

I think it���s safe to assume an “anything goes” attitude for what I post here. Being a web developer, there���s bound to be lots of geeky, techy stuff but I also want a place where I can rant and rave about life in general.

That���s been pretty true, although I feel that maybe there���s been too much geeky stuff and not enough about everything else in my life.

I���ll try and post fairly regularly but I don���t want to make any promises I can���t keep. Hopefully, I���ll be updating the journal on a daily basis.

I made no promises but I think I���ve done a pretty good job. Many���s the blogger who has let the weeds grow over their websites as they were lured by the siren song of centralised social networks. I���m glad that I���ve managed to avoid that fate. It feels good to look back on twenty years of updates posted on my own domain.

Anyway, let���s see what happens. I hope you���ll like it.

I hope you still like it.

Here are some of my handpicked highlights from the past twenty years of blogging:

Hyperdrive, April 20th, 2007

Last night in San Francisco.

Design doing, November 11, 2007

The opposite of design thinking.

Iron Man and me, December 1st, 2008

The story of how one of my Flickr pictures came to be used in a Hollywood movie.

Seams, May 12th, 2014

There is a crack, a crack in everything. That���s how the light gets in.

Web! What is it good for?, May 28th, 2015

Not absolutely nothing, but not absolutely everything either.

Split, April 10th, 2019

Materials and tools; client and server; declarative and imperative; inclusion and privilege.

Innovation on the Clearleft podcast

We���re past the halfway mark for this season of the Clearleft podcast. Episode four came out today. It���s all about innovation.

At the beginning of the episode, I think you can hear the scorn in my voice. Y���see, innovation is one of the words���like ���disruptive������that gets thrown around a lot and everyone assumes it only has positive connotations. But words like ���innovative��� and ���disruptive��� can be applied to endeavours that are not good for the world.

Bitcoin, for example, could rightly be described as innovative (and disruptive) but it���s also a planet-destroying ponzi scheme���like a lovechild of the trolley problem and the paperclip maximizer designed to generate the most amount of waste for the least amount of value.

So, yeah, I���m not a fan of innovation for innovation���s sake. But don���t worry. For this episode of the podcast I set my personal feelings to one side and let the episode act as a conduit for much smarter people.

The whole thing clocks in at 25 minutes but I think this episode might have the widest range of contributors yet. There are snippets from an internal Clearleft discussion, soundbites from a panel discussion, extracts from conference talks, as well as interviews with individuals. From Clearleft there���s Chris How, Andy Thornton, Jon Aizlewood and Lorenzo Ferronato. From the panel discussion there���s Janna Bastow, Matt Cooper-Wright, Dorota Biniecka and Akshan Ish. And from UX Fest there���s Radhika Dutt, Teresa Torres and Gregg Bernstein.

I happily defer to their expertise on this topic. Have a listen and hear what they have to say.

Halfway through season three of the Clearleft podcast

Each season of the Clearleft podcast has six episodes. Three of the six episodes of the current season are available with another three still to come.

In case you missed them, the episodes of season three released so far are:

Coaching

What���s the difference between training, coaching, and mentorship?

Design Engineering

A role that sits at the intersection���or rather, the gap���between design and engineering.

Design Research

The journey from evaluative research to generative research.

That���s quite a mixed bag. You might think that there���s no particular unifying to a season of the podcast.

Well, that���s kind of true. There���s no specific theme. But each season does have a meta-grouping.

At Clearleft, we think about our services in three interconnected categories: explore, create, and grow.

���Explore��� is all about the big strategic picture.���Create��� is the nitty-gritty work of delivery.���Grow��� is what connects those together.

Each season of the podcast focuses on one of those categories. This season it���s all about ���explore��� with a bit of ���grow��� thrown in.

The next three episodes of this season will double down on the big-picture thinking. I don���t want to give any spoilers, but I���ll just remind you that if you���re not already subscribed to the Clearleft podcast, I highly recommend rectifying that situation.

Subscribe via RSS, or on Apple, Google, Spotify, or wherever you get your podcasts from.

And if you���re already subscribed …thank you. If you���re enjoying listening to it half as much as I���m enjoying making it, then I���m enjoying it twice as much as you.

Seriously though, if you like what you hear, please share it around. Drop a link to the Clearleft podcast into your work Slack channel or share it in a tweet.

Thank you for listening.

Design research on the Clearleft podcast

We���re halfway through the third season of the Clearleft podcast already!

Episode three is all about design research. I like the narrative structure of this. It���s a bit like a whodunnit, but it���s more like a whydunnit. The ���why��� question is ���why aren���t companies hiring more researchers?���

The scene of the crime is this year���s UX Fest, where talks by both Teresa Torres and Gregg Bernstein uncovered the shocking lack of researchers. From there, I take up the investigation with Maite Otondo and Stephanie Troeth.

I won���t spoil it but by the end there���s an answer to the mystery.

I learned a lot along the way too. I realised how many axes of research there are. There���s qualitative research (stories, emotion, and context) and then there���s quantitative research (volume and data). But there���s also evualative research (testing a hyphothesis) and generative research (exploring a problem space before creating a solution). By my count that gives four possible combos: qualitative evaluative research, quantitative evaluative research, qualitative generative research, and quantitative generative research. Phew!

Steph was a terrific guest. Only a fraction of our conversation made it into the episode, but we chatted for ages.

And Maite kind of blew my mind too, especially when she was talking about the relationship between research and design and she said:

Research is about the present and design is about the future.

����

I���m going to use that quote again in a future episode. In fact, this episode on design research leads directly into the next two episodes. You won���t want to miss them. So if you���re not already subscribed to the Clearleft podcast, you should get on that, whether it���s via the RSS feed, Apple, Google, Spotify, Overcast, or wherever you get your podcasts from.

Have a listen to this episode on design research and if you���re a researcher yourself, remember that unlike most companies we value research at Clearleft and that���s why we���re hiring another researcher right now. Come and work with us!

Writing the Clearleft newsletter

The Clearleft newsletter goes out every two weeks on a Thursday. You can peruse the archive to see past editions.

I think it���s a really good newsletter, but then again, I���m the one who writes it. It just kind of worked out that way. In theory, anyone at Clearleft could write an edition of the newsletter.

To make that prospect less intimidating, I put together a document for my colleagues describing how I go about creating a new edition of the newsletter. Then I thought it might be interesting for other people outside of Clearleft to get a peek at how the sausage is made.

So here���s what I wrote…

Topics

The description of the newsletter is:

A round-up of handpicked hyperlinks from Clearleft, covering design, technology, and culture.

It usually has three links (maybe four, tops) on a single topic.

The topic can be anything that���s interesting, especially if it���s related to design or technology. Every now and then the topic can be something that incorporates an item that���s specifically Clearleft-related (a case study, an event, a job opening). In general it���s not very salesy at all so people will tolerate the occasional plug.

You can use the ���iiiinteresting��� Slack channel to find potential topics of interest. I���ve gotten in the habit of popping potential newsletter fodder in there, and then adding related links in a thread.

Tone

Imagine you���re telling a friend about something cool you���ve just discovered. You can sound excited. Don���t worry about this looking unprofessional���it���s better to come across as enthusiastic than too robotic. You can put real feelings on display: anger, disappointment, happiness.

That said, you can also just stick to the facts and describe each link in turn, letting the content speak for itself.

If you���re expressing a feeling or an opinion, use the personal pronoun ���I���. Don���t use ���we��� unless you���re specifically referring to Clearleft.

But most of the time, you won���t be using any pronouns at all:

So-and-so has written an article in such-and-such magazine on this-particular-topic.

You might find it useful to have connecting phrases as you move from link to link:

Speaking of some-specific-thing, this-other-person has a different viewpoint.

or

On the subject of this-particular-topic, so-and-so wrote something about this a while back.

Structure

The format of the newsletter is:

An introductory sentence or short paragraph.A sentence describing the first link, ending with the title of the item in bold.A link to the item on its own separate line.An excerpt from the link, usually a sentence or two, styled as a quote.Repeat steps 2 to 4 another two times.���

Take a look through the archive of previous newsletters to get a feel for it.

Subject line

Currently the newsletter is called dConstruct from Clearleft. The subject line of every edition is in the format:

dConstruct from Clearleft ��� Title of the edition

(Note that���s an em dash with a space on either side of it separating the name of the newsletter and the title of the edition)

I often try to come up with a pun-based title (often a punny portmanteau) but that���s not necessary. It should be nice and short though: just one or two words.

Design engineering on the Clearleft podcast

If you���re subscribed to the Clearleft podcast, then the latest episode is winging its way through the ether to your podcast software. The topic is one close to my heart: design engineering.

I wrote about this role back in February. I think my fervour comes across in that post and you can probably hear it in the podcast episode too.

As ever, I end up asking the question, ���So what exactly is insert topic of the podcast episode here?���

I���ve got some smart folks answering that question. There���s an excerpt from Tobias Ahlin���s talk at this year���s UX Fest. And when I interviewed Adekunle Oduye for a previous episode on prototyping, we also discussed design engineering so I pulled out the relevant bits. But the bulk of the episode features the voice of Trys Mudford.

As you can gather from the many posts on Trys���s blog, he has a lot to say on the topic of design engineering. Luckily for me, he says it all with a clear, articulate delivery���the perfect podcast guest!

This episode finishes with a call to action (oh, the synergy!). If, after listening to 23 minutes of discussion on design engineering, you find yourself thinking ���Hey, I think I might be a design engineer!���, then you should definitely head along to this job opening at Clearleft:

We���re currently looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production.

Have a listen to episode two of season three of the Clearleft podcast and if you like what you hear, come and join us!

Accessibility testing

I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.

While I was doing this I started to realise that not all accessibility issues are created equal. I don���t just mean in their severity. I mean that some issues can���and should���be caught early on, while other issues can only be found later.

Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that���s the time to check the ratio between background and foreground colours to make sure there���s enough contrast between them. You can catch this kind of thing later on, but by then it���s likely to come with a higher cost���you might have to literally go back to the drawing board. It���s better to find the issue when you���re at the drawing board the first time.

Then there���s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they���re issues of ommission: form fields that don���t have an explicitly associated label element (using the for and id attributes); images that don���t have alt text; pages that don���t have sensible heading levels or landmark regions like main and nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you���ve got sensible forms, sensible headings, alt text on images, and a solid document structure, you���ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated: alt text for images; labels for inputs.

Then there���s interactive stuff. If you only use native HTML elements you���re probably in the clear, but chances are you���ve got some bespoke interactivity on your site: a carousel; a mega dropdown for navigation; a tabbed interface. HTML doesn���t give you any of those out of the box so you���d need to make your own using a combination of HTML, CSS, JavaScript and ARIA. There���s plenty of testing you can do before launching���I always ask myself ���What would Heydon do?������but these components really benefit from being tested by real screen reader users.

So if you commission an accessibility audit, you should hope to get feedback that���s mostly in that third category���interactive widgets.

If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it���s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there���s a framework or content management system that���s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.

If you get feedback about colour contrast issues, just fixing the immediate problem isn���t going to address the underlying issue. There���s a process problem, or perhaps a communication issue. In that case, don���t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.

When you commission an accessibility audit, you want to make sure you���re getting the most out of it. Don���t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

Stakeholders of styling

When I wrote about the new accent-color property in CSS, I pondered how much control a web developer should have over styling form controls:

Who are we to make that decision? Shouldn���t the user���s choice take primacy over our choices?

But then again, where do we draw the line? We���re allowed over-ride link colours. We���re allowed over-ride font choices.

Ultimately, I came down on the side of granting authors more control:

If developers don���t get a standardised way to customise native form controls, they���ll just recreate their own over-engineered versions.

This question of ���who gets to decide?��� used to be much more prevelant in the early days of the web. One way to think about this is that there are three stakeholders involved in the presentation of a web page:

The author of the page. ���Author��� is spec-speak for designer or developer.The user.The browser, or user agent. A piece of software tries to balance the needs of both author and user. But, as the name implies, the user takes precedence.

These days we tend to think of web design a single-stakeholder undertaking. The author decides how something should be presented and then executes that decision using CSS.

But as Eric once said, every line of you CSS you write is a suggestion to the browser. That���s not how we think about CSS though. We think of CSS like a series of instructions rather than suggestions. Never mind respecting the user���s preferences; one of the first things we do is reset all the user agent���s styles.

In the early days of the web, more consideration was given to the idea of style suggestions rather than instructions. Heck, users could always over-ride any of your suggestions with their own user stylesheet. These days, users would need to install a browser extension to do the same thing.

The first proposal for CSS had a concept called ���influence���:

h2.font.size = 20pt 40%

Here, the requested influence is reduced to 40%. If a style sheet later in the cascade also requests influence over h2.font.size, up to 60% can be granted. When the document is rendered, a weighted average of the two requests is calculated, and the final font size is determined.

I think the only remnant of ���influence��� left in CSS is accidental. It���s in the specificity of selectors …and the !important declaration.

I think it���s a shame that user stylesheets are no longer a thing. But I get why they were dropped from browsers. They date from a time when it was mostly nerds using the web, before ���regular folks��� came on board. I understand why it became a little-used feature, suitable for being dropped. But the principle of it still rankles slightly.

But in recent years there has been a slight return to the multi-stakeholder concept of styling websites. Thanks to prefers-reduced-motion and prefers-color-scheme, a responsible author can choose to bow to the wishes of the user.

I was reminded of this when I added a dark mode to my website:

Y���know, when I first heard about Apple adding dark mode to their OS���and also to CSS���I thought, ���Oh, great, Apple are making shit up again!��� But then I realised that, like user style sheets, this is one more reminder to designers and developers that they don���t get the last word���users do.

Accent all areas

Whenever a new version of Chrome comes out, there���s an accompanying blog post listing what���s new. Chrome 93 just came out and, sure enough, Pete has written a blog post about it.

But what I think is the most exciting addition to the browser isn���t listed.

What is this feature that���s got me so excited?

Okay, I���ve probably oversold it now because actually, it looks like a rather small trivial addition. It���s the accent-color property in CSS.

Up until now, accent colour was controlled by the operating system. If you���re on a Mac, go to ���System Preferences��� and then ���General���. There you���ll see an option to change your accent colour. Try picking a different colour. You���ll see that change cascade down into the other form fields in that preference pane: checkboxes, radio buttons, and dropdowns.

Your choice will also cascade down into web pages. Any web page that uses native checkboxes, radio buttons and other interface elements will inherit that colour.

This is how interface elements are supposed to work. The browser inherits the look���n���feel of the inputs from the operating system.

That���s the theory anyway. In practice, form elements���such as dropdowns���can look different from browser to browser, something that shouldn���t be happening if the browsers are all inheriting from the operating system.

Anyway, it���s probably this supposed separation of responsibility between browser and operating system which has led to the current situation with form fields and CSS. Authors can style form fields up to a point, but there���s always a line that you don���t get to cross.

The accent colour of a selected radio button or a checkbox has historically been on the other side of that line. You either had to accept that you couldn���t change the colour, or you had to make your own checkbox or radio button interface. You could use CSS to hide the native element and replace it with an image instead.

That feels a bit over-engineered and frankly kind of hacky. It reminds me of the bad old days of image replacement for text before we had web fonts.

Now, with the accent-color property in CSS, authors can over-ride the choice that the user has set at the operating system level.

On the one hand, this doesn���t feel great to me. Who are we to make that decision? Shouldn���t the user���s choice take primacy over our choices?

But then again, where do we draw the line? We���re allowed over-ride link colours. We���re allowed over-ride font choices.

Ultimately I think it���s a good thing that authors can now specify an accent colour. What makes me think that is the behaviour that authors have shown if they don���t have this ability���they do it anyway, and in a hackier manner. This is why I think the work of the Open UI group is so important. If developers don���t get a standardised way to customise native form controls, they���ll just recreate their own over-engineered versions.

The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as select dropdowns, checkboxes, radio buttons, and date/color pickers.

Trying to stop developers from styling checkboxes and radio buttons is like trying to stop teenagers from having sex. You might as well accept that it���s going to happen and give them contraception so they can at least do it safely.

So I welcome this new CSS condom.

You can see accent-color in action in this demo. Change the value of the accent-color property to see the form fields update:

:root { accent-color: rebeccapurple;}

Applying it at the document level like that will make it universal, but you can also use the property on an element-by-element basis using whatever selector you want.

That demo works in Chrome and Edge 93, the current release. It also works in Firefox 92, which literally just landed (like as I was writing this blog post, support for accent-color magically arrived!).

As for Safari, well, who knows? If Apple published a roadmap, then developers would have a clue when to expect a property like this to land. But we mere mortals cannot be trusted with such important hush-hush information.

In the meantime, keep an eye on Can I Use. And lack of support on one browser is no reason not to use accent-color anyway. It���s a progressive enhancement. Add it to your CSS today and it will work in more browsers in the future.