A cute walkthrough for flexbox and grid.
Friday, March 6th, 2020
Tuesday, March 3rd, 2020
Telling the story of performance
At Clearleft, we’ve worked with quite a few clients on site redesigns. It’s always a fascinating process, particularly in the discovery phase. There’s that excitement of figuring out what’s currently working, what’s not working, and what’s missing completely.
The bulk of this early research phase is spent diving into the current offering. But it’s also the perfect time to do some competitor analysis—especially if we want some answers to the “what’s missing?” question.
It’s not all about missing features though. Execution is equally important. Our clients want to know how their users’ experience shapes up compared to the competition. And when it comes to user experience, performance is a huge factor. As Andy says, performance is a UX problem.
There’s no shortage of great tools out there for measuring (and monitoring) performance metrics, but they’re mostly aimed at developers. Quite rightly. Developers are the ones who can solve most performance issues. But that does make the tools somewhat impenetrable if you don’t speak the language of “time to first byte” and “first contentful paint”.
When we’re trying to show our clients the performance of their site—or their competitors—we need to tell a story.
Web Page Test is a terrific tool for measuring performance. It can also be used as a story-telling tool.
You can go to webpagetest.org/easy if you don’t need to tweak settings much beyond the typical site visit (slow 3G on mobile). Pop in your client’s URL and, when the test is done, you get a valuable but impenetrable waterfall chart. It’s not exactly the kind of thing I’d want to present to a client.
Fortunately there’s an attention-grabbing output from each test: video. Download the video of your client’s site loading. Then repeat the test with the URL of a competitor. Download that video too. Repeat for as many competitor URLs as you think appropriate.
Now take those videos and play them side by side. Presentation software like Keynote is perfect for showing multiple videos like this.
This is so much more effective than showing a table of numbers! Clients get to really feel the performance difference between their site and their competitors.
Running all those tests can take time though. But there are some other tools out there that can give a quick dose of performance information.
SpeedCurve recently unveiled Page Speed Benchmarks. You can compare the performance of sites within a particualar sector like travel, retail, or finance. By default, you’ll get a filmstrip view of all the sites loading side by side. Click through on each one and you can get the video too. It might take a little while to gather all those videos, but it’s quicker than using Web Page Test directly. And it might be that the filmstrip view is impactful enough for telling your performance story.
If, during your discovery phase, you find that performance is being badly affected by third-party scripts, you’ll need some way to communicate that. Request Map Generator is fantastic for telling that story in a striking visual way. Pop the URL in there and then take a screenshot of the resulting visualisation.
The beginning of a redesign project is also the time to take stock of current performance metrics so that you can compare the numbers after your redesign launches. Crux.run is really great for tracking performance over time. You won’t get any videos but you will get some very appealing charts and graphs.
Web Page Test, Page Speed Benchmarks, and Request Map Generator are great for telling the story of what’s happening with performance right now—Crux.run balances that with the story of performance over time.
Measuring performance is important. Communicating the story of performance is equally important.
I can see this coming in very handy at Codebar—pop any CSS selector in here and get a plain English explanation of what it’s doing.
Garrett’s observation is spot-on here:
Well, this is a grim collection from Dave:
There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.
It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”
Friday, February 28th, 2020
Some solid research here. Turns out that using
input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using
The headline begs the question, but Robin makes this very insightful observation in the article itself:
How and when did I get to the point where I would consider a page weight of 4 MB on a large page and 500 KB on a small page normal?
This isn’t just a well-earned rant from Manuel. I mean, it *is that, but it’s also packed with practical performance advice.
I don’t understand what currying is, but Trys points out a really interesting thing about custom properties in CSS:
The value after the : in the CSS custom property does not have to be valid CSS.
That means you can use custom properties to store arbitrary strings of text, which can then be combined within a
calc() function, at which point they get evaluated.
I didn’t know about
scroll-margin-top! I wonder if you could apply a universal rule …like, say you’ve got a fixed header that’s
2em in height, couldn’t you declare:
Tuesday, February 25th, 2020
I love, love, love this encounter that Stephanie had with high school students when she showed them her own website (“Your website? You have a website?”).
I opened the DevTools on my site and there was an audible gasp from the class and excited murmuring.
“That’s your code?” A student asked. “Yes, that’s all my code!” “You wrote all of that?!” “Yes, it’s my website.”
And the class kind of exploded and starting talking amongst themselves. I was floored and my perspective readjusted.
When I code, it’s usually in HTML and CSS, and I suppose there’s a part of me that feels like that isn’t special because some tech bros decide to be vocal and loud about HTML and CSS not being special nearly everyday (it is special and tech bros can shut up.)
And the response from that class of high school students delighted me and grounded me in a way I haven’t experienced before. What I view as a simple code was absolute magic to them. And for all of us who code, I think we forget it is magic. Computational magic but still magic. HTML and CSS are magic.
Yes! Yes! Yes!
Monday, February 24th, 2020
Pages are often designed so that they’re hard or impossible to read if some dependency fails to load. On a slow connection, it’s quite common for at least one depedency to fail.
Fire up Reader Mode and read this excellent article informed by data from using a typically slow connection in rural USA today. Two findings are:
- A large fraction of the web is unusable on a bad connection. Even on a good (0% packetloss, no ping spike) dialup connection, some sites won’t load.
- Some sites will use a lot of data!
Jen kicked off a fascinating thread here:
It’s come up quite a few times recently that the world of people who make websites would greatly benefit from the CSS Working Group officially defining ”CSS 4”, and later “CSS 5“, etc.
The level is discourse is impressively smart and civil.
Personally, I don’t (yet) have an opinion on this either way, but I’ll be watching it unfold with keen interest.
Thursday, February 20th, 2020
Monica shares the little snippet of handy CSS she uses at the start of any project.
Tuesday, February 18th, 2020
Elegantly scale type and space without breakpoints.
I may well be biased, but I really like this project. I’ve been asking myself why I find it so appealing. Here are a few of the attributes of Utopia that strike a chord with me…
Collaboration is at the heart of Clearleft’s work. I know everyone says that, but we’ve definitely seen a direct correlation: projects with high levels of collaboration are invariably more successful than projects where people are siloed.
The genesis for Utopia came about after Trys and James worked together on a few different projects. It’s all too easy to let design and development splinter off into their own caves, but on these projects, Trys and James were working (literally) side by side. This meant that they could easily articulate frustrations to one another, and more important, they could easily share their excitement.
The end result of their collaboration is some very clever code. There’s an irony here. This code could be used to discourage collaboration! After all, why would designers and developers sit down together if they can just pass these numbers back and forth?
But I don’t think that Utopia will appeal to designers and developers who work in that way. Born in the spirit of collaboration, I suspect that it will mostly benefit people who value collaboration.
If you’re a control freak, you may not like Utopia. The idea is that you specify the boundaries of what you’re trying to accomplish—minimum/maximum font sizes, minumum/maximum screen sizes, and some modular scales. Then you let the code—and the browser—do all the work.
On the one hand, this feels like surrending control. But on the other hand, because the underlying system is so robust, it’s a way of guaranteeing quality, even in situations you haven’t accounted for.
If someone asks you, “What size will the body copy be when the viewport is 850 pixels wide?”, your answer would have to be “I don’t know …but I do know that it will be appropriate.”
Employing algorithmic layout design means doing away with
@mediabreakpoints, “magic numbers”, and other hacks, to create context-independent layout components. Your future design systems will be more consistent, terser in code, and more malleable in the hands of your users and their devices.
See how breakpoints are mentioned as being a very top-down approach to layout? Remember the tagline for Utopia, which aims for fluid responsive design?
Elegantly scale type and space without breakpoints.
Unsurprisingly, Andy really likes Utopia:
As the co-author of Every Layout, my head nearly fell off from all of the nodding when reading this because this is the exact sort of approach that we preach: setting some rules and letting the browser do the rest.
Heydon describes this mindset as automating intent. I really like that. I think that’s what Utopia does too.
Be your browser’s mentor, not its micromanager.
The idea is that you give it rules, you give it axioms or principles to work on, and you let it do the calculation. You work with the in-built algorithms of the browser and of CSS itself.
This is all possible thanks to improvements to CSS like
calc, flexbox and grid. Jen calls this approach intrinsic web design. Last year, I liveblogged her excellent talk at An Event Apart called Designing Intrinsic Layouts.
Utopia feels like it has the same mindset as algorithmic layout design and intrinsic web design. Trys and James are building on the great work already out there, which brings me to the final property of Utopia that appeals to me…
I’m a great believer in the HTML design principle, Evolution Not Revolution:
It is better to evolve an existing design rather than throwing it away.
Then there’s the idea of typography being fluid and responsive—just like Jason Pamental has been speaking and writing about.
Utopia takes these building blocks and combines them. So if you’re wondering if it would be a good tool for one of your projects, you can take an equally iterative approach by asking some questions…
Are you using fluid type?
Do your font-sizes increase in proportion to the width of the viewport? I don’t mean in sudden jumps with
@media breakpoints—I mean some kind of relationship between font size and the
vw (viewport width) unit. If so, you’re probably using some kind of mechanism to cap the minimum and maximum font sizes—CSS locks.
I’m using that technique on Resilient Web Design. But I’m not changing the relative difference between different sized elements—body copy, headings, etc.—as the screen size changes.
Are you using modular scales?
Does your type system have some kind of ratio that describes the increase in type sizes? You probably have more than one ratio (unlike Resilient Web Design). The ratio for small screens should probably be smaller than the ratio for big screens. But rather than jump from one ratio to another at an arbitrary breakpoint, Utopia allows the ratio to be fluid.
So it’s not just that font sizes are increasing as the screen gets larger; the comparative difference is also subtly changing. That means there’s never a sudden jump in font size at any time.
Are you using custom properties?
A technical detail this, but the magic of Utopia relies on two powerful CSS features:
calc() and custom properties. These two workhorses are used by Utopia to generate some CSS that you can stick at the start of your stylesheet. If you ever need to make changes, all the parameters are defined at the top of the code block. Tweak those numbers and watch everything cascade.
You’ll see that there’s one—and only one—media query in there. This is quite clever. Usually with CSS locks, you’d need to have a media query for every different font size in order to cap its growth at the maximum screen size. With Utopia, the maximum screen size—
100vw—is abstracted into a variable (a custom property). The media query then changes its value to be the upper end of your CSS lock. So it doesn’t matter how many different font sizes you’re setting: because they all use that custom property, one single media query takes care of capping the growth of every font size declaration.
If you’re already using CSS locks, modular scales, and custom properties, Utopia is almost certainly going to be a good fit for you.
If you’re not yet using those techniques, but you’d like to, I highly recommend using Utopia on your next project.
Saturday, February 15th, 2020
Like a little mini CSS Zen Garden, here’s one compenent styled five very different ways.
Crucially, the order of the markup doesn’t consider the appearance—it’s concerned purely with what makes sense semantically. And now with CSS grid, elements can be rearranged regardless of source order.
CSS is powerful and capable of doing amazingly beautiful things. Let’s embrace that and keep the HTML semantical instead of adapting it to the need of the next design change.
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.
- Wrong: web workers will take over the world
- Wrong: Safari is the new IE
- Right: developer experience is trumping user experience
- Right: I’m better off without a Twitter account
- Right: the cost of small modules
- Mixed: progressive enhancement isn’t dead, but it smells funny
Maybe I should do one of these.
Friday, February 14th, 2020
Chris takes two side-by-side deep dives; one into the
a element, the other into the
Even if you think you already know those elements well, I bet there’ll be something new here for you. Like, did you know that the
button element can have form over-riding attributes like
A great explanation of