I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.
Tuesday, July 6th, 2021
Sunday, March 7th, 2021
I’m very taken with Github’s tab-container element—this is exactly how I think web components should be designed!
Tuesday, December 8th, 2020
Feel bad because your favourite artists aren’t getting any income from Spotify? Here’s a handy tool from Hype Machine that allows you to import Sportify playlists and see where you can support those artists on Bandcamp.
Saturday, November 14th, 2020
I like the way that Simon is liberating his data from silos and making it work for him.
Thursday, November 12th, 2020
- First impressions
- The Tab key
- Automated testing tools
- Screen reader testing
- Next steps
Sunday, November 1st, 2020
Monday, October 19th, 2020
I like this idea for a minimum viable note-taking app:
data:text/html,<body contenteditable style="line-height:1.5;font-size:20px;">
I have added this to bookmarks and now my zero-weight text editor is one keypress away from me. You might also use it as a temporary clipboard to paste text or even pictures.
See also: a minimum viable code editor.
Sunday, September 27th, 2020
The title says it all, really. This is another great piece of writing from Paul Ford.
I’ve noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is. This has been the history of the World Wide Web, for example. Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.
Thursday, August 20th, 2020
Thursday, July 30th, 2020
What web development can learn from the Nintendo Game and Watch.
The Web now consists of an ever-growing number of different frameworks, methodologies, screen sizes, devices, browsers, and connection speeds. “Lateral thinking with withered technology” – progressively enhanced – might actually be an ideal philosophy for building accessible, performant, resilient, and original experiences for a wide audience of users on the Web.
Sunday, July 5th, 2020
Notes on the old internet, its design and frontend.
Thursday, June 25th, 2020
Here then are 10 stories of remaking the future that contain hope — or at least stability.
- The City and the Stars by Arthur C Clarke
- The First Fifteen Lives of Harry August by Claire North
- Revenger by Alastair Reynolds
- Children of Time by Adrian Tchaikovsky
- Do You Dream of Terra-Two? by Temi Oh
- Consider Phlebas by Iain M Banks
- Natural History by Justina Robson
- Ancillary Justice by Ann Leckie
- Way Station by Clifford D Simak
- News from Gardenia by Robert Llewellyn
Wednesday, June 10th, 2020
Smart thinking from Sara to improve usability for keyboard users by using
aria-hidden="true" tabindex="-1" to skip duplicate links:
A good rule of thumb for similar cases is that if you have multiple consecutive links to the same page, there is probably a chance to improve keyboard navigation by skipping some of those links to reduce the number of tab stops to one. The less tab stops, the better, as long as it does not worsen or compromise on other aspects of usability.
I’ve cautiously implemented this pattern now over on The Session where snippets of comments had both a title link and a “more” link going to the same destination.
Friday, May 8th, 2020
Progressive disclosure interface patterns categorised and evaluated:
- mouseover popups (just say no!),
- new pages,
- scrolling sideways.
I really like the hypertext history invoked in this article.
The piece finishes with a great note on the MacNamara fallacy:
Everyone thinks metrics let us measure results. But, actually, they don’t. They measure only what they are measuring. Engagement, for example, is not something that can be measured, so we use an analogue for it. Time on page. Or clicks.
We often end up measuring what is quick, cheap, and easy to measure. Therefore, few organizations regularly conduct usability testing or customer-satisfaction surveys, but lots use analytics.
Even today, organizations often use clicks as a measure of engagement. So, all too often, they design user interfaces to generate clicks, so the system can measure them.
Trys describes the backend architecture of the excellent Sofa Conf website. In short, it’s a Jamstack dream: all of the convenience and familiarity of using a database-driven CMS (Craft), combined with all the speed and resilience of using a static site generator (Eleventy).
I love the fact that anyone on the Clearleft events team can push to production with a Slack message.
I also love that the site is Lighthousetastically fast.
Saturday, February 15th, 2020
Here are the many, many reasons why you should not open links in a new window (or tab).
Regardless of what accessibility conformance level you target, do not arbitrarily open links in a new window or tab. If you are required to do so anyway, inform users in text.
Thursday, December 12th, 2019
Saturday, August 10th, 2019
Harry wrote a really good article all about the performance measurement Time To First Byte. Time To First Byte: What It Is and Why It Matters:
While a good TTFB doesn’t necessarily mean you will have a fast website, a bad TTFB almost certainly guarantees a slow one.
Time To First Byte has been the chink in my armour over at thesession.org, especially on the home page. Every time I ran Lighthouse, or some other performance testing tool, I’d get a high score …with some points deducted for taking too long to get that first byte from the server.
Harry’s proposed solution is to set up some Server Timing headers:
With a little bit of extra work spent implementing the Server Timing API, we can begin to measure and surface intricate timings to the front-end, allowing web developers to identify and debug potential bottlenecks previously obscured from view.
I rememberd that Drew wrote an excellent article on Smashing Magazine last year called Measuring Performance With Server Timing:
The job of Server Timing is not to help you actually time activity on your server. You’ll need to do the timing yourself using whatever toolset your backend platform makes available to you. Rather, the purpose of Server Timing is to specify how those measurements can be communicated to the browser.
He even provides some PHP code, which I was able to take wholesale and drop into the codebase for thesession.org. Then I was able to put start/stop points in my code for measuring how long some operations were taking. Then I could output the results of these measurements into Server Timing headers that I could inspect in the “Network” tab of a browser’s dev tools (Chrome is particularly good for displaying Server Timing, so I used that while I was conducting this experiment).
I started with overall database requests. Sure enough, that was where most of the time in time-to-first-byte was being spent.
Then I got more granular. I put start/stop points around specific database calls. By doing this, I was able to zero in on which operations were particularly costly. Once I had done that, I had to figure out how to make the database calls go faster.
Spoiler: I did it by adding an extra index on one particular table. It’s almost always indexes, in my experience, that make the biggest difference to database performance.
I don’t know why it took me so long to get around to messing with Server Timing headers. It has paid off in spades. I wish I had done it sooner.
Monday, March 18th, 2019
This is a nifty visualisation by Hui Jing. It’s really handy to have elements categorised like this:
- Root elements
- Interactive elements
- Document metadata
- Tabular data
- Grouping content
- Embedded content
- Text-level semantics
Sunday, February 10th, 2019