Brad gets ranty …with good reason.
Monday, December 9th, 2019
Friday, November 22nd, 2019
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.
Thursday, November 21st, 2019
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.
Monday, November 11th, 2019
I have such fondness for this film. It’s one of those films that I love to watch on a Sunday afternoon (though that’s true of so many Spielberg films—Jaws, Raiders Of The Lost Ark, E.T.). I remember seeing it in the cinema—this would’ve been the special edition re-release—and feeling the seat under me quake with the rumbling of the musical exchange during the film’s climax.
Ariel invited Rose Eveleth and Laura Welcher on to discuss the film. They spent a lot of time discussing the depiction of first contact communication—Arrival being the other landmark film on this topic.
If we send a message into space, will extraterrestrial beings receive it? Will they understand?
You can a read an article by the author on The Guardian, where he mentions some of the wilder ideas about transmitting signals to aliens:
Minsky, widely regarded as the father of AI, suggested it would be best to send a cat as our extraterrestrial delegate.
Don’t worry. Marvin Minsky wasn’t talking about sending a real live cat. Rather, we transmit instructions for building a computer and then we can transmit information as software. Software about, say, cats.
It’s not that far removed from what happened with the Voyager golden record, although that relied on analogue technology—the phonograph—and sent the message pre-compiled on hardware; a much slower transmission rate than radio.
But it’s interesting to me that Minsky specifically mentioned cats. There’s another long-term communication puzzle that has a cat connection.
The Yukka Mountain nuclear waste repository is supposed to store nuclear waste for 10,000 years. How do we warn our descendants to stay away? We can’t use language. We probably can’t even use symbols; they’re too culturally specific. A think tank called the Human Interference Task Force was convened to agree on the message to be conveyed:
This place is a message… and part of a system of messages… pay attention to it! Sending this message was important to us. We considered ourselves to be a powerful culture.
This place is not a place of honor…no highly esteemed deed is commemorated here… nothing valued is here.
What is here is dangerous and repulsive to us. This message is a warning about danger.
A series of thorn-like threatening earthworks was deemed the most feasible solution. But there was another proposal that took a two pronged approach with genetics and folklore:
- Breed cats that change colour in the presence of radioactive material.
- Teach children nursery rhymes about staying away from cats that change colour.
This is the raycat solution.
Tuesday, October 29th, 2019
If we want design to communicate, we need to communicate in the design process.
I might get that framed.
Wednesday, July 24th, 2019
Jon’s ranting about Agile here, but it could equally apply to design systems:
Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.
Wednesday, July 3rd, 2019
Chris describes exactly why I wrote about
But we should be extra watchful about stuff like this. If any browser goes rogue and just starts shipping stuff, web standards is over. Life for devs gets a lot harder and the web gets a lot worse. The stakes are high. And it’s not going to happen overnight, it’s going to happen with little tiny things like this. Keep that blue beanie on.
Wednesday, June 19th, 2019
Shockwaves rippled across the web standards community recently when it appeared that Google Chrome was unilaterally implementing a new element called
toast. It turns out that’s not the case, but the confusion is understandable.
First off, this all kicked off with the announcement of “intent to implement”. That makes it sounds like Google are intending to, well, …implement this. In fact “intent to implement” really means “intend to mess around with this behind a flag”. The language is definitely confusing and this is something that will hopefully be addressed.
Secondly, Chrome isn’t going to ship a
toast element. Instead, this is a proposal for a custom element currently called
std-toast. I’m assuming that should the experiment prove successful, it’s not a foregone conclusion that the final element name will be called
toast (minus the sexually-transmitted-disease prefix). If this turns out to be a useful feature, there will surely be a discussion between implementators about the naming of the finished element.
This is the ideal candidate for a web component. It makes total sense to create a custom element along the lines of
std-toast. At first I was confused about why this was happening inside of a browser instead of first being created as a standalone web component, but it turns out that there’s been a fair bit of research looking at existing implementations in libraries and web components. So this actually looks like a good example of paving an existing cowpath.
But it didn’t come across that way. The timing of announcements felt like this was something that was happening without prior discussion. Terence Eden writes:
It feels like a Google-designed, Google-approved, Google-benefiting idea which has been dumped onto the Web without any consideration for others.
I know that isn’t the case. And I know how many dedicated people have worked hard on this proposal.
To be clear, while I think there is value in minting a native HTML element to fill a defined gap, I am wary of the approach Google has taken. A repo from a new-to-the-industry Googler getting a lot of promotion from Googlers, with Googlers on social media doing damage control for the blowback, WHATWG Googlers handling questions on the repo, and Google AMP strongly supporting it (to reduce its own footprint), all add up to raise alarm bells with those who advocated for a community-driven, needs-based, accessible web.
But my concern wasn’t so much about the nature of the new elements, but of how we learned about them and what that says about how web standardization works.
So there’s a general feeling (outside of Google) that there’s something screwy here about the order of events. A lot discussion and research seems to have happened in isolation before announcing the intent to implement:
It does not appear that any discussions happened with other browser vendors or standards bodies before the intent to implement.
Why is this a problem? Google is seeking feedback on a solution, not on how to solve the problem.
Going back to my early confusion about putting a web component directly into a browser, this question on Discourse echoes my initial reaction:
Why not release
std-toast(and other elements in development) as libraries first?
The extensible web movement focused on exposing low-level APIs to developers: the fetch API, the cache API, custom elements, Houdini, and all of those other building blocks. Layered APIs, on the other hand, focuses on high-level features …like, say, an HTML element for displaying “toast” notifications.
Layered APIs is an interesting idea, but I’m worried that it could be used to circumvent discussion between implementers. It’s a route to unilaterally creating new browser features first and standardising after the fact. I know that’s how many features already end up in browsers, but I think that the sooner that authors, implementers, and standards bodies get a say, the better.
I certainly don’t think this is a good look for Google given the debacle of AMP’s “my way or the highway” rollout. I know that’s a completely different team, but the external perception of Google amongst developers has been damaged by the AMP project’s anti-competitive abuse of Google’s power in search.
Right now, a lot of people are jumpy about Microsoft’s move to Chromium for Edge. My friends at Microsoft have been reassuring me that while it’s always a shame to reduce browser engine diversity, this could actually be a good thing for the standards process: Microsoft could theoretically keep Google in check when it comes to what features are introduced to the Chromium engine.
But that only works if there is some kind of standards process. Layered APIs in general—and
std-toast in particular—hint at a future where a single browser vendor can plough ahead on their own. I sincerely hope that’s a misreading of the situation and that this has all been an exercise in miscommunication and misunderstanding.
Like Dave Cramer says:
I hear a lot about how anyone can contribute to the web platform. We’ve all heard the preaching about incubation, the Extensible Web, working in public, paving the cowpaths, and so on. But to an outside observer this feels like Google making all the decisions, in private, and then asking for public comment after the feature has been designed.
Wednesday, May 15th, 2019
The slides from Carolyn’s talk at Beyond Tellerrand. The presentation is ostensibly about writing documentation, but I think it’s packed with good advice for writing in general.
Monday, April 8th, 2019
Thursday, February 28th, 2019
Onboarding. Reaching out. In terms of. Synergy. Bandwidth. Headcount. Forward planning. Multichannel. Going forward. We are constantly bombarded and polluted with nonsense speak. These words and phrases snag and attach themselves to our vocabulary like sticky weeds.
Words become walls.
I love this post from Ben on the value of plain language!
We’re not dumbing things down by using simple terms. We’re being smarter.
Read on for the story of the one exception that Ben makes—it’s a good one.
Tuesday, February 26th, 2019
Some useful lessons here for strengthening a culture of sustained work on a design system.
Creating and maintaining a design system is like planting a tree—it has to be nurtured and cared for to reap the benefits. The seed of our design system has been planted, and now our teams are working together to maintain and grow it. Our new way of working supports gives people recognition, facilitates trust, and creates strong partnerships.
Sunday, January 27th, 2019
A browser extension that encrypts and decrypts posts on Facebook—if two users have the extension installed, they can communicate without Facebook being able read their messages.
Thursday, November 22nd, 2018
I just binge-listened to the six episodes of the first season of this podcast from Stephen Fry—it’s excellent!
It covers the history of communication from the emergence of language to the modern day. At first I was worried that it was going to rehash some of the more questionable ideas in the risible Sapiens, but it turned out to be far more like James Gleick’s The Information or Tom Standage’s The Victorian Internet (two of my favourite books on the history of technology).
There’s no annoying sponsorship interruptions and the whole series feels more like an audiobook than a podcast—an audiobook researched, written and read by Stephen Fry!
Wednesday, November 21st, 2018
The tools that characterize a person’s time and place in technological history are the ones that a person actually uses, the technologies relied upon so heavily that they can feel like an extension of oneself. This is part of how technology can define a culture, and why sometimes you forget the thing you’re using is technology at all. Until, eventually, inevitably, the technology is all but forgotten.
Thursday, November 8th, 2018
Publishing on the web really is quite marvellous:
…an endless thrill, a sort of everlasting, punk-rock feeling and I hope it will never really go away.
Monday, October 22nd, 2018
Like banging your head against a proprietary brick wall.
To me this is all just another example of a company operating a closed process, not willing to collaborate openly as peers. The Ivory Tower development methodology.
Monday, October 8th, 2018
The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.
This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
That last part dovetails nicely with Jerlyn’s equally great piece.
Tuesday, October 2nd, 2018
When you’re struggling to write something that sounds clear and sounds human (two of the essential basics of a good blog post, I’d argue), just use the words normal people would use.
If we use jargon, we reveal our insecurity. If we use pretentious language, we expose our arrogance. But if we use language that anyone can understand, people are much more likely to value what we do.