When is the right time to share our excitement about new web features?

When we share content about emerging web platform features, we have to be careful that we aren’t frustrating people with things they can’t use yet. However there is a place for talking about new things, and people who enjoy hearing about them. This post is about some of the ways I try to meet the needs of a browser DevRel team that need to share information about new things, with those of developers who need to know what actually works now. If you write or speak about the web, perhaps some of these ideas will help you too.

The amount of stuff our influencers hype on their websites and newsletters needs to slow down. I know they sincerely like CSS, that their professional life depends on staying up to date and looking relevant in CSS, but damn. When I want to update myself, I have to spend hours checking on Can I Use if the things they talked about in a blog post in 2021 actually exist in my browser; only to find half of it stuck in technical preview purgatory. It makes me resentful towards people and I don’t like that.— New CSS that can actually be used in 2024

My day job is as content lead for Chrome Developer Relations, so publishing developer content is what I do. As a lead, figuring out how to have the most impact with that content is also my job. 

As the developer relations team for a browser, we need to share with developers things that are landing in Chrome. We do this for several reasons. Often we’re trying to get feedback. When I write about a feature that’s actually behind a flag in Chromium, it usually comes with a question. Sometimes we’re just letting people know a thing is here, because demand from developers is one way we get things implemented in other browsers.

All that said, we’re very aware that most developers aren’t going to use a thing until it’s available across browsers. It’s the entire premise behind Baseline—a feature doesn’t become Baseline Newly available until it’s supported in the main engines, it doesn’t become Widely available until 30 months have passed since the Newly available date. That reflects the real world that we know developers exist in, not a Chrome-only world, or a world where everyone always has the latest version of their chosen browser.

There’s a tension there, how do we get the word out about new things, get feedback, and drive demand for interoperability, without making developers frustrated and resentful? I think there are a couple of straightforward things we can all do.

“Who needs the feature” versus “Who this content is for”

It’s important not to confuse who the feature is for with who this article you are writing right now is for. The feature might ultimately be useful to every developer, that doesn’t mean this particular blog post is.

For example, customizable select solves a real need. I’m pretty sure that once it’s Baseline Widely available most developers will want to use it. However, when writing a blog post asking for feedback on the emerging feature, the audience for that blog post is not “all developers who might use customizable select when it’s available everywhere”. The audience is “developers who are interested in giving feedback on things they can’t use yet, particularly those who are doing a lot of custom select implementations right now”.

Think about who this piece of content is for, at this point in time. Then make sure that intention is clear from the introduction. If a developer starts to read about something experimental, they should be made aware that it’s experimental within a few sentences. They can then choose whether to continue, or to go and find something that’s actually relevant, before they’ve invested time and feel misled. I’m a fan of really boring intros for technical content. Up front let people know if the content is for them and what they will get out of reading it.

You don’t need lengthy tutorials for experimental features

You often don’t need to write huge guides, how tos, and tutorials for experimental things. Once again, it comes back to the audience. The people who like to play around with experimental things are likely to be expert developers, they’ll want reference docs far more than a step by step guide to a specific solution. Things that do work well are demos that can be played with live or checked out locally. When asking for help and feedback, make it as easy as possible for people to give you that.

If you really need to get feedback from a cohort less interested in playing around with tech, a short video is likely to be most productive. They probably aren’t going to implement something to try out this feature they can’t use in production. With a video you can also draw attention to specific things you want feedback on.

The gap between single browser and Baseline Widely available

Once a feature is no longer truly experimental, when it’s launched into stable in one or two browsers, we enter a slightly different period. There are features that do work well as a progressive enhancement or have solid polyfills, and some developers are happy to adopt them, but they need to know that’s the case. Make the status clear early on, so people don’t have to do the searching of Can I Use, mentioned in the quote at the start of this article.

One of the first things I did after joining the Chrome team, was to start insisting that all content had clear browser information included near the start. We’ve used the MDN data for a couple of years, we’ve now launched a Baseline web component, available for anyone to use, which gives the Baseline status of any feature. Use the component, and the status is updated as a feature moves from Limited, through Newly available to Widely available.

The right content at the right time

There’s a good number of developers who love to hear about new things landing on the platform. However there’s a much larger group of people who really just want to do their jobs, and who can’t invest time learning new things until they can use the new things. If we publish all of our material when things are experimental or only available in a single browser, all the noise happens at the wrong time. This leads to people missing the fact that things have become available everywhere. So, don’t forget to write about the Newly and Widely available things, you’ll be speaking to a much bigger audience, and providing people with something they can use in their production sites right away.

At the point that early adopters, influencers, and professional developer relations folks are getting bored with talking about something, that’s pretty much the point it becomes useful to everyone else. Keep talking about it, listen to the problems that people are having trying to use it in their projects, because there’s a whole stack of new content ideas in showing how to solve those problems.