The Size of Space
Celestial objects ordered by size, covering a scale from one astronaut to the observable universe.
5th | 10th | 15th | 20th | 25th | 30th | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
12am | ||||||||||||||||||||||||||||||
4am | ||||||||||||||||||||||||||||||
8am | ||||||||||||||||||||||||||||||
12pm | ||||||||||||||||||||||||||||||
4pm | ||||||||||||||||||||||||||||||
8pm |
Celestial objects ordered by size, covering a scale from one astronaut to the observable universe.
Lynn gives a step-by-step walkthrough of the latest amazing redesign of her website. There’s so much joy and craft in here, with real attention to detail—I love it!
The opening of this blog post warned the cockles of my heart:
I have a rule about conferences: go once.
Like all rules, it can be broken — usually when Jeremy Keith is involved — but not often.
Awww! That’s so nice!
This is such a great way to explain a technology! Chris talks through his thought process when using flexbox for layout.
I’ve signed this letter.
This is an interesting comparison: design systems as APIs. It makes sense. A design system—like an API—is a contract. Also, an API without documentation is of little use …much like a design system without documentation.
Here’s a nice little test for the file size of your web pages—could they fit on a floppy disk?
The Session fits comfortably and adactio.com just about scrapes by.
On the internet, everything can appear equally legitimate. Breitbart resembles the BBC. The fictitious Protocols of the Elders of Zion look as valid as an ADL report. And the rantings of a lunatic seem as credible as the findings of a Nobel Prize winner. We have lost, it seems, a shared sense of the basic facts upon which democracy depends.
A series of really nice CSS grid demos based on two-page magazine spreads.
Aaron outlines some sensible strategies for serving up images, including using the Cache API from your service worker script.
Supporting Internet Explorer 11 doesn’t mean you need to give it the same experience as a modern browser:
Making sure (some of) your code works in older browsers, does not mean all functionality has to work everywhere. But, mind you, ninety percent of web development means putting text and images in boxes.
And to be honest, there is no reason to not enable this everywhere. Same for form submissions. Make it boring. Make it solid. And sprinkle delight on it.
I know the anxiety of sharing something with the world. I know there is a pressure to match the quality we see elsewhere on the web. But maybe we should stop trying to live up to somebody else’s standards and focus on just getting stuff out there instead. Maybe our “imperfect” things are already helpful to someone. Maybe this shouldn’t be so hard.
Amnesty International have released a PDF report on the out-of-control surveillance perpetrated by Google and Facebook:
Google and Facebook’s platforms come at a systemic cost. The companies’ surveillance-based business model forces people to make a Faustian bargain, whereby they are only able to enjoy their human rights online by submitting to a system predicated on human rights abuse. Firstly, an assault on the right to privacy on an unprecedented scale, and then a series of knock-on effects that pose a serious risk to a range of other rights, from freedom of expression and opinion, to freedom of thought and the right to non-discrimination.
However…
This page on the Amnesty International website has six tracking scripts. Also, consent to accept tracking cookies is assumed (check dev tools). It looks like you can reject marketing cookies, but I tried that without any success.
The stone PDF has been thrown from a very badly-performing glass house.
Frank is redesigning in the open. Watch this space:
By writing about it, it may help both of us. I can further develop my methods by navigating the friction of explaining them. I’ve been looking for a way to clarify and share my thoughts about typography and layout on screens, and this seems like a good chance to do so. And you? Well, perhaps the site can offer a clearly explained way of working that’s worth considering. That seems to be a rare thing on the web these days.
This is a fascinating way to present a code tutorial! It reminds of Tim’s Tutorial Markdown that I linked to a while back (which in turn reminds me of Bret Victor’s work).
I’m really enjoying this end-of-the-year round-up from people speaking their brains. It’s not over yet, but there’s already a lot of thoughtful stuff to read through.
There are optimistic hopeful thoughts from Sam and from Ire:
Only a few years ago, I would need a whole team of developers to accomplish what can now be done with just a few amazing tools.
And I like this zinger from Geoff:
HTML, CSS, and JavaScript: it’s still the best cocktail in town.
Then there are more cautious prognostications from Dave and from Robin:
The true beauty of web design is that you can pick up HTML, CSS, and the basics of JavaScript within a dedicated week or two. But over the past year, I’ve come to the conclusion that building a truly great website doesn’t require much skill and it certainly doesn’t require years to figure out how to perform the coding equivalent of a backflip.
What you need to build a great website is restraint.
A very handy web component from Paul—this works exactly like a regular YouTube embed, but is much more performant.
The fat JavaScript stacks-du-jour have a lot of appeal. They promise you to be able to do more with less. But what if I want to do less?
This is a terrific little (free!) online book all about modest JavaScript. The second part has practical code, but it’s the first part—all about the principles of staying lean—that really resonates with me.
Don’t build more JS than you can maintain over the long term. If you’re going to be building something for a long time, make sure what you are building will grow with you. Make sure you don’t depend on other people’s work too much, lest you want to keep refactoring your code when the framework you picked goes out of style.
This is a fascinating project from Github, the Long Now Foundation, the Internet Archive, the Bodleian Library and others. All of the public code on Github on February 2nd, 2020 will be archived for 1000 years in a vault in Svalbard.
Mind you, given the amount of dependencies that most “modern” code projects rely on, I can’t foresee the code working after 1000 days.
These are great photos of the speakers at Beyond Tellerrand—great captures of Sharon, Cassie, and Charlotte.
Let us not overlook the fact that a semantic HTML web site is inherently accessible by default. When we bend the web to our will, we break that. So we have a responsibility to correct it. Sure the new technologies are neat, but the end result is usually garbage. This all requires some next-level narcissism that our goals and priorities as developers are far more important than that of the audience we’re theoretically building software to serve.
A good overview of the unfair playing field of web browsers, dominated by the monopolistic practices by Google and Apple.
Mozilla is no longer fighting for market share of its browser: it is fighting for the future of the web.
I think these are great habit-forming ideas for any web designer or developer: a day without using your mouse; a day with your display set to grayscale; a day spent using a different web browser; a day with your internet connection throttled. I’m going to try these!
This chimes nicely with my recent post on third-party scripts. Here, Jeremy treats third-party JavaScript at technical debt and outlines some solutions to staying on top of it.
Convenience always has a price, and the web is wracked by our collective preference for it. JavaScript, in particular, is employed in a way that suggests a rapidly increasing tendency to outsource whatever it is that We (the first party) don’t want to do. At times, this is a necessary decision; it makes perfect financial and operational sense in many situations.
But make no mistake, third-party JavaScript is never cheap. It’s a devil’s bargain where vendors seduce you with solutions to your problem, yet conveniently fail to remind you that you have little to no control over the side effects that solution introduces.
A biblical short story from Adam Roberts.
An interesting project that will research and document the language used across different design systems to name similar components.
This would be a fascinating experiment to run in Firefox nightly! This is in response to that post I wrote about third-party scripts.
(It’s fascinating to see how different this response is to the responses from people working at Google.)
The benchmarks that advertising companies use — intended to measure the number of clicks, sales and downloads that occur after an ad is viewed — are fundamentally misleading. None of these benchmarks distinguish between the selection effect (clicks, purchases and downloads that are happening anyway) and the advertising effect (clicks, purchases and downloads that would not have happened without ads).
It gets worse: the brightest minds of this generation are creating algorithms which only increase the effects of selection.
A terrificly well-written piece on the emperor’s new clothes worn by online advertising. Equal parts economic rigour and Gladwellian anecdata, it’s a joy to read! Kudos to Alana Gillespie for the great translation work (the original article was written in Dutch).
We currently assume that advertising companies always benefit from more data. … But the majority of advertising companies feed their complex algorithms silos full of data even though the practice never delivers the desired result. In the worst case, all that invasion of privacy can even lead to targeting the wrong group of people.
This insight is conspicuously absent from the debate about online privacy. At the moment, we don’t even know whether all this privacy violation works as advertised.
The interaction design of this article is great too—annotations, charts, and more!
Here are the slides from my opening keynote at Beyond Tellarrand on Thursday. They don’t make much sense out of context.
How cool is this!!?
Tom took one of the core ideas from my talk at Beyond Tellerrand and turned it into this animated CodePen!
Thanks to the quick work of Marc and his team, the talk I gave at Beyond Tellerrand on Thursday was online within hours!
I’m really pleased with how this turned out. I wasn’t sure if anybody was going to be interested in the deep dive into history that I took for the first 15 or 20 minutes, but lots of people told me that they really enjoyed that part, so that makes me happy.
The Web is smothering in useless images. These clichéd, stock images communicate absolutely nothing of value, interest or use. They are one of the worst forms of digital pollution because they take up space on the page, forcing more useful content out of sight. They also slow down the site’s ability to download quickly.
It’s nice to see that the Chrome browser will add interface enhancements to show whether you can expect a site to load fast or slowly.
Just a shame that the Google search team aren’t doing this kind of badging …unless you’ve given up on your website and decided to use Google AMP instead.
Maybe the Chrome team can figure out what the AMP team are doing to get such preferential treatment from the search team.
The slides from Laura’s excellent talk at FF Conf on Friday.
Here, then, is my speculation. Work is something we struggle to get and strive to keep. We love-hate it (usually not in equal measure). Sometimes it seems meaningless. I’m told this is the case even for surgeons, teachers and disaster-relief workers: those with jobs whose worth seems indisputable. For the mere facilitators, the obscure cogs in the machinery of the modern economy whose precise function and value it takes some effort to ascertain, the meaning in what we do often seems particularly elusive (I should know). I contend, however, that while our lives need to be meaningful, our work does not; it only has to be honest and useful. And if someone is voluntarily paying you to do something, it’s probably useful at least to them.
It’s time for a look at the state of the web when it comes to JavaScript usage. Here’s the report powered by data from HTTP Archive:
JavaScript is the most costly resource we send to browsers; having to be downloaded, parsed, compiled, and finally executed. Although browsers have significantly decreased the time it takes to parse and compile scripts, download and execution have become the most expensive stages when JavaScript is processed by a web page.
Sending smaller JavaScript bundles to the browser is the best way to reduce download times, and in turn improve page performance. But how much JavaScript do we really use?
When it comes to frameworks and UI libraries, there are some interesting numbers. Given the volume of chatter in the dev world, you’d be forgiven for thinking that React is used on the majority of websites today. The real number? 4.6% of websites. That’s less than the number of websites using CSS custom properties.
This is reminding me of what I wrote about dev perception.
Worlds of scarcity are made out of things. Worlds of abundance are made out of dependencies. That’s the software playbook: find a system made of costly, redundant objects; and rearrange it into a fast, frictionless system made of logical dependencies. The delta in performance is irresistible, and dependencies are a compelling building block: they seem like just a piece of logic, with no cost and no friction. But they absolutely have a cost: the cost is complexity, outsourced agency, and brittleness. The cost of ownership is up front and visible; the cost of access is back-dated and hidden.
Timelines of people, interfaces, technologies and more:
30 years of facts about the World Wide Web.
This looks like a nice way to get a blog up and running:
Blot turns a folder into a blog. Drag-and-drop files inside to publish. Images, text files, Word Documents, Markdown and more become blog posts automatically.
I really like the work that IF are doing to document patterns around handling data:
- Signing in to a service
- Giving and removing consent
- Giving access to data
- Getting access to data
- Understanding automated decisions
- Doing security checks
Each pattern has a description, advantages, limitations, and examples.
Nolan writes up what he learned making accessibiity improvements to a single page app. The two big takeways involve letting the browser do the work for you:
Here’s the best piece of accessibility advice for newbies: if something is a button, make it a
<button>
. If something is an input, make it an<input>
. Don’t try to reinvent everything from scratch using<div>
s and<span>
s.
And then there are all the issues that crop up when you take over the task of handling navigations:
- You need to manage focus yourself.
- You need to manage scroll position yourself.
For classic server-rendered pages, most browser engines give you this functionality for free. You don’t have to code anything. But in an SPA, since you’re overriding the normal navigation behavior, you have to handle the focus yourself.
Craig compares and contrasts books to “attention monsters”:
That is, any app / service / publication whose business is predicated on keeping a consumer engaged and re-engaged for the benefit of the organization (often to the detriment of the mental and physical health of the user), dozens if not hundreds or thousands of times a day.
A counterpart to the piece by Baldur that I linked to yesterday:
There are many challenges to face as the web grows.
Most of them are people problems. Habits. Inertia. A misalignment of priorities with user needs. Those can be overcome.
The title sounds clickbaity, but this is a thoughtful list of project ideas from Chris (partly prompted by the way other lists seem to involve nothing but JavaScript frameworks).
This isn’t a “the web is doomed, DOOMED, I tells ya” kind of blog post. It’s more in the “the web in its current form isn’t sustainable and will collapse into a simpler, more sustainable form, possibly several” genre.
Baldur points to the multiple causes of the web’s current quagmire.
I honestly have no idea on how to mitigate this harm or even how long the decline is going to take. My hope is that if we can make the less complex, more distributed aspects of the web safer and more robust, they will be more likely to thrive when the situation has forced the web as a whole to break up and simplify.
It’s not a matter of if your users don’t have JavaScript—it’s a matter of when and how often.
The answer to that is around 1% of the time.
If you had an application bug which occurred 1% of the time, you’d fix it. No team I’ve come across would put up with that level of reliability.
The same goes for JavaScript. It’s not about people who turn it off. It’s about the nature of the web itself.
Testing on a <$100 Android device on a 3G network should be an integral part of testing your website. Not everyone is on a brand-new device or upgrades often, especially with the price point of a high-end phones these days.
When we design and build our websites with the outliers in mind, whether it’s for performance or even user experience, we build an experience that can be easy for all to access and use — and that’s what the web is about, access and information for all.