Regression: New browser-compatibility table format is less helpful

[MichaelAllenWarner]

The browser-compatibility table now displays just a checkmark if any version of the browser has adopted the feature in question, and you have to click the checkmark to see which version was the earliest to adopt it. To be frank, this makes the table useless—developers now need to click every checkmark to glean the information they're looking for.

Please go back to the old way of displaying the earliest version to adopt the feature.

[Rumyra]

Thanks for the feedback and suggestion @MichaelAllenWarner - I'm going to move this issue to our feedback repository where it will get triaged 👍

[DannyFeliz]

I came to this repo to post exactly the same thing, now it is just not clear, but I'm glad you are considering 👍🏻

In the meantime, you can use https://caniuse.com to see the compatibility table as before.

[mjw-pp]

Please bear the following in mind:

• Firefox ESR versions exist
• Safari is not an evergreen browser

I've no doubt it's possible to do better than the previous design of this table, but I think it would be most helpful to revert to something equivalent to the previous design while you work out what's best.

[jrochkind]

One of my top uses of MDN, and i agree the redesign is a significant loss of utility. (And that there are definitely possible redesigns that would improve utility, but this wasn't it!)

[ConcernedHobbit]

A great example from HackerNews: The dialog browser compatibility chart shows support for Firefox with a checkmark, leading developers to believe it is already supported. However, support is shipping in FF98, which has not been released.

[alexkrolick]

Another thing is that old design was screenshot-friendly. You could see all the version info in one go and paste it into a conversation. Now, since expanding one box collapses the current selection, you can't do that.

[arxpoetica]

Came to just say the loss of color on the compatibility table makes it harder to scan. Green/yellow POPS (Hello, Wordle). Please add color back too.

[queengooborg]

I'd have to agree with this -- while a checkbox, X, flask, etc. is much cleaner than numbers, it's a lot less helpful as well. Additionally, the varying colors helped a lot with determining wide browser adoption at a glance. I'd love to have the original tables brought back.

[gilmoreorless]

A while ago I raised https://github.com/mdn/kumascript/issues/1384 in the now-archived predecessor to this project. I had been contemplating re-raising it here before the UI revamp. But I'd much prefer to have the previous display tables back (including that slightly misleading display) than the current simplified view.

Others have already stated some of the problems here, which I also agree with. For me the biggest thing is that the old display of versions conveyed a lot more information than a simple "yes/no" binary question.

To show a solid example, the Intl.DateTimeFormat options:

In the old design, I could see at a glance that the dateStyle option was fairly-well supported. But the dayPeriod option, although supported, was much newer and may not actually be available to all of my end users. See https://css-tricks.com/evergreen-does-not-mean-immediately-available/ for why this distinction is still really important, even in a world of auto-updating browsers. It also shows a Node.js version of 12.9.0 — that minor version number is crucial information, as just running "Node 12" doesn't guarantee you have the option available.

By contrast, this is what the page looks like today:

All of that extra contextual information is gone, leaving me clicking box after box after box after box to work out if I actually can use the feature. And on my 13" laptop screen, the last column is completely cut off due to the fairly limited space of the centre column in the new layout.

---

Also on that support table, backing up what was mentioned in https://github.com/mdn/yari/issues/5366#issuecomment-1055701516:

Looks like good support in Safari for these options (6th column of icons). Now let's check which versions just to be sure...

That last item has a key difference that should be more visible. And at the time of writing, Safari 15.4 hasn't even been released yet.

[pleunv]

Also baffled by the removal of the numbers on the default view. I think both the version numbers and the background colors are just too valuable to hide and/or remove.

Quite frankly, even the browser icons add to the "glanceability" because you don't have to read the browser name, which is vertically positioned and not easily readable anyway. Additionally, the icons remain in your peripheral vision when scanning the numbers and remain largely distinguishable due to their visibility, which is helpful. Less is definitely not more here.

[HerminaC]

Thanks everyone for the feedback - we'll address this before the end of the week. @schalkneethling - let's use this ticket to track the BCD work

[j-f1]

Another bit of feedback (let me know if this should be a new issue): features incorrectly say they’ve been “removed“ if a browser goes from partial to full support. Example: Notification.requestPermission in Safari

[debiru]

I am one of the MDN contributors, and I am feeling inconvenienced.

I understand that this will be supported, but one thing I would like to add is that when making such a design change, I would like to see the ability to revert to the previous design on a per-user basis at the same time. This problem has already been a hindrance to my work as an MDN contributor.

[schalkneethling]

That sounds like a separate issue.

[schalkneethling]

I am one of the MDN contributors, and I am feeling inconvenienced.

I understand that this will be supported, but one thing I would like to add is that when making such a design change, I would like to see the ability to revert to the previous design on a per-user basis at the same time. This problem has already been a hindrance to my work as an MDN contributor.

I am really sorry to hear that @debiru. We are working on giving you a way to switch back to the table showing version numbers and have it stick across page loads and navigation.

[yume-chan]

The old version looked like this:

They have same data, but the new view displays them in a confusing way.

"Removed in 15 and later", "Partial support", "Only supported the deprecated callback syntax." are notes of the old implementation in Safari 7~15, but now it's separated.

Secondly, I don't know how multiple entries in BCD are sorted, but I naturally expects top to bottom as time goes.

[fiji-flo]

I've been digging into this. Bringing back the old BCD tables triggers a lot of issues. We do plan to solve this in the future and make BCD tables better then ever.

I personally agree 100% that the old design was better then the new one, but let's figure out how to move forward. I have a proposal for a small change as an interim fix. There's two things I focused on. Bring back the version numbers as there's many reasons developers wanna see them like, ESR, and the fact that a lot of us have to support >3 versions and not just the release that landed yesterday. The other thing I wanted to finally solve is make it more accessible to people with various degrees of colorblindness, that's why the ✔️ and ❌ are icons are still in there along side the version numbers. I plan to hide it behind a toggle for now waiting for feedback and potentially use it as default and remove the toggle.

That being said, we do plan to really improve and fix BCD substantially but we wanna get it right and get some feedback while figuring it out so this is just an interim solution.

[MichaelAllenWarner]

@fiji-flo

I certainly think that that would be an improvement over the new version-less table.

That said, the old table also had asterisks and clickable-arrowheads that would let you know if a given cell came with additional information that a developer might need to know (e.g., about partial support). Without those indicators, the (diligent) developer still will have to click on each and every box in a row to rule out "more-important-information" scenarios before confidently using the feature in question.

I'm curious: were there complaints about the old table? I ask because this strikes me as a case of trying to fix something that wasn't broken. I love the idea of tweaking the colors to improve accessibility, but of course that could have been done without removing all (or any) of the useful at-a-glance information.

Thanks for digging into this so quickly, by the way.

[nschulzke]

@fiji-flo, something to keep in mind with this whole redesign project is that these docs are for a demographic for whom function is infinitely more important than form. Most of us use CLI apps on a regular basis. If you look at pretty much every popular developer tool, you'll see that information density in particular is extremely high as compared to more consumer-grade applications. With that in mind, the direction this redesign has taken runs entirely contrary to the actual goals of developers.

Focusing on my personal usage of this specific table: I would often spend all of a half second looking at it before making a decision. All green? Go for it. All green except IE? Go for it. All green except that Firefox has an asterisk? Let's check that asterisk. The old design wasn't "pretty" by modern standards, but it was exceptionally well-planned for that workflow.

The fact that the full box was colored in allowed identifying incompatibilities at the speed of thought. No need to scan the table and check all the icons, if there was red, you knew it. The asterisk, the "show more" arrow, and the red X were huge and obvious. They immediately drew the eye because they were the only icons present in the table. In the new version, the color is isolated to the text and icons themselves, and all these check boxes distract from what I actually want to know. I'm not interested in which browsers do support it, I'm interested in how many don't.

With the old version, when I found an incompatibility, I could scan right up to the top and instantly recognize the browser by its icon. Now I have to read sideways text to figure out which browser is incompatible. There are superfluous check icons where none were needed, but you guys stripped out icons where they were actually useful.

As for accessibility, the old design seems to have been plenty accessible. Taking a screenshot from earlier in the thread and running it through color-blindness.com's simulator, I can immediately pick out all the important details in every single mode. Even when in full monochrome (attached below), the only thing I might say is you could probably increase the contrast on the X.

The new table is prettier, I'll give you that. But MDN is a tool used by working developers on a daily basis. A stepladder doesn't need to be pretty, a hammer doesn't need to be pretty, a set of pliers don't need to be pretty. They need to save us time. In some cases pretty is the enemy of useful, and when that is the case, a tool should always choose to be useful. Please, as you work on redesigning the redesign, make it functional, not pretty.

[debiru]

A change in design can lead to dissatisfaction from two perspectives.

One is that it is absolutely inconvenient. The other is that it is relatively inconvenient. The latter, in other words it is a matter of accustomedness. In the past, when the MacBook keyboard design was changed, there were also complaints. However, it is now accepted.

Is your dissatisfaction with this design change a matter of accustomedness? I don't think so. So what went wrong? We need to think about that carefully.

What I am trying to say is that even a new design table with a clearly marked version may be complained about at first. But I think that is a matter of accustomedness. I look forward to improvements in essential areas.

[ddbeck]

Hey folks, I just wanted to reiterate that we're appreciative that you've all come here to share your concerns and offer suggestions. It would be much harder to fix these issues without your help.

To provide some additional background, we redesigned the compat tables to address some known issues with the former design. We had evidence that some readers were misunderstanding the former tables (e.g., not recognizing version number as version numbers, wrongly inferring other meanings) or ignored the numbers outright. Some of that evidence was direct (i.e., observed in usability testing and reader interviews) and indirect (e.g., bug reports for valid, confirmed compat data).

That evidence led us to overcorrect in the new design. It has inconvenienced a lot of you in the process. We're sorry about that. We're planning to ship some incremental improvements to the design this week (perhaps as early as tomorrow).

But we're not going to stop there. Now that we have a better idea of how readers are using the compat tables, we're going to take another look at how the whole page—not just the tables—can support MDN readers in understanding compatibility. That work is going to require a lengthier research, design, and implementation process, but this time it'll be based on a more complete and accurate picture of how you're using MDN.

[romainmenke]

Thank you for the update!

Would be awesome if the current effort to resolve visual issues could also immediately address accessibility concerns.

My concern is that the current implementations is very inaccessible and that resolving it might also have design implications. Choosing the right patterns for accessibility first will prevent another re-design later :)

[caugner]

FWIW The version numbers have been restored via #5477 (shortly after the redesign), so I will go ahead and close this issue. 🎉

I don't know how multiple entries in BCD are sorted, but I naturally expects top to bottom as time goes.

@yume-chan FYI BCD history is now sorted chronologically (resolved via #5649).

the old table also had asterisks and clickable-arrowheads that would let you know if a given cell came with additional information that a developer might need to know (e.g., about partial support).

@MichaelAllenWarner FYI Symbols for notes, alternative names and prefixes have been restored. Kudos to @danielhjacobs for working on this.

My concern is that the current implementations is very inaccessible and that resolving it might also have design implications. Choosing the right patterns for accessibility first will prevent another re-design later :)

@romainmenke FYI We have addressed one accessibility issue regarding a duplicate focus point in the feature cells via #5648, and #5710 will address some remaining accessibility issues with the website in general.

If you find any remaining accessibility issue with the BCD tables specifically, please don't hesitate to open a new issue for this. 🙏