[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

report: map metrics to audits #11732

Merged
merged 6 commits into from
May 17, 2021
Merged

report: map metrics to audits #11732

merged 6 commits into from
May 17, 2021

Conversation

paulirish
Copy link
Member
@paulirish paulirish commented Dec 1, 2020

Adds a little filter control so the audit list in Performance can be filtered by what's relevant to each metric.

➡️ See an interactive demo here: https://lighthouse-git-mapping-googlechrome.vercel.app/english/

The UX is ~inspired by the AMP page exp tool.

image

Addy's doc: go/cfspg
ref #11279


image


@google-cla google-cla bot added the cla: yes label Dec 1, 2020
@patrickhulce
Copy link
Collaborator

Sweeet! So glad we're starting down this path 🎉

My primary concern with adding the filter without reworking the opportunity display is that it seems like it suggests the impact number is for that metric. Maybe it's mostly just a wording issue? "Filter be relevant metric:" would be a step in the right direction. Another quick alternative on my mind is removing the time estimate in the opportunity section when filtered.

Other piece that stood out is the empty opportunities for most on TBT and CLS and how we can increase the prominence of diagnostics in those cases.

@paulirish paulirish added the 7.1 label Dec 14, 2020
@paulirish paulirish added the P1 label Feb 11, 2021
@paulirish paulirish self-assigned this Feb 11, 2021
@paulirish paulirish removed the 7.1 label Feb 11, 2021
@paulirish paulirish removed their assignment Apr 1, 2021
@paulirish paulirish marked this pull request as ready for review April 1, 2021 20:31
@paulirish paulirish requested a review from a team as a code owner April 1, 2021 20:31
@paulirish paulirish requested review from connorjclark and removed request for a team April 1, 2021 20:31
@paulirish
Copy link
Member Author

I've given this a few updates. It's ready for a look. Description was updated with all the goodstuff.

* @param {LH.ReportResult.AuditRef[]} filterableMetrics
* @param {HTMLDivElement} element
*/
renderMetricAuditFilter(filterableMetrics, element) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be in report ui features (like 3p filtering is)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's specific to the perf category (and the rendering of the opportunities/diagnostics), so I think it's better kept local to those methods.

if (metric.acronym === 'All') {
radioEl.checked = true;
}
// Dynamically write some CSS, for the CSS-only filtering
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all this dynamic CSS seems much harder to follow than the equivalent JS would be. What reasons did you rule out JS?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO the CSS's declarative state communicates all the changes pretty clearly.
I'll give the JS equivalent a try in a second PR, for comparison.

.lh-filterbar__radio:checked:not(#metric-All) ~ .lh-audit-group .lh-audit,
.lh-filterbar__radio:checked:not(#metric-All) ~ .lh-audit-group .lh-audit-group__description,
.lh-filterbar__radio:checked:not(#metric-All) ~ .lh-audit-group .lh-audit-group__itemcount {
display: none;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there alternatives to hiding the filtered audits? I think keeping things in a constant place is beneficial. wdyt of reduce opacity?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we discussed this in the team meeting. there are arguments for both sides: hiding vs highlighting.

IMO highlighting is best if you're trying to do a diff. but I think the point of this control is to help focus action on the most relevant tasks. Given, that I think it's best to remove the irrelevant items from view completely.

lighthouse-core/report/html/report-styles.css Outdated Show resolved Hide resolved
types/lhr.d.ts Outdated Show resolved Hide resolved
lighthouse-core/config/default-config.js Outdated Show resolved Hide resolved
lighthouse-core/config/default-config.js Outdated Show resolved Hide resolved
@egsweeny
Copy link
Contributor
egsweeny commented Apr 6, 2021

Overall this is looking amazing. Just a quick fly-by suggestion re: verbiage for the copy 'Filter to relevant audits:'. It wasn't intuitive to me, but the current state might hold up if we don't like my alternatives (below).

Some alternatives:

  1. Filter audits by metric
  2. Filter audits by applicable metric
  3. Show audits relevant to: [alt: Filter audits relevant to:]
  4. Show audits relevant to a specific metric:
  5. Show audits to improve:

I'm currently leaning towards option 3, but am bike shedding and am flexible.

@connorjclark
Copy link
Collaborator

idea after talking to paul: would be nice to show metric adornments in the expanded audit view.

Copy link
Member Author
@paulirish paulirish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idea after talking to paul: would be nice to show metric adornments in the expanded audit view.

i like this. I'm gonna do in a second PR as it adds more line changes then you'd think.

* @param {LH.ReportResult.AuditRef[]} filterableMetrics
* @param {HTMLDivElement} element
*/
renderMetricAuditFilter(filterableMetrics, element) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's specific to the perf category (and the rendering of the opportunities/diagnostics), so I think it's better kept local to those methods.

if (metric.acronym === 'All') {
radioEl.checked = true;
}
// Dynamically write some CSS, for the CSS-only filtering
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO the CSS's declarative state communicates all the changes pretty clearly.
I'll give the JS equivalent a try in a second PR, for comparison.

.lh-filterbar__radio:checked:not(#metric-All) ~ .lh-audit-group .lh-audit,
.lh-filterbar__radio:checked:not(#metric-All) ~ .lh-audit-group .lh-audit-group__description,
.lh-filterbar__radio:checked:not(#metric-All) ~ .lh-audit-group .lh-audit-group__itemcount {
display: none;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we discussed this in the team meeting. there are arguments for both sides: hiding vs highlighting.

IMO highlighting is best if you're trying to do a diff. but I think the point of this control is to help focus action on the most relevant tasks. Given, that I think it's best to remove the irrelevant items from view completely.

types/lhr.d.ts Outdated Show resolved Hide resolved
@GoogleChrome GoogleChrome deleted a comment from google-cla bot May 13, 2021
@GoogleChrome GoogleChrome deleted a comment from google-cla bot May 13, 2021
@GoogleChrome GoogleChrome deleted a comment from google-cla bot May 13, 2021
@@ -146,6 +146,8 @@ declare global {
id: string;
weight: number;
group?: string;
relevantAudits?: string[];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nit: swap order of these two new fields to match prototype field ids (and in below file)

@@ -41,6 +41,10 @@ const MESSAGE_I18N_ID_REGEX = / | [^\s]+$/;
Intl.NumberFormat = IntlPolyfill.NumberFormat;
Intl.DateTimeFormat = IntlPolyfill.DateTimeFormat;
}
// Deal with buggy regex caching. https://github.com/andyearnshaw/Intl.js/issues/308
if (IntlPolyfill.__disableRegExpRestore) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

big LOL

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

admittedly i should have googled before i build node 12 with small-icu. but yes. annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants