Update Baseline card to feature year more prominently and future Widely available date

[tonypconway]

Description

This change modifies the Baseline card at the top of feature/API docs to:

• Include the Baseline year of the feature in the unexpanded view.
• Make "Widely available" or "Newly available" chip formatting consistent and more prominent.
• Adds a sentence providing the future Widely available date for Newly available features.

Motivation

At the moment, it's not very easy to determine at a glance which Baseline year the feature belongs to. Some developers are not able to target Baseline Widely available and want to use a Baseline year as their feature selection threshold. Similarly, some developers will find that their audience is on more up to date browsers and might want to use more modern features and target e.g. Baseline 2023 or 2024.

Similarly, developers often draw up longer-term plans, especially library providers like Angular or Vite who use Baseline Widely available on the day of a major version release as their target. It would be valuable for these developers to more easily be able to tell when a feature will become Widely available. It may not be WA today, but it will be by the time the new version is launched. This was a specific ask from @dgp1130 from the Angular team.

Additional details

Happy to discuss the visual implementation in more detail, but here are some before and after examples:

Newly available card (expanded) before (on old MDN front-end):

Newly available card (expanded) after (on fred):

Widely available card (default) before (on old MDN front-end):

Widely available card (default) after (on fred):

[LeoMcA]

Some interesting ideas, thanks for opening this PR: I'm going to convert to a draft for now though, because these changes need more discussion, most of it on the https://github.com/web-platform-dx/web-features level:

Include the Baseline year of the feature in the unexpanded view.
Make "Widely available" or "Newly available" chip formatting consistent and more prominent.

We experimented with design variations a little bit like this, but if memory serves we decided that for most users, once a feature becomes Widely Available, the year matters much less - and so demoted the year into the expanded view.

I appreciate the visual consistency here, but as a developer targeting Widely Available - and the aim of the definition is that most developers will - I'm not sure the inclusion of the date in the main banner tells me much I don't already know.

But, we've also found that developer understanding of the Baseline "brand" has evolved enormously since its launch, so perhaps even developers targeting Widely Available still find meaning in the year, and it is valuable to include it. @atopal perhaps we should do some user research here?

Adds a sentence providing the future Widely available date for Newly available features.

There's no guarantee that a feature will become Widely Available 30 months after it's Newly Available: it's merely a prediction, and there's a good chance that breaking bugs will be found in that time (as more developers start using it) which set the feature back, so we can't do this. @ddbeck am I remembering that right?

[dgp1130]

Thanks for putting this together @tonypconway!

Just for some additional context on this request, I recently switched Angular to use Baseline widely available (pinned to a specific date for a major release) as our browser support for that release. This revealed some challenges in the UX for working with these APIs and making sure our implementation is limited to widely available APIs. I wrote a doc where I tried to explain how to read this component to determine whether an API is usable, but it is IMHO more complicated than it needs to be.

I think my main feedback comes down to:

1. It's confusing that the "widely available" view shows the "newly available" date.
   • Might be somewhat separate from this PR, but honestly, it just feels like a UX bug. At minimum, could we says something like "newly available since ${date}" just to put the words "newly available" in there?
2. There is no indicator of when a "newly available" API is expected to become "widely available", requiring the manual +2.5 years addition.
   • This is important because most meaningful feature development happens on versions which haven't released yet, so we usually don't care about the current Baseline status of the feature, so much as the Baseline status on the expected release date of the current in-development Angular version.

We experimented with design variations a little bit like this, but if memory serves we decided that for most users, once a feature becomes Widely Available, the year matters much less - and so demoted the year into the expanded view.

IMHO the date is important to note somewhere, but I think it's fine to limit it to the expanded view. I agree in the mainline case, most developers are interested in the current Baseline status, rather than its historical status. Historical status does come up, for example, when modifying an Angular LTS release, we would care whether the feature was Baseline during that original release up to 2 years back. But I don't think it's a big deal to have to expand the view for that use case, so I don't have any objection to hiding the year in the simplified view.

There's no guarantee that a feature will become Widely Available 30 months after it's Newly Available: it's merely a prediction, and there's a good chance that breaking bugs will be found in that time (as more developers start using it)

Isn't that all the more important to call out the widely available date then?

I'm thinking we can mark it as an "estimate" since we ultimately can't predict the future. But also if it is delayed due to a browser bug in the newly available period, then it would be helpful to say that even the current estimate is actually further out than "newly available date + 2.5 years". I'm not sure if we have the data to effectively include that kind of information, but it feels useful if we can.

[ddbeck]

@atopal reminded me of this today on a call. Some notes from our (very brief) chat on this:

• Widely available features are intended to be kind of "timeless" (though I don't love the word). Ideally, once features are into their widely available era, most developers can begin to forget when precisely they shipped. As Leo points out, that's why we originally de-emphasized the date on the widely available banners.
• A large fraction of features have a somewhat arbitrary date where Edge became a browser (newly available in 2015, widely available in 2018). It's not that those features were actually widely available in 2018. In 2018, a great many developers still had IE in their support matrix.
• Similarly well-established features also have a date that's kinda… fuzzy. They're a little more art than I'd like them to be science. For some of the older features, I would say that the dates are heavily influenced by our (retrospective) selection of constituent browser compatibility data (BCD) keys and the underlying (lesser) quality of BCD for browser releases of that vintage.
• Taking those two points together, the older a feature is, the more its Baseline date is anachronistic. There ought to be some threshold where we more or less bury the date. Kadir and I suspect it's somewhere between 3 and 5 years after the newly available date.

[ddbeck]

Now I'll respond the predictions question, speaking only for myself here:

There's no guarantee that a feature will become Widely Available 30 months after it's Newly Available: it's merely a prediction, and there's a good chance that breaking bugs will be found in that time (as more developers start using it) which set the feature back, so we can't do this. @ddbeck am I remembering that right?

That's correct. That said, now that we've had more time to see features progress to Baseline and widely available, there's been both increased interest in predicted dates and more confidence in doing such a thing (see web-platform-dx/web-features#3117 for more on this).

I'd say that I'm open to the idea at this point (I would not have been 6 months ago), but I'd choose to delay showing a prediction on MDN for some months after the newly available date.

Based on the regressions we've seen so far, I suspect 6-9 months after the newly available date is the highest risk period for a regression. That's when developers start to use a feature and discover its non-obvious bugs. So you'd want to wait at least that long before estimating a date, but perhaps longer on MDN and shorter for a resource like webstatus.dev.

All that said, I have a few reservations about showing an absolute predicted date. Doing something to reflect the fuzziness of the estimate would be nice ("Expected to be widely available in about a year") and would give some breathing room to the web-features editorial process, which does have the option to override a status if there's a good reason to do it.

[dgp1130]

Agreed there's value in being less precise as we estimate further in the future to illustrate the uncertainty.

I also agree the widely available date becomes less important over time as the ecosystem just accepts the feature is supported "everywhere". In Angular's case, we support versions for 18 months, so outside of extreme scenarios, that's as far back as we would typically care.

However other products might have much longer support windows and might care about Baseline support several years back. Is there a concrete boundary we can identify which we would feel confident in which a Baseline date no longer matters?

Regarding the difficulty in identifying specific dates for old features, does that problem become less important over time? Certainly it matters now for the stuff that released in the last 3-5 years. But over the next 3-5 years, that window only covers features releasing in the future. So if we can identify precise dates for new features today as they release, those will become reliable historical dates we can use for future reference. Just one way of thinking about this problem.

[rviscomi]

For some additional context, the Chrome team is ramping up a campaign encouraging developers to take a closer look at their real-user analytics data to choose a Baseline target. Widely available should be a suitable target for most developers, but for some it may not be conservative enough and for others it might be overly conservative. In either of those cases, developers can target a more specific Baseline year.

MDN already supports the "overly conservative" use case by labelling newly available features with their Baseline year. @tonypconway's proposal would add support for the "not conservative enough" use case by more prominently displaying Baseline years on widely available features.

I agree with @ddbeck that most of these Baseline targets should be within the last ~5 years. One nice side effect of the Chrome campaign is that developers will be encouraged to share their targets publicly on social media, so we might get a nice sample of targets to see how well that assumption holds.

That said, I wouldn't rule out showing the Baseline year for even older features. That was the direction we took with the VS Code integration, which adds "Baseline since YYYY" to all newly and widely available features. If a developer is targeting a Baseline year and we did omit that info in some cases, they would need to know 1) it's not a bug, and 2) it means that the feature is older than X years, and 3) what the value of X is to be sure that it meets their target.

On a separate note, there was a suggestion in mdn/browser-compat-data#27115 to change how the limited availability Baseline card describes browsers that don't fully support the feature. Might be worth tackling that in this PR while we're at it.

[ddbeck]

That said, I wouldn't rule out showing the Baseline year for even older features. That was the direction we took with the VS Code integration, which adds "Baseline since YYYY" to all newly and widely available features. If a developer is targeting a Baseline year and we did omit that info in some cases, they would need to know 1) it's not a bug, and 2) it means that the feature is older than X years, and 3) what the value of X is to be sure that it meets their target.

Given some limitations in BCD (it represents some versions as, literally, ≤X some version number X), it wouldn't be meaningful to show dates before mid-2020 (circa Edge's Chromium switchover). That data is fixable, but it's not trivial to do it. See mdn/browser-compat-data#23991 for details.