Tags: communicatio

82

sparkline

Wednesday, July 24th, 2019

Jon Aizlewood · Agile and design — How to avoid Frankensteining your product

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

Toast

Chris describes exactly why I wrote about toast:

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

Toast

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.

Adrian Roselli also remarks on the optics of this situation:

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.

Dave Cramer made a similar point:

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?

It turns out that std-toast and other in-browser web components are part of an idea called layered APIs. In theory this is an initiative in the spirit of the extensible web manifesto.

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

Humanizing Your Documentation - Full Talk - Speaker Deck

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

Break out of the echo chamber - Andy Bell

So much of my echo chamber is consumed by people, including myself, who have a very dim view of JavaScript frameworks being thrown at everything, arguing with the people who are in the process of throwing JavaScript frameworks at everything. We forget one very important thing, though: we represent the minority of the web community and our arguments probably look very pointless and silly to the majority.

Thursday, February 28th, 2019

Getting help from your worst enemy

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

Systems Thinking, Unlocked – Airbnb Design

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.

Thursday, February 7th, 2019

Transcript of Tim Berners-Lee’s talk to the LCS 35th Anniversary celebrations, Cambridge Massachusetts, 1999/April/14

Twenty years ago—when the web was just a decade old—Tim Berners-Lee gave this talk, looking backwards and forwards.

For me the fundamental Web is the Web of people. It’s not the Web of machines talking to each other; it’s not the network of machines talking to each other. It’s not the Web of documents. Remember when machines talked to each other over some protocol, two machines are talking on behalf of two people.

Sunday, January 27th, 2019

Deface

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

Great Leap Years - Official site of Stephen Fry

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

Can You Still Send a Telegram? - The Atlantic

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

What do you want to do when you grow up, kid? • Robin Rendle

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

Rehabilitating Google AMP: My failed attempt - socPub

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

Workplace topology | Clearleft

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

Use the words normal people use

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.

John Spencer: “There’s no bullshit like design bullshit” - Design Week

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.

Friday, September 28th, 2018

Letterform Archive – From the Collection: Blissymbolics

The fascinating story of Charles K. Bliss and his symbolic language:

The writing system – originally named World Writing in 1942, then Semantography in 1947, and finally Blissymoblics in the 1960s – contains several hundred basic geometric symbols (“Bliss-characters”) that can be combined in different ways to represent more complex concepts (“Bliss-words”). For example, the Bliss-characters for “house” and “medical” are combined to form the Bliss-word for “hospital” or “clinic”. The modular structure invites comparison to the German language; the German word for “hospital ” – “krankenhaus” – translates directly to “sick house”.

Wednesday, September 5th, 2018

The principles behind Bulb’s design – Making Bulb – Medium

This is a great piece by Alla, ostensibly about Bulb’s design principles, but it’s really about what makes for effective design principles in general. It’s packed full of great advice, like these design principles for design principles:

  • Good principles are genuine
  • Good principles have a point of view
  • Good principles are memorable

Sunday, August 12th, 2018

Let’s serve everyone good-looking content

A terrific piece by Hidde, about CSS grid, but also about a much bigger question:

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.

Sunday, August 5th, 2018

Joymaker by Frederik Pohl from The Age of The Pussyfoot

From Frederik Pohl’s 1966 novel:

The remote-access computer transponder called the “joymaker” is your most valuable single possession in your new life. If you can imagine a combination of telephone, credit card, alarm clock, pocket bar, reference library, and full-time secretary, you will have sketched some of the functions provided by your joymaker.

Essentially, it is a transponder connecting you with the central computing facilities of the city in which you reside on a shared-time, self-programming basis.