search

GoogleChrome / webstatus.dev

A tool to monitor and track the status of all Web Platform features across dimensions that are related to availability and implementation quality across browsers, and adoption by web developers.
https://webstatus.dev
Apache License 2.0
76 stars 4 forks source link

Show baseline keystone and wide support dates as columns #348

Open mirisuzanne opened 1 month ago

mirisuzanne commented 1 month ago

As a developer and teacher, I'd love to see when something hit baseline - and when it's expected to achieve (or already has achieved) wide support. Being able to sort on that as a column in the table would be really useful.

jcscottiii commented 3 weeks ago

Hi @mirisuzanne,

Thanks for the suggestion.

We recently added the ability to see the newly-available baseline date (when all the major browsers support the feature). You can see it when hovering the baseline logo for a given feature. We only show it when hovering to reduce information overload.

The page is sorted by the newly available date by default. The widely available date right now is just newly-available + 30 months (code)

Would using the newly available date work for you?

mirisuzanne commented 3 weeks ago

Yeah, it can work. But having the main data I would use hidden behind a hover interaction and some math doesn't feel like I'm avoiding information overload - it just requires extra work to get the information I'm looking for. I think the hide/show-columns feature is a much better solution, and already in place. Since columns can be hidden by default, and turned on as needed, these seem like useful columns to make available in that interface – without adding to the amount of information shown by default.

jcscottiii commented 3 weeks ago

One limitation with sorting by widely/high available date is that many features haven't reached that 30-month threshold yet, resulting in null values. This means sorting would only show widely available features at the top, followed by all others with no clear order.

To achieve your desired outcome of seeing projected dates as well, you could request a change in the data.json from Web Features to include future widely available dates. This would avoid the need for us to duplicate the 30-month calculation (that could potentially change).

A lightweight option could be to add toggles within the existing "Baseline" column in the column selection dialog that you mentioned:

image

image

Since it does not rely on a new column with potential future high dates added in data.json, all of this could be handled in the frontend. We distinguish that is an estimate with "Projected" phrasing too. And maintenance is a lot easier (whereas future dates stored in the database might need to change.)

Let me know what you think!

mirisuzanne commented 3 weeks ago

That sounds like a great solution, thanks!