WebCompat Diagnosis Sidebar

[violasong]

Current design:

First round of testing needs

• Focus on this sidebar first, and adapt to the smaller UI of the toolbar tool later
• Reconsider the "list of issues" UI. Maybe a caniuse-style support table or friendly suggestions (e.g. use feature query to support browser xyz)
• Consider a browsing UI with search suggestions
• Encourage cross-browser testing
• Try to educate on how to use unsupported features in a safe way. How would the user go to MDN from here, to learn more about certain properties? would this show up on hover?
• Use version names (e.g. stable, beta, canary) instead of numbers
• Grouping for similar (or duplicate) warnings in the subtree [1]. (Should there be a way to expand the group? What would Learn More do?)
• Config screen is postponed to next round

Initial description

• Make it easier to discover and configure Open in Browser feature
• Make the browser version links more obvious
• Use MDN in the wording/visuals
• Messaging to show that a perfect score does not mean a compatible website (e.g. Lighthouse includes disclaimers like, "Only a subset of accessibility issues can be automatically detected so manual testing is also encouraged.")
• Integration with Unified Layout

[dadaa]

This is a screenshot of current prototype.

[violasong]

Thanks!

It occurred to me that I've borrowed the Selected Node/Whole Document pattern for unified layout panel :D. Will have to match up the two designs.

[violasong]

[violasong]

WebCompat sub-elements: listing the names of those elements, with disclosure UI for multiple occurrences

[SebastianZ]

I love seeing web compatibility info finally coming to the DevTools! As a former Firebug developer, I can say that this was one of the most missed features when the Firebug extension called CodeBurner stopped working.

A few notes from my side regarding the mockup and the prototype implementation:

• Always link the feature with the appropriate MDN site, so authors can read about it (probably even when it doesn't exist yet and let the MDN team know about it, so it gets created).
• Always try to provide a "Learn more" link with an explanation and a fallback/workaround/alternative, in some cases you may even provide a hint right there (either inline or, if you think this might clutter the UI too much, behind a toggle; e.g. "clip is deprecated and not supported in iOS Safari. Use clip-path instead. Learn more" [Well, clip-path has its own caveats, but that's another point.]).
• I love the idea in the mockup to be able to highlight the affected elements on the page!
• Always use " isn't supported in " instead of " doesn't support ". It's the browser not supporting a feature, not the feature forbidding the browser to be used. 😉 (only in mockup, screenshot ok)
• If possible, for one-browser-only features say " is only supported in " instead of "<feature isn't supported in " (like "-ms-flow-from is only supported in IE and Edge.")
• Try to be smart about showing the hints.
  • Don't show a hint if the author uses a feature that's lacking support in some browsers but it's placed within an @supports rule checking whether it's supported.
  • If the author already uses a fallback for a feature that is only supported in a few browsers, don't show the hint but, if possible, do show one when the fallback is not needed anymore. (E.g. there should be a hint when using display: grid that it's only supported prefixed in IE and Edge up to version 12, but not when it's used along with display: -ms-grid as a fallback for them.)
  • Similar to the above, only show the hint for the fallback feature if that's also not supported everywhere or adjust it accordingly (e.g. if clip is used alone, show a hint that it's deprecated and not supported everywhere, if it's used alongside clip-path, show only a hint for that but not the one for clip, and if clip-path is used alone, show a hint that it's not supported in IE versions before 10. (This point probably needs more discussion, though.)
• Regarding version names vs. version numbers, I slightly tend to numbers, because it's more precise data and you don't have to worry about updating the info once a new browser version ships. Which numbers to show by default is hard, though. The last three like in the screenshot might be ok, I guess.
• Looking at the screenshot, browsers should be separated by commas and between the name and the opening bracket for the versions there should be a space.
• Looking at the mockups and screenshot, it seems they are linked. What do the browsers link to?

Sebastian

[violasong]

Hi Sebastian, thanks for all the great feedback! :D Will keep this in mind as I work on more iterations.

Regarding hints: We're investigating solutions for this. They're not currently in the WebCompat data but we may be able to add them in the future. That's a good point about not showing warnings for @support and fallback situations.

Re: Linked browsers: You'll be able to click those links to open the page in those browsers, after you've configured your browser paths in the settings.

We'll indeed be linking to MDN whenever and wherever it makes sense :). (This is a general goal for all of DevTools)

[SebastianZ]

Regarding hints: We're investigating solutions for this. They're not currently in the WebCompat data but we may be able to add them in the future.

I know the web compat data currently doesn't include this information. Question is whether it should. I can open an issue there to start the discussion if you didn't discuss this internally with the MDN team yet.

Re: Linked browsers: You'll be able to click those links to open the page in those browsers, after you've configured your browser paths in the settings.

Great idea but hard to implement and for mobile devices probably impossible, I assume.

We'll indeed be linking to MDN whenever and wherever it makes sense :). (This is a general goal for all of DevTools)

Perfect! Let me know once the implementation begins and I can help creating the pages and data if needed.

Sebastian

[violasong]

I know the web compat data currently doesn't include this information. Question is whether it should. I can open an issue there to start the discussion if you didn't discuss this internally with the MDN team yet.

Thanks, I've started chatting with them. This is out of scope for our first testable product but would be amazing to add later.

We'll indeed be linking to MDN whenever and wherever it makes sense :). (This is a general goal for all of DevTools)

Perfect! Let me know once the implementation begins and I can help creating the pages and data if needed.

Awesome! I don't have a good understanding right now of know how much content would actually need to be created on MDN itself, but maybe @martinbalfanz has thoughts on this.

[violasong]

Latest version - starting to show more detail, including expanded "occurrences" sections. It's feeling a cluttery at the moment, but will keep at it. Am experimenting with ways of showing the warnings more compactly. There may be other ways to simplify as well.

Clicking on the property names would take you to MDN, so no need for lots of Learn mores.

[violasong]

Next steps: Research and testing needed to learn:

• How folks choose the browsers they test for
• When the the chosen browser list gets updated
• How much customization most people will need when using this tool
• If we were to set a default, how many browser versions back do we want to go? etc

[violasong]

New prototypes! https://github.com/firefox-devtools/webcompat-helper/releases

Currently undergoing user testing.

[violasong]

Initial prototype tests had positive and useful results! A bug has been filed to integrate the extension into DevTools.

[violasong]

Next steps

• Update latest mockup with simplified names, browser icons
• Settings panel
• Explore a better experience for All Issues
• Explore inline warnings

[violasong]

An early version of this is now available in Nightly by flipping devtools.inspector.compatibility.enabled!

Shows info for current element as well as all elements.

Will work on more testing and polish. Also, need to try coloring the icons.