BCD "In the Wild": BCD Explorer Webapp

connorshea · May 4, 2018, 5:24pm

Hey all, I’ve been working on an open source Rails app I call the MDN Browser Compatibility Data Explorer.

The source code is available on GitHub and I’d be happy to take any feature suggestions/improvements/bug reports, either in this thread or in the issue tracker

What does it do?

The Explorer lets you “explore” the data from the mdn-browser-compat-data repo with search functionality, and also visualize the data with some graphs.

Right now there are three main pages: Browsers, Features, and Graphs.

Browsers

The browsers page is a list of all browsers in the dataset, along with browser versions, release dates, and release notes.

I’m looking into adding a list of features added for each release of a browser, which would be useful for comparing official release notes with the data tracked by the browser-compat-data repo.

Features

The features page has support tables (based on the ones used on MDN) and other info for every feature in the dataset, as well as search functionality.

You can use the search to find all the features that don’t have an MDN URL, that don’t have a description, or that are marked as experimental, for example.

The features page after its been filtered down to JavaScript features that have no MDN URL.

Graphs

Right now the graphs page only has visualizations for feature support in each browser, e.g. it tracks how many features are listed as supported, unsupported, unknown, and how many have no data for a given browser.

If you have ideas for other visualizations that can be done with the data, I’d be happy to hear them.

What’s the purpose?

I made this because I wanted to explore the dataset visually, and also in the hopes it could be used to more easily find problems and blank spots in the data. If you have any ideas for features that would help with either of those, you can reply here or open an issue, I’ll try to respond to any issues people open!

I also used it as an excuse to get better at Ruby on Rails

Can I contribute?

I’d love to have contributions! I tried to make it easy to get started, and instructions for setting the app up locally are in the README. Even if you don’t know Ruby/Rails, you can probably help with the CSS or JavaScript

Of course, you can also contribute indirectly by improving the browser-compat-data repo, which I definitely encourage!

TL;DR

I made a website that you can use to look at data from the mdn-browser-compat-data repo. It has search and some pretty graphs, and it’s also open source.

It’s still unpolished and has some issues, but I hope people find it useful!

sheppy · May 4, 2018, 9:15pm

This thing is nifty as all get out.

atopal · May 11, 2018, 4:05am

Hey Connor. This is absolutely fantastic! Thank you! Regarding the graphs: It would be great if you could see a list of the features after clicking on the status. For example, clicking on the “true” value for Chrome, should list all the features that have that value. That would allow maintainers to address those issues.

connorshea · May 11, 2018, 4:24pm

hmm, I’ve considered adding search filters for browser statuses, e.g. search for all features where Chrome is true.

What level of granularity do you want here? Do you want to be able to filter down to only the features that list Chrome as true, or do you want any that are truthy, e.g. true, but also 58, 59, etc.

atopal · May 11, 2018, 6:35pm

I had put together a spreadsheet at the Hack on MDN event that the Microsoft team used to drive down the number of “true” values. So, just being able to filter on the value is fine.

jswisher · May 11, 2018, 6:52pm

In other words, the use case for filtering on “True” is to look for places to replace “True” with a version number. There may be other use cases, but for that one, filtering on exactly “True” is what’s needed.

connorshea · May 11, 2018, 9:22pm

@atopal @jswisher Does this work? It lets you filter to True (which includes version numbers) or “Exactly true”, which is only true values. I considered naming them True and Truthy, but I think this is easier to understand.

atopal · May 13, 2018, 11:50pm

Yes, that works indeed!

connorshea · May 14, 2018, 8:45pm

I just released v0.4.0 with a bunch of changes. You can see them on the live site now.

Notably:

Filtering by browser status (e.g. filter down to features where Firefox is exactly true or where Chrome has no data) on the search page.
A “Search on GitHub” link for feature cards, it searches for the feature in the browser-compat-data repo.
Create pages for each browser, list all new features associated with each release.

So now you can see exactly what features were added in a given version of Chrome on this page. I see this as being useful when comparing changelogs to the features tracked in the dataset.

The “Search on GitHub” links are useful for finding the source file for a given feature, and it works a lot better than I expected. This is particularly useful for quickly correcting errors if you see them on the features page.

This also updates the search page to allow for filtering by feature status in a given browser. It should make it easier to find holes in the dataset.

Hopefully this makes the tool more useful to everyone

atopal · May 15, 2018, 11:58pm

Thank you Connor! I guess I can retire my scripts

sheppy · May 16, 2018, 9:36pm

I’d love it if the names of things got decoded into standard syntax; that is, instead of api.TextTrack.removeCue you’d see TextTrack.removeCue. Ideally, actually, TextTrack.removeCue() since it’s a function, but there’s no way to know that that I can see at a glance at the JSON in the BCD repo.

Sheppy

connorshea · May 17, 2018, 7:18pm

Unfortunately I don’t see a good way to do that unless I do some weird hackery or try to get the page title from MDN for every feature, and I imagine the latter would have plenty of its own issues.

I could also get some of the way there by mapping out the directories, e.g. api, css, css.selectors, etc. but that’d require a lot of manual upkeep. It’s probably possible to go through the data with a script and find all the feature segments that aren’t features themselves (api, css, css.selectors, etc.), and then cut those out, but I’m not sure that’d be worth the effort right now.

Maybe the data set should have a name property? That’s kind of what description is being used for with a lot of the data

sheppy · May 17, 2018, 8:50pm

At least for some of the stuff, you can easily determine what the final text should be.

For CSS, just drop the “css.(whatever).” part of the feature’s ID string and wrap the rest in <code>. The “(whatever)” identifies what part of CSS you’re looking at, if you need that information.

Identify HTML elements by an ID starting with “html.elements.”; remove that and wrap the remaining in "<code><...></code>".

For APIs, just drop the leading “api.” to get the interface name and possibly a member name. If there’s a period left anywhere, that separates out the interface name from the method or property name. Pull them out and you’re done.

Sheppy

connorshea · December 22, 2018, 10:30pm

Another update on this project:

I ended up getting stuck on v0.0.45 for a while because I wasn’t paying for Heroku, and they limit you to 10k rows in your database (0.0.45 was the last release before this limit was hit), but today I’ve updated to a basic Heroku plan so I can have up to 10 million rows

The application is now updated to the latest version, v0.0.61, and will be up 24/7 from now on! https://mdn-compat-data-explorer.herokuapp.com/

sheppy · January 2, 2019, 5:16pm

Hurray! That’s great news, @connorshea! I look forward to seeing it move forward again!

exe-boss · January 2, 2019, 9:00pm

Now if only version 0.0.61 could be pushed to MDN (which is still on version 0.0.60).

connorshea · May 2, 2019, 5:04am

And now it’s on 0.77.0! (just in time for 0.78 to come out tomorrow :P)