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

[#2098] Add show more button for error messages #2105

Merged
merged 13 commits into from
Mar 14, 2024

Conversation

jonasongg
Copy link
Contributor

@jonasongg jonasongg commented Jan 30, 2024

Fixes #2098

Proposed commit message

Add show more button for error messages

Currently, if there are a lot of error messages, it can block the rest
of the page to the point where users may thing the report failed to
generate at all.

Let's hide extra messages automatically add a show more button if there
are more to display the messages in full.

Other information

Currently, I opted for an easier JS implementation of the feature that displays the button if the number of error messages are above 4. About this, I wanted to ask what the best place would be to put a constant that defines this number (maximum number of error messages displayed without showing more).

Regarding the design of the show more button, I wanted to also get some thoughts on what would work best for RepoSense:
image

image
(default a tag, bad contrast)

image
(default MUI text button)

Lastly, with JS, the transition when clicking show more is visually a bit jarring as the new elements appear programmatically. If needed, I can investigate a way to better animate showing more through CSS, which would also eliminate the need to have a constant to define the number of error messages displayed by default (preliminarily, this would involve adding a transition to max-height).

@jonasongg jonasongg requested a review from a team January 30, 2024 06:44
Copy link
Contributor

@sopa301 sopa301 left a comment

Choose a reason for hiding this comment

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

LGTM! I think I like the blue option more because it's distinct from the surrounding colours. Also, the rest of RepoSense also uses blue for toggles.

Copy link
Contributor

@asdfghjkxd asdfghjkxd left a comment

Choose a reason for hiding this comment

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

Good work on the PR!

However, it seems like CI is failing due to some linting mistakes!

frontend/src/views/c-summary.vue Outdated Show resolved Hide resolved
@jonasongg
Copy link
Contributor Author

@sopa301 @asdfghjkxd Thanks for the insight! Fixed the linting issue also

@jonasongg jonasongg requested a review from a team February 2, 2024 09:56
frontend/src/views/c-summary.vue Outdated Show resolved Hide resolved
frontend/src/styles/style.scss Outdated Show resolved Hide resolved
@ckcherry23
Copy link
Member

@jonasongg Thanks for tacking this issue!

About this, I wanted to ask what the best place would be to put a constant that defines this number (maximum number of error messages displayed without showing more).

For now, I think we can define it in the view file and later move it to a dedicated Vue component.

Regarding the design of the show more button, I wanted to also get some thoughts on what would work best for RepoSense.

Currently, the 'Show More' button takes up a lot of vertical space at the bottom of the error box. Moreover, we do not expect most users to click on 'Show More' so it can be more subtle. I think what would work better to fit in with the compact style of RepoSense is using a right-aligned button styled like a red link.

image

Lastly, with JS, the transition when clicking show more is visually a bit jarring as the new elements appear programmatically. If needed, I can investigate a way to better animate showing more through CSS, which would also eliminate the need to have a constant to define the number of error messages displayed by default (preliminarily, this would involve adding a transition to max-height).

I think the transition isn't too bad but if you're interested in implementing smoother transitions, please go ahead!

@damithc
Copy link
Collaborator

damithc commented Feb 3, 2024

One other comment about the UI: I feel the fact that some errors have been omitted should be more apparent. The current Show more appears like a regular UI control that people will automatically ignore.

For example, the last line of error message could be

Remaining error messages omitted to save space. Show all ...

What do you all think? Other alternatives?

@ckcherry23
Copy link
Member

For example, the last line of error message could be

Remaining error messages omitted to save space. Show all ...

Just some mockups for discussion:

image
image

@damithc
Copy link
Collaborator

damithc commented Feb 3, 2024

Just some mockups for discussion:

image image

Thanks @ckcherry23 I'm OK with either. Will leave you all to decide.

@jonasongg
Copy link
Contributor Author

jonasongg commented Feb 5, 2024

@ckcherry23 @damithc Added the changes as specified!
image

@jonasongg
Copy link
Contributor Author

@ckcherry23 Wondering if I should add some tests in chartView_errorSummary_messageBox.cy.js to test this show more button; if I do, then I will need to add some repos to summary.json

@ckcherry23
Copy link
Member

Yes, it would be great if we added a test case to test this behaviour!

However, adding repos to summary.json may cause other test cases to break so we try to avoid making any changes to it (the RepoSense/cypress branch) unless absolutely necessary.

In your case, would it be okay to show only 3 errors by default?

@jonasongg
Copy link
Contributor Author

If I'm not wrong, the default cypress configuration will only result in one error message, so I'm not too sure on how best to test this!

@ckcherry23
Copy link
Member

If I'm not wrong, the default cypress configuration will only result in one error message, so I'm not too sure on how best to test this!

@jonasongg Okay, I thought the Cypress configuration had 4 errors, which is why I suggested the default of 3.

In that case, let's make changes to the cypress branch. You can go ahead and add more repos for analysis to the branch locally and see if all the Cypress tests pass, and fix any breaking tests.

@jonasongg
Copy link
Contributor Author

@ckcherry23 Sorry for the late update, just added the aforementioned tests!

Copy link
Member

@ckcherry23 ckcherry23 left a comment

Choose a reason for hiding this comment

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

LGTM! Pleasantly surprised other tests didn't break because of this change.

@ckcherry23 ckcherry23 requested a review from a team February 16, 2024 16:38
@ckcherry23
Copy link
Member

@jonasongg Please edit the title of the PR to include the issue number

@jonasongg jonasongg changed the title Add show more button for error messages [#2098] Add show more button for error messages Feb 17, 2024
@jonasongg
Copy link
Contributor Author

@ckcherry23 Made the changes! Thanks

frontend/src/views/c-summary.vue Outdated Show resolved Hide resolved
@jonasongg
Copy link
Contributor Author

@vvidday @ckcherry23 I added the variable in data() as I'm not too sure what the idiomatic way to define constants in our Vue files are, let me know if I should change it!

@vvidday
Copy link
Contributor

vvidday commented Feb 19, 2024

Tests seem to be failing due to the new title component + added error messages pushing the charts out of viewport - Might be worth looking into the visibility selectors in our tests.

chrome_AojBzTIZzQ.mp4

@jonasongg
Copy link
Contributor Author

jonasongg commented Mar 4, 2024

@vvidday thanks for pointing this out! a very simple fix for most of these tests would like you suggested to remove the .should('be.visible') assertion in the tests, but i'm not sure if this is the right way to fix them? the assertion doesn't seem to be doing much as the test would already fail if the element cannot be found. another way could be to scroll down so that the elements are visible

@sopa301
Copy link
Contributor

sopa301 commented Mar 9, 2024

We can either use the exist assertion or we can use scrollIntoView as you mentioned. I think it would be better to use scrollIntoView because it would more closely follow an actual user's interaction.

@jonasongg
Copy link
Contributor Author

@sopa301 Thanks for the suggestions! I decided to go with the exist assertion because it's an easier change (and also .click() will automatically scroll once the exist assertion passes). I also renamed zoomView_rampChart.js to zoomView_rampChart.cy.js so that the test actually appears

Copy link
Member

@ckcherry23 ckcherry23 left a comment

Choose a reason for hiding this comment

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

LGTM!

@ckcherry23 ckcherry23 requested a review from a team March 11, 2024 06:57
Copy link
Contributor

@vvidday vvidday left a comment

Choose a reason for hiding this comment

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

Thanks for the changes, LGTM!

Copy link
Contributor

@asdfghjkxd asdfghjkxd left a comment

Choose a reason for hiding this comment

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

LGTM!

@ckcherry23 ckcherry23 merged commit 0b09647 into reposense:master Mar 14, 2024
10 checks passed
Copy link
Contributor

The following links are for previewing this pull request:

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.

Improve UX of error message box when there are many error messages
6 participants