Plainness and Sweetness – Frank Chimero
I adore the thoughtfulness and lack of ego that Frank presents here. I hope that every designer reads this and thinks upon it.
I adore the thoughtfulness and lack of ego that Frank presents here. I hope that every designer reads this and thinks upon it.
T-5 minutes to ISS flyover.
Joe’s site is very clever …but is it as clever as Jon’s?
Jon’s site is very clever …but is it as clever as Joe’s?
I should do this in the Clearleft kitchen.
This is wonderful meditation on the history of older technologies that degrade in varied conditions versus newer formats that fall of a “digital cliff”, all tied in to working on the web.
When digital TV fails, it fails completely. Analog TV, to use parlance of the web, degrades gracefully. The web could be similar, if we choose to make it so. It could be “the analog” web in contrast to “the digital” platforms. Perhaps in our hurry to replicate and mirror native platforms, we’re forgetting the killer strength of the web: universal accessibility.
Charlotte’s step-by-step account of setting up a Node server is going to be invaluable if and when I get around to dipping my toes in those waters.
Going to Oxford. brb
Building and maintaining an open-source project is hard work. That observation is about as insightful as noting the religious affiliation of the pope or the scatological habits of woodland bears.
Nolan Lawson wrote a lengthy post describing what it feels like to be an open-source maintainer.
Outside your door stands a line of a few hundred people. They are patiently waiting for you to answer their questions, complaints, pull requests, and feature requests.
You want to help all of them, but for now you’re putting it off. Maybe you had a hard day at work, or you’re tired, or you’re just trying to enjoy a weekend with your family and friends.
But if you go to github.com/notifications, there’s a constant reminder of how many people are waiting
Most of the comments on the post are from people saying “Yup, I hear ya!”
Jan wrote a follow-up post called Sustainable Open Source: The Maintainers Perspective or: How I Learned to Stop Caring and Love Open Source:
Just because there are people with problems in front of your door, that doesn’t mean they are your problems. You can choose to make them yours, but you want to be very careful about what to care about.
There’s also help at hand in the shape of Open Source Guides created by Nadia Eghbal:
A collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project.
I’m sure Mark can relate to all of the tales of toil that come with being an open-source project maintainer. He’s been working flat-out on Fractal, sometimes at work, but often at home too.
Fractal isn’t really a Clearleft project, at least not in the same way that something like Silverback or UX London is. We’re sponsoring Fractal as much as we can, but an open-source project doesn’t really belong to anyone; everyone is free to fork it and take it. But I still want to make sure that Mark and Danielle have time at work to contribute to Fractal. It’s hard to balance that with the bill-paying client work though.
I invited Remy around to chat with them last week. It was really valuable. Mind you, Remy was echoing many of the same observations made in Nolan’s post about how draining this can be.
So nobody here is under any illusions that this open-source lark is to be entered into lightly. It can be a gruelling exercise. But then it can also be very, very rewarding. One kind word from somebody using your software can make your day. I was genuinely pleased as punch when Danish agency Shift sent Mark a gift to thank him for all his hard work on Fractal.
People can be pretty darn great (which I guess is an underlying principle of open source).
Monkman vs. Seagull …what a clash of the titans on University Challenge tonight!
Pina Bausch ballet in London during the day, and Ghost In The Shell (the original) in Brighton the same evening—that was a busy Sunday.
A lot has been written about the future of journalism, the importance of businesses like the LA Times being profitable as a way to protect American democracy. I agree with that in theory. But this sort of incompetence and contempt for readers makes me completely uninterested in helping their business.
Like Craig says…
between personal data suction and total disrespect of bandwidth, I'm not sure how you can *not* run ad blockers and browse the web— A Walkin' Dude (@craigmod) March 26, 2017
A ludicrously deep dive by Nolan into how scrolling works in web browsers. No, wait, come back! It’s more interesting than it sounds …and it certainly isn’t as simple as you might think.
For instance, do you know the difference between the following scenarios?
- User scrolls with two fingers on a touch pad
- User scrolls with one finger on a touch screen
- User scrolls with a mouse wheel on a physical mouse
- User clicks the sidebar and drags it up and down
- User presses up, down, PageUp, PageDown, or spacebar keys on a keyboard
If you ask the average web user (or even the average web developer!) they might tell you that these interactions are all equivalent. The truth is far more interesting.
This comes complete with lovely animated illustrations by Rachel.
If we describe patterns also in terms of content, context, and contrast, we are able to define more precisely what a specific pattern is all about, what its role within a design system is, and how it is defined and shaped by its environment.
I’m not a big fan of job titles. I’ve always had trouble defining what I do as a noun—I much prefer verbs (“I make websites” sounds fine, but “website maker” sounds kind of weird).
Mind you, the real issue is not finding the right words to describe what I do, but rather figuring out just what the heck it is that I actually do in the first place.
Instead, I try to make sure that the people doing the actual coding—Mark, Graham, and Danielle—are happy and have everything they need to get on with their work. From outside, it might look like my role is managerial, but I see it as the complete opposite. They’re not in service to me; I’m in service to them. If they’re not happy, I’m not doing my job.
There’s another aspect to this role of technical director, and it’s similar to the role of a creative director. Just as a creative director is responsible for the overall direction and quality of designs being produced, I have an oversight over the quality of front-end output. I don’t want to be a bottleneck in the process though, and to be honest, most of the time I don’t do much checking on the details of what’s being produced because I completely trust Mark, Graham, and Danielle to produce top quality code.
But I feel I should be doing more. Again, it’s not that I want to be a bottleneck where everything needs my approval before it gets delivered, but I hope that I could help improve everyone’s output.
Now the obvious way to do this is with code reviews. I do it a bit, but not nearly as much as I should. And even when I do, I always feel it’s a bit late to be spotting any issues. After all, the code has already been written. Also, who am I to try to review the code produced by people who are demonstrably better at coding than I am?
Instead I think it will be more useful for me to stick my oar in before a line of code has been written; to sit down with someone and talk through how they’re going to approach solving a particular problem, creating a particular pattern, or implementing a particular user story.
I suppose it’s really not that different to rubber ducking. Having someone to talk out loud with about potential solutions can be really valuable in my experience.
So I’m going to start doing more code previews. I think it will also incentivise me to do more code reviews—being involved in the initial discussion of a solution means I’m going to want to see the final result.
But I don’t think this should just apply to front-end code. I’d also like to exercise this role as technical director with the designers on a project.
All too often, decisions are made in the design phase that prove problematic in development. It usually works out okay, but it often means revisiting the designs in light of some technical considerations. I’d like to catch those issues sooner. That means sticking my nose in much earlier in the process, talking through what the designers are planning to do, and keeping an eye out for any potential issues.
So, as technical director, I won’t be giving feedback like “the colour’s not working for me” or “not sure about those type choices” (I’ll leave that to the creative director), but instead I can ask questions like “how will this work without hover?” or “what happens when the user does this?” as well as pointing out solutions that might be tricky or time-consuming to implement from a technical perspective.
What I want to avoid is the swoop’n’poop, when someone seagulls in after something has been designed or built and points out all the problems. The earlier in the process any potential issues can be spotted, the better.
And I think that’s my job.
Steps you can take to secure your phone and computer. This is especially useful in countries where ubiquitous surveillance is not only legal, but mandated by law (such as China, Australia, and the UK).
I know it’s just a landing page for YouTube channel of movie reviews but I really like the art direction and responsiveness of this.
Thinking up marketing taglines for Google:
Accelerated Mobile Pages — “Not just for mobile”
Progressive Web Apps — “Not just for apps”
Funnily enough, I led a brown bag lunch discussion about AMP at work just the other day. A lot of it mirrored Chris’s thoughts here. It’s a complicated situation that has lots of people worried.
It’s a bit finger-pointy but this blog should be useful for anyone working on internationalisation.
This blog has two general aims: to show the fundamental flaws in using flags to represent languages and how to create good experiences when dealing with multilingual and multi-regional content.
That library was a Pandorica of fabulous, interwoven randomness, as rich as plum cake. Push a seed of curiosity in between any two books and it would grow, overnight, into a rainforest hot with monkeys and jaguars and blowpipes and clouds. The room was full, and my head was full. What a magical system to place around a penniless girl.
Chapter 3 of Resilient Web Design, republished in Smashing Magazine:
In the world of web design, we tend to become preoccupied with the here and now. In “Resilient Web Design“, Jeremy Keith emphasizes the importance of learning from the past in order to better prepare ourselves for the future. So, perhaps we should stop and think more beyond our present moment? The following is an excerpt from Jeremy’s web book.
Speaking as an ancient web developer myself, this account by Gina of her journey into Node.js is really insightful. But I can’t help but get exhausted just contemplating the yak-shaving involved in the tooling set-up:
The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.
Turning your existing website into a progressive web “app”—a far more appealing prospect than trying to create an entirely new app-shell architecture:
…they are an enhancement of your existing website which should take no longer than a few hours and have no negative effect on unsupported browsers.
Here’s a crazy idea: threaded tweets, but logged together, on a single webpage. A ‘weblog’, if you will.— Paul Lloyd (@paulrobertlloyd) March 21, 2017
Some people have been putting Paul’s crazy idea into practice.
There are more people I could mention …but, to be honest, not that many more. Seems like most people are happy to only publish on Ev’s blog or not at all.
I know not everybody wants to write on the web, and that’s fine. But it makes me sad when people choose not to publish their thoughts because they think no-one will be interested, or that it’s all been said before. I understand where those worries come from, but I believe—no, I know—that they are unfounded.
It’s a world wide web out there. There’s plenty of room for everyone. And I, for one, love reading the words of others.
Here’s a CSS file that will give you a bit more control over styling some form elements. The thinking behind the CSS for each element is explained nice and clearly.
Incredibly impressive work from the CodePen team—you can now edit entire projects in your web browser …and then deploy them to a live site!
Smörgåsbord Studio created a design system for the Welsh government, including the typeface Cymru Wales Sans from Colophon.
The accompanying video lists the design principles:
- Elevate our status
- Surprise & inspire
- Change perceptions
- Do good things
- Be unmistakably Wales
Everyone in the Fractal Slack channel is currently freaking out about this. Veeeeery iiiiinteresting!
I must confess I briefly nipped out of @CodebarBrighton for a peek at Jupiter.
Pssst! @SlightlyLate, @Owencm, it’s been almost a year—how is this progressing?
When I was in Porto a few weeks back, I took lots of pictures of the beautiful tiles. They reminded me of the ubiquitous repeating background images that were so popular on the early web. I was thinking about abstracting them into a collection of reusable patterns but now it looks like I’ve been beaten to it!
I really need to have a play with this API. I think it could potentially be a useful indie web building block …if the web share target API also gets implemented.
An even thornier problem than the Clock of the Long Now.
A great new site from Heydon:
A blog trying to be a pattern library. Each post explores the design of a robust, accessible interface component.
The first component is a deep dive into toggle buttons.
A new way to enjoy the mother of all demos, organised into sections that you can jump between. This was put together by Douglas Engelbart’s daughter Christina, and Bret Victor.
Two new typefaces, designed to be deliberately lacking in expression.
The write-up of the making of the typefaces is as open and honest as the finished output. This insight into the design process rings very, very true:
Post rationalisation is an open secret in the design industry. Only when a project is finished can it be written up, the messy process is delineated and everything seems to follow a logical sequence up until the final thing is unveiled, spotless and perfect.
However, I suspect the process is largely irrational for most designers. There is a point where all the input has been processed, all the shit drawings, tenuous concepts and small ideas have been thrown away and you just work towards the finish, too exhausted and distracted to even know if it’s worth anything or not. And, if you’re lucky, someone or something will come along and validate the work.
🎵 If there’s something strange, in your neighbourhood’s architectural renders, who you gonna call? 🎵
(I ain’t ‘fraid of no render ghost.)
Time-shifted reports from the Russian revolution, 100 years on.
All the texts used are taken from genuine documents written by historical figures: letters, memoirs, diaries and other documents of the period.
Every day, when you go onto the site, you will find out what happened exactly one hundred years ago: what various people were thinking about and what happened to each of them in this eventful year. You may not fast-forward into the future, but must follow events as they happen in real time.
Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.
If you missed the other parts of this series, they are:
The second part of Bruce’s excellent series begins by focusing on the usage of proxy browsers around the world:
But how!? Well, Bruce has the answer:
I call this amazing new technique “progressive enhancement.”
You heard it here first, folks!
We’ve gone through the invention step. The infrastructure came out of DARPA and the World Wide Web itself came out of CERN.
We’ve gone through the hobbyist step. Everyone now knows what the internet is, and some of the amazing things it’s capable of.
We’ve gone through the commercialization step. Monopolies have emerged, refined, and scaled the internet.
But the question remains: can we break with the tragic history that has befallen all prior information empires? Can this time be different?
The first part of this article is a great history lesson in the style of Tim Wu’s The Master Switch. The second part is a great explanation of net neutrality, why it matters, and how we can fight for it.
If you do nothing, we will lose the war for the open internet. The greatest tool for communication and creativity in human history will fall into the hands of a few powerful corporations and governments.
There’s something very endearing about this docudrama retelling of the story of the web.
Interesting ideas around front-end frameworks:
The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.
Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.
A free ten part email course on web typography for designers and developers. The end results will be gathered together into a book.
After Clearleft’s recent rebranding, I’m really interested in Happy Cog’s redesign process:
In the near future we’ll be rolling out a new website, followed by a rebrand of Cognition, our blog. As the identity is tested against applications, much of what’s here may change. Nothing is set in stone.
Jamie has put his talks online, complete with transcripts:
Google have released this encoder for JPEGs which promises 20-30% smaller file sizes without any perceptible loss of quality.
One of the accessibility features built into OS X:
Using Switch Control, and tapping a small switch with his head, my son tweets, texts, types emails, makes FaceTime calls, operates the TV, studies at university online, runs a video-editing business using Final Cut Pro on his Mac, plays games, listens to music, turns on lights and air-conditioners in the house and even pilots a drone!
Hope is a belief that what we do might matter, an understanding that the future is not yet written.
Rebecca Solnit’s piece reminded me of something I mentioned a couple of year’s back when I referred to Margaret Atwood’s phrase “judicious hope”:
Hope sounds like such a wishy-washy word, like “faith” or “belief”, but it carries with it a seed of resistance. Hope, faith, and belief all carry connotations of optimism, but where faith and belief sound passive, even downright complacent, hope carries the promise of action.
Lá féile Pádraig sona daoibh go léir, a chairde! ☘
An open beta of Smashing Magazine’s redesign, which looks like it could be a real poster child for progressive enhancement:
Yesterday was a good day with Amber. She’s been marking up her CV and it was the perfect opportunity to take a deep dive into HTML.
Many thanks to @SorceressOfFilm for organising last night’s screening of Sunshine in @DukeOfYorks.
It was genuinely awesome.
A website dedicated to one of the most, um, interesting solutions to the Yucca Mountain nuclear waste storage problem:
- Engineer cats that change colour in response to radiation.
- Create the culture/legend/history that if your cat changes colour, you should move some place else.
There are T-shirts!
This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:
- Figure out what [insert tool] does.
- Figure out what sucks right now
- Determine if it’s worth the investment
- Learn it (if it’s worth it)
- Differentiate opinions from facts
Veritably aquiver with excitement at the prospect of watching a 35mm print of Sunshine on the big screen in @DukeOfYorks this evening!
I’m supposed to be writing …so of course I’m rearranging the @Clearleft book shelves instead.
I got a nice email recently from Colin van Eenige. He wrote:
For my graduation project I’m researching the development of Progressive Web Apps and found your offline book called resilient web design. I was very impressed by the implementation of the website and it really was a nice experience.
I’m very interested in your vision on progressive web apps and what capabilities are waiting for us regarding offline content. Would it be fine if I’d send you some questions?
I said that would be fine, although I couldn’t promise a swift response. He sent me four questions. I finally got ‘round to sending my answers…
Well, given the subject matter, it felt right that the canonical version of the book should be not just online, but made with the building blocks of the web. The other formats are all nice to have, but the HTML version feels (to me) like the “real” book.
Interestingly, it wasn’t too much trouble for people to generate other formats from the HTML (ePub, MOBI, PDF), whereas I think trying to go in the other direction would be trickier.
As for the offline part, that felt like a natural fit. I had already done that with a previous book of mine, HTML5 For Web Designers, which I put online a year or two after its print publication. In that case, I used AppCache for the offline functionality. AppCache is horrible, but this use case might be one of the few where it works well: a static book that’s never going to change. Cache invalidation is one of the worst parts of using AppCache so by not having any kinds of updates at all, I dodged that bullet.
But when it came time for Resilient Web Design, a service worker was definitely the right technology. Still, I’ve got AppCache in there as well for the browsers that don’t yet support service workers.
The biggest effect that service workers could have is to change the expectations that people have about using the web, especially on mobile devices. Right now, people associate the web on mobile with long waits and horrible spammy overlays. Service workers can help solve that first part.
If people then start adding sites to their home screen, that will be a great sign that the web is really holding its own. But I don’t think we should get too optimistic about that: for a user, there’s no difference between a prompt on their screen saying “add to home screen” and a prompt on their screen saying “download our app”—they’re equally likely to be dismissed because we’ve trained people to dismiss anything that covers up the content they actually came for.
It’s entirely possible that websites could start taking over much of the functionality that previously was only possible in a native app. But I think that inertia and habit will keep people using native apps for quite some time.
The big exception is in markets where storage space on devices is in short supply. That’s where the decision to install a native app isn’t taken likely (given the choice between your family photos and an app, most people will reject the app). The web can truly shine here if we build lightweight, performant services.
Even in that situation, I’m still not sure how many people will end up adding those sites to their home screen (it might feel so similar to installing a native app that there may be some residual worry about storage space) but I don’t think that’s too much of a problem: if people get to a site via search or typing, that’s fine.
I worry that the messaging around “progressive web apps” is perhaps over-fetishising the home screen. I don’t think that’s the real battleground. The real battleground is in people’s heads; how they perceive the web and how they perceive native.
After all, if the average number of native apps installed in a month is zero, then that’s not exactly a hard target to match. :-)
For me, progressive web apps don’t feel like a separate thing from making websites. I worry that the marketing of them might inflate expectations or confuse people. I like the idea that they’re simply websites that have taken their vitamins.
So my vision for progressive web apps is the same as my vision for the web: something that people use every day for all sorts of tasks.
I find it really discouraging that progressive web apps are becoming conflated with single page apps and the app shell model. Those architectural decisions have nothing to do with service workers, HTTPS, and manifest files. Yet I keep seeing the concepts used interchangeably. It would be a real shame if people chose not to use these great technologies just because they don’t classify what they’re building as an “app.”
If anything, it’s good ol’ fashioned content sites (newspapers, wikipedia, blogs, and yes, books) that can really benefit from the turbo boost of service worker+HTTPS+manifest.
I was at a conference recently where someone was given a talk encouraging people to build progressive web apps but discouraging people from doing it for their own personal sites. That’s a horrible, elitist attitude. I worry that this attitude is being codified in the term “progressive web app”.
Well, like I said, I think that some people are focusing a bit too much on the home screen and not enough on the benefits that service workers can provide to just about any website.
My biggest learning is that these technologies aren’t for a specific subset of services, but can benefit just about anything that’s on the web. I mean, just using a service worker to explicitly cache static assets like CSS, JS, and some images is a no-brainer for almost any project.
So there you go—I’m very excited about the capabilities of these technologies, but very worried about how they’re being “sold”. I’m particularly nervous that in the rush to emulate native apps, we end up losing the very thing that makes the web so powerful: URLs.
I can forgive our answer machines if they sometimes get it wrong. It’s less easy to forgive the confidence with which the bad answer is presented, giving the impression that the answer is definitive. That’s a design problem.
Ellen goes through the principles behind the tone of voice on the new Clearleft site:
- Our clients are the heroes and heroines, we facilitate their journey.
- Speak as an individual doing whatever it is you love. Expose lovable details.
- Use the imperative, kill the “-ing”.
- Be evocative and paint the picture. Show don’t tell.
- Be a practical friend.
- Be inquisitive. Ask smart questions that need solving.
An online training course that will banish all fear of the command line, expertly delivered by the one and only Remy Sharp.
For designers, new developers, UX, UI, product owners and anyone who’s been asked to “just open the terminal”.
Take advantage of the special launch price—there are some serious price reductions there.
AMP Conf was one of those deep dive events, with two days dedicated to one single technology: AMP.
Except AMP isn’t really one technology, is it? And therein lies the confusion. This was at the heart of the panel I was on. When we talk about AMP, we could be talking about one of three things:
imgelement on an AMP page, you use an
styleelement instead of an external file, and there’s a limit on what you can do with those styles.
The first piece of AMP—the format—is kind of like a collection of marginal gains. Where the
img element might have some performance issues, the
amp-img element optimises for perceived performance. But if you just used the AMP web components, it wouldn’t be enough to make your site blazingly fast.
The second part of AMP—the rules—is where the speed gains start to really show. You can’t have an external style sheet, and crucially, you can’t have any third-party scripts other than the AMP script itself. This is key to making AMP pages super fast. It’s not so much about what AMP does; it’s more about what it doesn’t allow. If you never used a single AMP component, but stuck to AMP’s rules disallowing external styles and scripts, you could easily make a page that’s even faster than what AMP can do.
At AMP Conf, Natalia pointed out that The Guardian’s non-AMP pages beat out the AMP pages for performance. So why even have AMP pages? Well, that’s down to the third, most contentious, part of the AMP puzzle.
The AMP cache turns the user experience of visiting an AMP page from fast to instant. While you’re still on the search results page, Google will pre-render an AMP page in the background. Not pre-fetch, pre-render. That’s why it opens so damn fast. It’s also what causes the most confusion for end users.
From my unscientific polling, the behaviour of AMP results confuses the hell out of people. The fact that the page opens instantly isn’t the problem—far from it. It’s the fact that you don’t actually go to an another page. Technically, you’re still on Google. An analogous mental model would be an RSS reader, or an email client: you don’t go to an item or an email; you view it in situ.
Well, that mental model would be fine if it were consistent. But in Google search, only some results will behave that way (the AMP pages) and others will behave just like regular links to other websites. No wonder people are confused! Some search results take them away and some search results keep them on Google …even though the page looks like a different website.
The price that we pay for the instantly-opening AMP pages from the Google cache is the URL. Because we’re looking at Google’s pre-rendered copy instead of the original URL, the address bar is not pointing to the site the browser claims to be showing. Everything in the body of the browser looks like an article from The Guardian, but if I look at the URL (which is what security people have been telling us for years is important to avoid being phished), then I’ll see a domain that is not The Guardian’s.
But wait! Couldn’t Google pre-render the page at its original URL?
Yes, they could. But they won’t.
This was a point that Paul kept coming back to: trust. There’s no way that Google can trust that someone else’s URL will play by the AMP rules (no external scripts, only loading embedded content via web components, limited styles, etc.). They can only trust the copies that they themselves are serving up from their cache.
By the way, there was a joint AMP/search panel at AMP Conf with representatives from both teams. As you can imagine, there were many questions for the search team, most of which were Glomar’d. But one thing that the search people said time and again was that Google was not hosting our AMP pages. Now I don’t don’t know if they were trying to make some fine-grained semantic distinction there, but that’s an outright falsehood. If I click on a link, and the URL I get taken to is a Google property, then I am looking at a page hosted by Google. Yes, it might be a copy of a document that started life somewhere else, but if Google are serving something from their cache, they are hosting it.
This is one of the reasons why AMP feels like such a bait’n’switch to me. When it first came along, it felt like a direct competitor to Facebook’s Instant Articles and Apple News. But the big difference, we were told, was that you get to host your own content. That appealed to me much more than having Facebook or Apple host the articles. But now it turns out that Google do host the articles.
This will be the point at which Googlers will say no, no, no, you can totally host your own AMP pages …but you won’t get the benefits of pre-rendering. But without the pre-rendering, what’s the point of even having AMP pages?
Alright, but what about The Guardian? They’ve already got fast pages, but they still have to create separate AMP pages if they want to get the pre-rendering benefits when they show up in Google search results. Sorry, says Google, but it’s the only way we can trust that the pre-rendered page will be truly fast.
So here’s the impasse we’re at. Google have provided a list of best practices for making fast web pages, but the only way they can truly verify that a page is sticking to those best practices is by hosting their own copy, URLs be damned.
This was the crux of Paul’s argument when he was on the Shop Talk Show podcast (it’s a really good episode—I was genuinely reassured to hear that Paul is not gung-ho about drinking the AMP Kool Aid; he has genuine concerns about the potential downsides for the web).
Initially, I accepted this argument that Google just can’t trust the rest of the web. But the more I talked to people at AMP Conf—and I had some really, really good discussions with people away from the stage—the more I began to question it.
Here’s the thing: the regular Google search can’t guarantee that any web page is actually 100% the right result to return for a search. Instead there’s a lot of fuzziness involved: based on the content, the markup, and the number of trusted sources linking to this, it looks like it should be a good result. In other words, Google search trusts websites to—by and large—do the right thing. Sometimes websites abuse that trust and try to game the system with sneaky tricks. Google responds with penalties when that happens.
Why can’t it be the same for AMP pages? Let me host my own AMP pages (maybe even host my own AMP script) and then when the Googlebot crawls those pages—the same as it crawls any other pages—that’s when it can verify that the AMP page is abiding by the rules. If I do something sneaky and trick Google into flagging a page as fast when it actually isn’t, then take my pre-rendering reward away from me.
To be fair, Google has very, very strict rules about what and how to pre-render the AMP results it’s caching. I can see how allowing even the potential for a false positive would have a negative impact on the user experience of Google search. But c’mon, there are already false positives in regular search results—fake news, spam blogs. Googlers are smart people. They can solve—or at least mitigate—these problems.
Google says it can’t trust our self-hosted AMP pages enough to pre-render them. But they ask for a lot of trust from us. We’re supposed to trust Google to cache and host copies of our pages. We’re supposed to trust Google to provide some mechanism to users to get at the original canonical URL. I’d like to see trust work both ways.
Hatching plans for the August eclipse.
A Mac app for converting PNGs and JPEGs to WebP.
Excellent and practical advice for before, during, and after research sessions and usability tests.
We examine the possibility that Fast Radio Bursts (FRBs) originate from the activity of extragalactic civilizations. Our analysis shows that beams used for powering large light sails could yield parameters that are consistent with FRBs.
I’m guessing Paul Gilster may have thoughts on this.
This is a nice understandable explanation of the basics of React.
There’s a real skill in explaining something so clearly that even n00bs like me can understand it.
And here’s another reason why password rules are bullshit: you’re basically giving a list of instructions to hackers—the password rules help them narrow down the strings they need to brute force.
Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.
Josh gives a thorough roundup of the Interaction ‘17 event he co-chaired.
“I think I’ve distilled what this conference is all about,” Jeremy Keith quipped to me during one of the breaks. “It’s about how we’ll save the world through some nightmarish combination of virtual reality, chatbots, and self-driving cars.”
Tim watched the panel discussion at AMP Conf. He has opinions.
Optimistically, AMP may be a stepping stone to a better performant web. But I still can’t shake the feeling that, in its current form, it’s more of a detour.
Here’s the panel I was on at the AMP conference. It was an honour and a pleasure to share the stage with Nicole, Sarah, Gina, and Mike.
Everyone at AMP Conf seems really eager to get more analytics and more ads into AMP. But for a user, those aren’t features; they’re bugs.
About to appear on a panel at AMP Conf, live streamed here:
Smart use of attribute selectors in CSS to catch mistakes in HTML.
I’m in New York. Again. This time it’s for Google’s AMP Conf, where I’ll be giving ‘em a piece of my mind on a panel.
The conference starts tomorrow so I’ve had a day or two to acclimatise and explore. Seeing as Google are footing the bill for travel and accommodation, I’m staying at a rather nice hotel close to the conference venue in Tribeca. There’s live jazz in the lounge most evenings, a cinema downstairs, and should I request it, I can even have a goldfish in my room.
Today I realised that my hotel sits in the apex of a triangle of interesting buildings: carrier hotels.
Looming above my hotel is 32 Avenue of the Americas. On the outside the building looks like your classic Gozer the Gozerian style of New York building. Inside, the lobby features a mosaic on the ceiling, and another on the wall extolling the connective power of radio and telephone.
The same architects also designed 60 Hudson Street, which has a similar Art Deco feel to it. Inside, there’s a cavernous hallway running through the ground floor but I can’t show you a picture of it. A security guard told me I couldn’t take any photos inside …which is a little strange seeing as it’s splashed across the website of the building.
I walked around the outside of 60 Hudson, taking more pictures. Another security guard asked me what I was doing. I told her I was interested in the history of the building, which is true; it was the headquarters of Western Union. For much of the twentieth century, it was a world hub of telegraphic communication, in much the same way that a beach hut in Porthcurno was the nexus of the nineteenth century.
For a 21st century hub, there’s the third and final corner of the triangle at 33 Thomas Street. It’s a breathtaking building. It looks like a spaceship from a Chris Foss painting. It was probably designed more like a spacecraft than a traditional building—it’s primary purpose was to withstand an atomic blast. Gone are niceties like windows. Instead there’s an impenetrable monolith that looks like something straight out of a dystopian sci-fi film.
Brutalist on the outside, its interior is host to even more brutal acts of invasive surveillance. The Snowden papers revealed this AT&T building to be a centrepiece of the Titanpointe programme:
They called it Project X. It was an unusually audacious, highly sensitive assignment: to build a massive skyscraper, capable of withstanding an atomic blast, in the middle of New York City. It would have no windows, 29 floors with three basement levels, and enough food to last 1,500 people two weeks in the event of a catastrophe.
But the building’s primary purpose would not be to protect humans from toxic radiation amid nuclear war. Rather, the fortified skyscraper would safeguard powerful computers, cables, and switchboards. It would house one of the most important telecommunications hubs in the United States…
Looking at the building, it requires very little imagination to picture it as the lair of villainous activity. Laura Poitras’s short film Project X basically consists of a voiceover of someone reading an NSA manual, some ominous background music, and shots of 33 Thomas Street looming in its oh-so-loomy way.
A top-secret handbook takes viewers on an undercover journey to Titanpointe, the site of a hidden partnership. Narrated by Rami Malek and Michelle Williams, and based on classified NSA documents, Project X reveals the inner workings of a windowless skyscraper in downtown Manhattan.
A nasty service that Harry noticed in his role as chronicler of dark patterns—this exploits the way that browser permissions are presented below the line of death.
Bruce widens our horizons with this in-depth look at where and how people are accessing the web around the world.
In this article, we’ve explored where the next 4 billion connected people will come from, as well as some of the innovations that the standards community has made to better serve them. In the next part, we’ll look at some of the demand-side problems that prevent people from accessing the web easily and what can be done to overcome them.
Exploring the internet in New York.
To be clear, every company currently does some form of this tracking of users. There would simply be no other way to measure operations. But Facebook has quite clearly been tiptoeing outside the bounds of what is ethically acceptable data business practices for a while.
A thorough round-up of Facebook’s current data collection practices and what you can do about it.
Absolute gold dust from Mike!
I think that having regular 1:1s is really important, but I’m sure I’m not doing them as effectively as I could—the advice in here is going to be invaluable.
There are three types of employees in the world when it comes to disclosing issues:
- Those who will always tell you about problems.
- Those who will never tell you about problems.
- Those who will tell you about problems when asked in the right way.
I love my ones and am frustrated by my twos, but I feel like at least 9 out of 10 people are actually threes.
A damning assessment of Tim Berners-Lee’s defeatist portrayal of the W3C:
No matter which side is right, the W3C faces an existential crisis.
- The W3C is a shepherd of the web for all, the web on everything, and a web of trust. But now it is fundamentally compromising its own principles in the name of maintaining industry relevance.
- Or, the W3C is merely an industry body for browser vendors to collaborate and its mission statement is nothing more than PR to increase buy-in from the smaller, largely powerless, members.
Both can’t be true. Neither is good news for the organisation.
С Днем Рождения, Валентина Терешкова!
Thinking of writing a book? Here’s some excellent advice and insights from Yaili, who only went and wrote another one.
Let me say this first: writing a book is hard work. It eats up all of your free time and mental space. It makes you feel like you are forever procrastinating and producing very little. It makes you not enjoy any free time. It’s like having a dark cloud hanging over your head at all times. At. All. Times.
For the second time in two weeks, I find myself sitting in a dive bar in America, drinking beer, eating wings, and watching a Pens game.
This is really good fun! And thanks to service workers, it works offline too.
The rounds are:
An interview with Batesy that gives a nice insight into life at Clearleft.
He’s sketching mad, that one!
Reading Star Maker by Olaf Stapledon.
An alternative history of technology, emphasising curation over innovation:
We start to see the intangibles – the standards and ideologies that help to create and order technology systems, making them work at least most of the time. We start to see that technological change does not demand that we move fast and break things. Understanding the role that standards, ideologies, institutions – the non-thing aspects of technology – play, makes it possible to see how technological change actually happens, and who makes it happen.
Reading Bloodchild by Octavia E. Butler.
Going to New York. brb
Fear and concrete in Las Vegas: a great piece of infrastructure reportage by Georgina.
Much as I respect Tim Berners-Lee, his logic here is completely flawed. First of all, treating DRM as though it’s an implacable force of nature is a category error. Secondly, EME doesn’t in any provide a standardised solution: it provides a sandbox for each DRM vendor to inject their own proprietary solution.
The new Clearleft website is live! Huzzah!
Many people have been working very hard on it and it’s all looking rather nice. But, as I said before, the site launch isn’t the end—it’s just the beginning.
There are some obvious next steps: fixing bugs, adding content, tweaking copy, and, oh yeah, that whole “testing with real users” thing. But there’s also an opportunity to have some fun on the front end. Now that the site is out there in the wild, there’s a real incentive to improve its performance.
Off the top of my head, these are some areas where I think we can play around:
@font-face. A smart font-loading strategy—at least for the body copy—could really help improve the perceived performance.
I’m looking forward to tinkering with some of those technologies. Each one should make an incremental improvement to the site’s performance. There are already some steps on the back-end that are making a big difference: upgrading to PHP7 and using HTTP2.
Now the real fun begins.
A really inspiring post by Jen outlining all the benefits of the new CSS layout features …and the problems with thinking framework-first.
I know a lot of people will think the “best” way to use CSS Grid will be to download the new version of Bootstrap (version 5! now with Grid!), or to use any one of a number of CSS Grid layout frameworks that people are inevitably going to make later this year (despite Rachel Andrew and I begging everyone not to). But I don’t. The more I use CSS Grid, the more convinced I am that there is no benefit to be had by adding a layer of abstraction over it. CSS Grid is the layout framework. Baked right into the browser.
These icons-as-a-service could be really useful for making quick’n’dirty HTML prototypes.
Danielle and Mark have been working flat out on Fractal. Here’s the roadmap they’re working to.
Unsurprisingly, I completely and utterly agree with Ethan’s assessment here:
I’ve written some code that’s saying, “Once the screen is this size and the element appears in a different, smaller container, use a narrower layout on this element.”
But, well, that’s weird. Why can’t we apply styles based on the space available to the module we’re designing, rather than looking at the shape of the viewport?
I also share his frustration with the “math is hard; let’s go shopping” response from browser vendors:
There’s an incredible clamor for container queries, with folks from every corner of the responsive community asking for something that solves this problem. So personally, I’d love to see at least one browser vendor partner with the RICG, and get properly fired up about this.
We had to drag browser makers kicking and screaming to responsive images (to this day, Hixie maintains it’s not a problem that needs solving) and I suspect even more activism is going to be needed to get them to tackle container queries.
A nice rundown of some of the fun you can have with viewport units.
I’m very glad the problems with
vh units I wrote about a little while back is getting fixed in Chrome for mobile.
Dan describes his approach to maintainable CSS. It’s a nice balance between semantic naming and reusable styles.
Warning: the analogies used here might make you very, very hungry.
A lovely piece of early web history—Olia Lialina describes the early Net Art scene in 2000.
The address bar is the author’s signature. It’s where action takes place, and it’s the action itself. The real action on the web doesn’t happen on the page with its animated GIFs or funny scripts, it’s concentrated in the address bar.
And how wonderful that this piece is now published on Rhizome, an online institution so committed to its mission that it’s mentioned in this seventeen year old article.
How style tiles can work great in combination with content prototypes:
Surprisingly, it helps clients understand the HTML content prototype better. They now clearly see the difference and the relationship between content and design. In general it helps me explain the content-first process better and it helps them make more sense of it.
Jason revisits responsive images. On the whole, things are looking good when it comes to browser support, but he points out that
scrset’s precursor in CSS—
image-set seems to have dropped off the radar of most browser makers, which is a real shame.