Show only one browser per engine in the default view

[jgraham]

The default view currently shows two blink based browsers, one gecko browser and one webkit browser. This doesn't seem particularly helpful to anyone. For people trying to compare engines, having two copies of any particular engine is adding noise in the form of extra columns to skip over, rather than value. For people working on specific browsers embedding a given engine the most informative view will often be differences with other implementations using the same engine; that requires a non-default query anyway since the default view will show far too much in the way of similarities to be useful for spotting differences.

I think the same argument applies to a single engine running on multiple platforms i.e. once we have mobile results I think putting those on the default view will be largely unhelpful even though the difference between desktop and mobile can be larger than the difference between different browsers with the same engine on the same platform.

If you feel there needs to be a rule to follow on what's in the default view, I'd suggest either a) the browser with a specific engine for which the results are most reliable, or b) the higest marketshare browser with a specific engine in cases where there isn't a significant difference in reliability.

[foolip]

@thejohnjansen @mustjab can you weigh in?

My calculus has been roughly that if Edgium isn't on the front page, then Microsoft engineers might not know the runs exist and be less interested in looking at wpt.fyi. And that for similar reasons Microsoft would be less keen to keep the runs reliable and sponsor the extra Azure Pipelines VMs if the results aren't really visible.

That being said, I do agree that 3 columns is the more useful view, and I often go in and remove Edge from some view when it's cross-engine interop issues I'm after.

If we start getting reliable results for WebKitGTK or some mobile browsers we'll be forced to grapple with a very similar issue: how to make runs discoverable without them being the default view.

One thing we could experiment with is the http://wpt.fyi/ front page to give people an overview that isn't just a redirect to /results/, and there you'd have room to feature the configurations available and maybe also plug some of the good stuff in /interop/ and /insights/.

[thejohnjansen]

I'd like to explore the idea of a redesign of the landing page, rather than focus on three vs. four vs. 8 column layout. I'm in no way convinced that 3 is better than 4, for example. In fact, for my workflow (and that of Microsoft in general) the most interesting view is Chrome and Edge with the Diff showing. That is the view that we need more than anything. Granted, that's an implementer's view, not a web-developer's view, but I think the design should be focused on user scenarios. For web-developers, I think the most interesting views are those that show differences, not views that show everything. The places where all engines pass all tests (or fail all tests) are not very interesting at all.

What do you think for a timeline for designing a new landing page?

[Hexcles]

I'm open to the idea of redesigning the landing page!

One thing we could experiment with is the http://wpt.fyi/ front page to give people an overview that isn't just a redirect to /results

Could you elaborate a bit more, Philip? I can't quite picture the "overview" off the top of my head. Also, John, do you have any thoughts for a redesigned landing page that would bypass the debate of default browser selection?

[jgraham]

Note that even redesigning the landing page doesn't address all of the issue. If I get a link like https://wpt.fyi/results/?aligned&q=flex-basis or https://wpt.fyi/results/css/css-flexbox/flex-basis-001.html that also has some default set of browsers that are shown. And note also that that set is already not the full set for which we have results (it defaults to "experimental"-only). So I think that redesigning the landing page is possibly good but doesn't fully address the original issue.

In fact, for my workflow (and that of Microsoft in general) the most interesting view is Chrome and Edge with the Diff showing.

This supports the fact that the default view already isn't useful if your primary use case is about differences between browsers running the same engine, so it doesn't make sense to include multiple copies of the same engine on the default page.

[thejohnjansen]

This supports the fact that the default view already isn't useful if your primary use case is about differences between browsers running the same engine, so it doesn't make sense to include multiple copies of the same engine on the default page.

I disagree. I think the default view should be ONLY a diff of the engines that we run with a single-click solution for removing engines we don't care about at that time. But as I say: I think this needs design work, not something that should be designed in the comments section.

[foolip]

@jgraham you're right of course that there has to be some default set of browsers, if nothing else then to keep existing links working.

Because we already have some configurations we don't show by default and will gain more (WebKitGTK, probably some Android browsers) soon we'll need to make those easily discoverable.

@Hexcles I was thinking a page with no results table but rather a few different sections/cards/widgets to guide people towards the most useful and common views we have. Maybe one widget for stable desktop, one for stable mobile, and so on, and maybe there being able to select or unselect browsers before going to the view, like a trimmed down query builder. (You could imagine highlighting new features and such too.)

If it is very simple to get to your favorite view from the landing page, very simple to select/unselect browsers, and we encode the chosen browsers in the URL even for our defaults, then I think most of the tension between what people are interested in goes away.

[thejohnjansen]

I was thinking a page with no results table but rather a few different sections/cards/widgets to guide people towards the most useful and common views we have. Maybe one widget for stable desktop, one for stable mobile, and so on, and maybe there being able to select or unselect browsers before going to the view, like a trimmed down query builder. (You could imagine highlighting new features and such too.)

I was typing up almost exactly this. Pretty much starting with the "Interoperability" tab so all the text on top, but in "Edit" mode with n browsers as choices to add to a view that then gets created when you click "Submit"

[thejohnjansen]

Maybe we can design it in the comments. :-)

[jgraham]

To be clear the browsers we currently run are:

• Firefox Desktop Stable
• Firefox Desktop Beta
• Firefox Desktop Nightly
• Chome Desktop Stable
• Chrome Desktop Beta
• Chrome Desktop Dev
• Safari Stable
• Safari Preview
• Edge Stable
• Edge Dev
• Edge Canary

And by the end of year we hope to also be running at least:

• WebKit-gtk Nightly
• Firefox Android Nightly
• Chrome Android tbd

A table with 14+ columns as the default view doesn't seem useful to anyone. So some decision has to be made about what to show by default and in each view in some future iteration of the UI.

I fully agree that some UI to switch between common use cases is a good idea; a <select> with options like "Latest desktop browser engines", "Chromium Variants", "Latest Mobile Browser Engines" etc. seems like a totally reasonable idea. And I think the value should be sticky so if all you care about is the Chromium variants view that's what you get each time. But it's scope creep to insist that it has to happen to solve this bug.

[foolip]

The only immediate thing we could do to resolve this bug is to drop Edge from the default product set and require using the "EDIT" button to add the column back. Some folks working on Edge say the results are useful, and deleting is quicker than adding, so I think that'd be a shame.

While some view will always be the fewest clicks away and we do have to decide what that is, if we start encoding the selected products in the URLs, then I think there will be a lot tension around what's preselected in a widget on the wpt.fyi landing page.

FWIW, the view I think should be the fewest clicks to reach is experimental Chrome+Firefox+Safari. This would be achieved by "experimental desktop" being the most highlighted view on the landing page, with Chrome, Edge, Firefox, Safari and WebKitGTK being toggle buttons, and Edge and WebKitGTK being deselected by default. Making the chosen state sticky for the front page seems like a good idea.

@thejohnjansen do you think that would be acceptable, to require two clicks to get to a view that includes Edge Dev?

@jgraham if we can get this done in Q4, would that be acceptable?

[thejohnjansen]

do you think that would be acceptable, to require two clicks to get to a view that includes Edge Dev?

Yes, I think that is acceptable as an interim solution, but I don't think that is the appropriate long-term default view we should aspire to.

[lukebjerring]

One thing that is worth mentioning is that for the purposes of attribution for metadata changes, we're creating a GitHub OAuth login flow (which bubbles down to a "User" concept). "Favorite queries" is a pretty simple concept to add once users are a thing, and would mean that we don't need to agree on a one-size-fits-all to the same degree.

[foolip]

@Hexcles and I discussed this a bit today, and while designing in the comments worked above expectation, it's probably best to use the RFC process for this. I think it'd be easier to communicate some of the options with mockups, after tinkering a bit to see what feels OK.

[thejohnjansen]

+1 Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Philip Jägenstedt <notifications@github.com> Sent: Thursday, October 3, 2019 3:51:50 PM To: web-platform-tests/wpt.fyi <wpt.fyi@noreply.github.com> Cc: John Jansen <John.Jansen@microsoft.com>; Mention <mention@noreply.github.com> Subject: Re: [web-platform-tests/wpt.fyi] Show only one browser per engine in the default view (#1519) @Hexcles<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHexcles&data=02%7C01%7CJohn.Jansen%40microsoft.com%7C4fa749ee8ccc450e99fd08d748544795%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637057399125058387&sdata=YhqruspsXTojnuVD05BErWLlAYQFVc7clKPGxEIIEvs%3D&reserved=0> and I discussed this a bit today, and while designing in the comments worked above expectation, it's probably best to use the RFC process for this. I think it'd be easier to communicate some of the options with mockups, after tinkering a bit to see what feels OK. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fweb-platform-tests%2Fwpt.fyi%2Fissues%2F1519%3Femail_source%3Dnotifications%26email_token%3DAAQFK76CV7A2YWPHLILZ4EDQMZZQNA5CNFSM4I4H45KKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJ2RDY%23issuecomment-538159247&data=02%7C01%7CJohn.Jansen%40microsoft.com%7C4fa749ee8ccc450e99fd08d748544795%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637057399125063378&sdata=HJiH5YGx8%2FttV2gP9pp4mNURECYaRfLTdakyvyBF3Ac%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAQFK73VVLL3ONHTF2DAQ5LQMZZQNANCNFSM4I4H45KA&data=02%7C01%7CJohn.Jansen%40microsoft.com%7C4fa749ee8ccc450e99fd08d748544795%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637057399125068370&sdata=loq42rG9PpCKb%2FvNIu%2FKpYejCbkXunx64KNcJBbCgLU%3D&reserved=0>.