Tags: lab

167

sparkline

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.

Thursday, June 27th, 2019

What I Learned Co-Founding Dribbble – SimpleBits

Twenty hard-won lessons from Dan from ten years of Dribbble.

We sent 50 shirts along with a card to friends and colleagues announcing Dribbble’s beta back in 2008. This first batch of members played a pivotal role in the foundation of the community and how it would develop. The shirt helped guilt them into actually checking out the site.

I think I still have my T-shirt somewhere!

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.

Tuesday, June 18th, 2019

How to Section Your HTML | CSS-Tricks

A deep dive with good advice on using—and labelling—sectioning content in HTML: nav, aside, section, and article.

Tuesday, May 28th, 2019

W3C and WHATWG to work together to advance the open Web platform | W3C Blog

It’s Armistice Day in the world of HTML:

WHATWG maintains the HTML and DOM Living Standards.

W3C stops independent publishing of a designated list of specifications related to HTML and DOM and instead will work to take WHATWG Review Drafts to W3C Recommendations.

It feels like the loop is finally being closed on what I wrote about in the opening chapter of HTML5 For Web Designers back in 2010.

Monday, May 27th, 2019

Bullet Time

Bullet comments, or 弹幕 (“danmu”), are text-based user reactions superimposed onto online videos: a visual commentary track to which anyone can contribute.

A fascinating article by Christina Xu on this overwhelming collaborative UI overlaid on Chinese video-sharing sites:

In the West, the Chinese internet is mostly depicted in negative terms: what websites and social platforms are blocked, what keywords are banned, what conversations and viral posts are scrubbed clean from the web overnight. This austere view is not inaccurate, but it leaves out what exactly the nearly 750 million internet users in China do get up to.

Take a look at bullet comments, and you’ll have a decent answer to that question. They represent the essence of Chinese internet culture: fast-paced and impish, playfully collaborative, thick with rapidly evolving inside jokes and memes. They are a social feature beloved by a generation known for being antisocial. And most importantly, they allow for a type of spontaneous, cumulative, and public conversation between strangers that is increasingly rare on the Chinese internet.

Monday, April 29th, 2019

Naming things to improve accessibility

Some good advice from Hidde, based on his recent talk Six ways to make your site more accessible.

Thursday, April 4th, 2019

UX Workshop | Trys Mudford

I’m so, so happy that Trys has joined us at Clearleft!

Here, he recounts his first day, which just happened to coincide with an introductory UX workshop that went really well.

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.

Friday, February 22nd, 2019

nexus-project / nexus-browser · GitLab

Here’s the source code for the WorldWideWeb project we did at CERN.

Sunday, February 17th, 2019

The ineffectiveness of lonely icons | Matt Wilcox, Web Developer & Tinkerer

When in doubt, label your icons.

When not in doubt, you probably should be.

Thursday, February 14th, 2019

Talk at Bush Symposium: Notes

On the 50th anniversary of Vannevar Bush’s As We May Think, Tim Berners-Lee delivered this address in 1995.

To a large part we have MEMEXes on our desks today. We have not yet seen the wide scale deployment of easy human interfaces for editing hypertext and making links. (I find this constantly frustrating, but always assume will be cured by cheap commercial products within the year.)

Saturday, February 2nd, 2019

1969 & 70 - Bell Labs

PIctures of computers (of the human and machine varieties).

Sunday, January 27th, 2019

Make Your ARIA Labels Sing on Key — Knowbility

A good look at the (over)use of the aria-label attribute that confirms the first rule of ARIA.

Tuesday, January 22nd, 2019

I’m a Web Designer - Andy Bell

Something that I am increasingly uncomfortable with is our industry’s obsession with job titles. I understand that the landscape has gotten a lot more complex than when I started out in 2009, but I do think the sheer volume and variation in titles isn’t overly helpful in communicating what people actually do.

I share Andy’s concern. I kinda wish that the title for this open job role at Clearleft could’ve just said “Person”.

Tuesday, November 13th, 2018

Tweeting for 10,000 Years: An Experiment in Autonomous Software — Brandur Leach

Taking the idea of the Clock of the Long Now and applying it to a twitterbot:

Software may not be as well suited as a finely engineered clock to operate on these sorts of geological scales, but that doesn’t mean we can’t try to put some of the 10,000 year clock’s design principles to work.

The bot will almost certainly fall foul of Twitter’s API changes long before the next tweet-chime is due, but it’s still fascinating to see the clock’s principles applied to software: longevity, maintainability, transparency, evolvability, and scalability.

Software tends to stay in operation longer than we think it will when we first wrote it, and the wearing effects of entropy within it and its ecosystem often take their toll more quickly and more destructively than we could imagine. You don’t need to be thinking on a scale of 10,000 years to make applying these principles a good idea.

Sunday, November 4th, 2018

When your design system fails — HeyDesigner

You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.

Marissa Christy outlines the reasons why your design system might struggle:

  1. The redesign isn’t prioritized
  2. The tech stack is changing
  3. Maintenance takes discipline

But she also offers advice for counteracting these forces:

  1. Get buy-in from the whole team
  2. Prioritize a lightweight re-skin on older parts of the product
  3. Treat a design system like any other product project: start small
  4. Don’t wait for others. Lead by example.
  5. Finally, don’t compare yourself to others on the internet

Tuesday, October 30th, 2018

Web 2.0 … The Machine is Us/ing Us - YouTube

Looking back on this classic explainer video from eleven years ago, I know exactly what’s meant by this comment:

its weird that when i first saw this video it made me think of the future, and now i watch it and it reminds me of the past..

Monday, October 15th, 2018

We are Oxvik

Ooh, this is an exciting collaboration! Jon and Brian have teamed up to form a lovely little cooperative.

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.