Show baseline keystone and wide support dates as columns

[mirisuzanne]

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]

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]

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]

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:

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]

That sounds like a great solution, thanks!

[dlaliberte]

Currently, the sorting of columns is only indicated and specified (by the user) in the column header. With these two new "columns" being nested inside the baseline status column, we need some UI changes to indicate which date is used to sort the column, and to specify which value to sort by.

I think it would be simpler, easier for the user to understand and interact with, and easier to implement, if we just replaced the one column with two, one for "Newly available" showing that date, and one for "Widely available" showing that date. Then it would be straightforward to select either column or both columns for the display, and sort by either one.

These two dates are also partly redundant with the tooltip we display when hovering the baseline status for a feature. Maybe we can drop that tooltip.

[jcscottiii]

Thanks for your thoughts, @dlaliberte!

To clarify, my original vision for this feature focused primarily on making the baseline and projected widely available dates easily visible to the user, as per their request. I didn't initially intend for these fields to be sortable for a couple of reasons:

Reason 1:

We don't store projected widely available dates. Instead, we only store the given widely available dates from the web-features repository. And that's another reason I would use the verbiage, "Projected", for those without widely available dates.

Without that data, we will run into the problem I mentioned earlier.

If we want to store projected widely available dates, I would want to be consistent and have the data come from the web-features repository. Which means we need to open an issue there for this change. This is because if the offset of months ever changes, it will be simple change that does not require us to do anything. Instead, the source of truth will change it for us.

Reason 2:

Given that the widely available date is generally an offset of the newly available date, sorting by either column would likely yield similar results (assuming we get the projected dates from the web-features repository). This might feel redundant to some users.

---

Final thoughts

If the web-features repository is updated to include projected dates, I'm open to revisiting the sortability of these columns in a future iteration.

I agree with your suggestion to remove the hover tooltip in any of the proposed solutions. It seems like an unnecessary duplication of information.

Providing a user-friendly toggle to display the dates within the baseline column (using the existing columns popup or an alternative approach) should suffice in the short term and keep the solution lightweight enough for future changes.

Let me know if you have any other questions or suggestions!