I quite like this change of terminology when it comes to making fast websites. After all, performance can sound like a process of addition, whereas efficiency can be a process of subtraction.
The term ‘performance’ brings to mind exotic super-cars suitable only for impractical demonstrations (or ‘performances’). ‘Efficiency’ brings to mind an electric car (or even better, a bicycle), making effective use of limited resources.
I did not know about box-decoration-break—sounds like a game-changer for text effects that wrap onto multiple lines.
Checked in at Jolly Brewer. Wednesday night session 🎶🎻☘️ — with Jessica
Targeted advertising based on online behavior doesn’t just hurt privacy. It also contributes to a range of other harms.
I very much agree with this call to action from the EFF.
Maybe we can finally get away from the ludicrious idea that behavioural advertising is the only possible form of effective advertising. It’s simply not true.
Checked in at Allen Gardens. Playing with Cider — with Jessica
Following on from the piece they ran called Google’s FLoC Is a Terrible Idea, the EFF now have the details of the origin trial and it’s even worse than what was originally planned.
I strongly encourage you to use a privacy-preserving browser like Firefox or Safari.
A handy tool for getting an overview of your site’s CSS:
CSS Stats provides analytics and visualizations for your stylesheets. This information can be used to improve consistency in your design, track performance of your app, and diagnose complex areas before it snowballs out of control.
I posted something recently that I think might be categorised as a “shitpost”:
Most single page apps are just giant carousels.
Extreme, yes, but perhaps there’s a nugget of truth to it. And it seemed to resonate:
I’ve never actually seen anybody justify SPA transitions with actual business data. They generally don’t seem to increase sales, conversion, or retention.
For some reason, for SPAs, managers are all of a sudden allowed to make purely emotional arguments: “it feels snappier”
If businesses were run rationally, when somebody asks for an order of magnitude increase in project complexity, the onus would be on them to prove that it proportionally improves business results.
But I’ve never actually seen that happen in a software business.
A single page app architecture makes a lot of sense for interaction-heavy sites with lots of state to maintain, like twitter.com. But I’ve seen plenty of sites built as single page apps even though there’s little to no interactivity or state management. For some people, it’s the default way of building anything on the web, even a brochureware site.
It seems like there’s a consensus that single page apps may have long initial loading times, but then they have quick transitions between “pages” …just like a carousel really. But I don’t know if that consensus is based on reality. Whether you’re loading a page of HTML or loading a chunk of JSON, you’re still making a network request that will take time to resolve.
The argument for loading a chunk of JSON is that you don’t have to make any requests for the associated CSS and JavaScript—they’re already loaded. Whereas if you request a page of HTML, that HTML will also request CSS and JavaScript.
Leaving aside the fact that is literally what the browser cache takes of, I’ve seen some circular reasoning around this:
To be fair, in the past, the experience of going from page to page used to feel a little herky-jerky, even if the response times were quick. You’d get a flash of a white blank page between navigations. But that’s no longer the case. Browsers now perform something called “paint holding” which elimates the herky-jerkiness.
So now if your pages are a reasonable size, there’s no practical difference in user experience between full page refreshes and single page app updates. Navigate around The Session if you want to see paint holding in action. Switching to a single page app architecture wouldn’t improve the user experience one jot.
Except…
If I were controlling everything with JavaScript, then I’d also have control over how to transition between the “pages” (or carousel items, if you prefer). There’s currently no way to do that with full page changes.
This is the problem that Jake set out to address in his proposal for navigation transitions a few years back:
Having to reimplement navigation for a simple transition is a bit much, often leading developers to use large frameworks where they could otherwise be avoided. This proposal provides a low-level way to create transitions while maintaining regular browser navigation.
I love this proposal. It focuses on user needs. It also asks why people reach for JavaScript frameworks instead of using what browsers provide. People reach for JavaScript frameworks because browsers don’t yet provide some functionality: components like tabs or accordions; DOM diffing; control over styling complex form elements; navigation transitions. The problems that JavaScript frameworks are solving today should be seen as the R&D departments for web standards of tomorrow. (And conversely, I strongly believe that the aim of any good JavaScript framework should be to make itself redundant.)
I linked to Jake’s excellent proposal in my shitpost saying:
bucketloads of JavaScript wouldn’t be needed if navigation transitions were available in browsers
But then I added—and I almost didn’t—this:
(not portals)
Now you might be asking yourself what Paul said out loud:
Excuse my ignorance but… WTF are portals!?
I replied with a link to the portals proposal and what I thought was an example use case:
Portals are a proposal from Google that would help their AMP use case (it would allow a web page to be pre-rendered, kind of like an iframe).
That was based on my reading of the proposal:
…show another page as an inset, and then activate it to perform a seamless transition to a new state, where the formerly-inset page becomes the top-level document.
It sounded like Google’s top stories carousel. And the proposal goes into a lot of detail around managing cross-origin requests. Again, that strikes me as something that would be more useful for a search engine than a single page app.
But Jake was not happy with my description. I didn’t intend to besmirch portals by mentioning Google AMP in the same sentence, but I can see how the transitive property of ickiness would apply. Because Google AMP is a nasty monopolistic project that harms the web and is an embarrassment to many open web advocates within Google, drawing any kind of comparison to AMP is kind of like Godwin’s Law for web stuff. I know that makes it sounds like I’m comparing Google AMP to Hitler, and just to be clear, I’m not (though I have myself been called a fascist by one of the lead engineers on AMP).
Clearly, emotions run high when Google AMP is involved. I regret summoning its demonic presence.
After chatting with Jake some more, I tried to find a better use case to describe portals. Reading the proposal, portals sound a lot like “spicy iframes”. So here’s a different use case that I ran past Jake: say you’re on a website that has an iframe embedded in it—like a YouTube video, for example. With portals, you’d have the ability to transition the iframe to a fully-fledged page smoothly.
But Jake told me that even though the proposal talks a lot about iframes and cross-origin security, portals are conceptually more like using rel="prerender" …but then having scripting control over how the pre-rendered page becomes the current page.
Put like that, portals sound more like Jake’s original navigation transitions proposal. But I have to say, I never would’ve understood that use case just from reading the portals proposal. I get that the proposal is aimed more at implementators than authors, but in its current form, it doesn’t seem to address the use case of single page apps.
we haven’t seen interest from SPA folks in portals so far.
I’m not surprised! He goes on:
Maybe, they are happy / benefits aren’t clear yet.
From my own reading of the portals proposal, I think the benefits are definitely not clear. It’s almost like the opposite of Jake’s original proposal for navigation transitions. Whereas as that was grounded in user needs and real-world examples, the portals proposal seems to have jumped to the intricacies of implementation without covering the user needs.
Don’t get me wrong: if portals somehow end up leading to a solution more like Jake’s navigation transitions proposals, then I’m all for that. That’s the end result I care about. I’d love it if people had a lightweight option for getting the perceived benefits of single page apps without the costly overhead in performance that comes with JavaScripting all the things.
I guess the web I want includes giant carousels.
These wonderfully realistic photo effects from Lynn are quite lovely!
This is a very nifty use of CSS gradients!
Human consciousness is the most astonishing thing, and most of it happened in deep time, beyond the reach of any writing and most legends. Human experience, in general, is prehistoric. And prehistoric experience was just as full as yours and mine: just as deeply felt, just as intelligent, just as real. What we know of it is mostly from durable artifacts and graves. I’m thinking of the woman found near the Snake River, buried at the end of the ice age with a perfectly crafted and unused stone knife tucked under her head. I’m thinking of the huge conical hats, beaten from single pieces of gold and inscribed with calendars, found north of the Alps. I’m thinking of Grave 8 at Vedbæk, where a woman held her premature baby on the spread wing of a swan. These are snapshot that experts can assemble into larger ideas, but what they tell all of us is that we’ve been people, not just humans, for a very long time.
I’ve really come to appreciate that performance isn’t just some property of a tool independent from its functionality or its feature set. Performance — in particular, being notably fast — is a feature in and of its own right, which fundamentally alters how a tool is used and perceived.
This is a fascinating look into how performance has knock-on effects beyond the obvious:
It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower.
What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task.
This observation is particularly salient for web developers:
We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.
I want to deliver working, stable things. To do that, we need to understand what we are building, in and out, and that’s impossible to do in bloated, over-engineered systems.
This pairs nicely with Craig’s post on fast software.
Everyone is busy building stuff for right now, today, rarely for tomorrow. But it would be nice to also have stuff that lasts a little longer than that.
I just got a new laptop and I decided to go with fresh installs rather than a migration. This really resonates:
It just seems that nobody is interested in building quality, fast, efficient, lasting, foundational stuff anymore. Even when efficient solutions have been known for ages, we still struggle with the same problems: package management, build systems, compilers, language design, IDEs.
Checked in at Sandy Bell’s. Listening to tunes — with Jessica
A case study from Twitter on the benefits of using a design system:
With component-based design, development becomes an act of composition, rather than constantly reinventing the wheel.
I think that could be boiled down to this:
Component-based design favours composition over invention.
I’m not saying that’s good. I’m not saying that’s bad. I’m also not saying it’s neutral.
Checked in at The Skiff. Codebar monthly
Effects pedals in the browser, using the Web Audio API. Very cool!
Be sure to read Trys’s write-up too.
Well, the clever CSS techniques just keep on comin’ from Trys—I’m learning so much from him!
While the Interaction 19 event was a bit of a mixed bag overall, there were some standout speakers.
Marty Neumeier was unsurprisingly excellent. I’d seen him speak before, at UX London a few years back, so I knew he’d be good. He has a very reassuring, avuncular manner when he’s speaking. You know the way that there are some people you could just listen to all day? He’s one of those.
Marty’s talk at Interaction 19 was particularly interesting because it was about his new book. Now, why would that be of particular interest? Well, this new book—Scramble—is a business book, but it’s written in the style of a thriller. He wanted it to be like one of those airport books that people read as a guilty pleasure.
One rainy night in December, young CEO David Stone is inexplicably called back to the office. The company’s chairman tells him that the board members have reached the end of their patience. If David can’t produce a viable turnaround plan in five weeks, he’s out of a job. His only hope is to try something new. But what?
I love this idea!
I’ve talked before about borrowing narrative structures from literature and film and applying them to blog posts and conference talks—techniques like flashback, in media res, etc.—so I really like the idea of taking an entire genre and applying it to a technical topic.
The closest I’ve seen is the comic that Scott McCloud wrote for the release of Google Chrome back in 2008. But how about a romantic comedy about service workers? Or a detective novel about CSS grid?
I have a feeling I’ll be thinking about Marty Neumeier’s book next time I’m struggling to put a conference talk together.
In the meantime, if you want to learn from the master storyteller himself, Clearleft are running a two-day Brand Master Workshop with Marty on March 14th and 15th at The Barbican in London. Early bird tickets are on sale until this Thursday, so don’t dilly-dally if you were thinking about nabbing your spot.
I reckon it’s time for distressed type to make a comeback—CSS is ready for it.