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

Reader: Make user profile header responsive #98184

Merged
merged 11 commits into from
Jan 15, 2025
Merged

Conversation

DustyReagan
Copy link
Member

@DustyReagan DustyReagan commented Jan 9, 2025

Related to https://github.com/Automattic/loop/issues/296

Proposed Changes

  • The PR makes the user profile header responsive for mobile
  • It borrows styling from ReaderFeedHeader. However, it does not implement ReaderFeedHeader because ReaderFeedHeader takes a site and feed as props and contains site-centric functionality.
Before After
Screenshot 2025-01-09 at 4 39 44 PM Screenshot 2025-01-10 at 3 09 05 PM
Before After
Screenshot 2025-01-09 at 4 38 37 PM Screenshot 2025-01-10 at 3 10 30 PM

Why are these changes being made?

  • Improve experience on narrow-width screens.

Testing Instructions

  • Use Calypso Live
  • Go to /read/users/218803706 and view the page in various widths and on mobile, and make sure it looks like the screenshots above.
  • Try some other profile pages to make sure there are no regressions.

Pre-merge Checklist

  • Has the general commit checklist been followed? (PCYsg-hS-p2)
  • Have you written new tests for your changes?
  • Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
  • Have you checked for TypeScript, React or other console errors?
  • Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
  • Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
    • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
  • For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

@matticbot
Copy link
Contributor

matticbot commented Jan 9, 2025

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Async-loaded Components (~18 bytes added 📈 [gzipped])

name                                   parsed_size           gzip_size
async-load-calypso-reader-user-stream       +127 B  (+3.0%)      +18 B  (+1.1%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

@matticbot
Copy link
Contributor

matticbot commented Jan 9, 2025

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

  • blaze-dashboard
  • command-palette-wp-admin
  • help-center
  • notifications
  • odyssey-stats
  • whats-new

To test WordPress.com changes, run install-plugin.sh $pluginSlug fix/reader-user-header-img on your sandbox.

@DustyReagan DustyReagan self-assigned this Jan 9, 2025
@DustyReagan DustyReagan marked this pull request as ready for review January 9, 2025 23:36
@DustyReagan DustyReagan requested a review from a team as a code owner January 9, 2025 23:36
@matticbot matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Jan 9, 2025
@davemart-in
Copy link
Contributor

Can we just re-use the component we use for the feed details page header instead of having separate components that do pretty much the same thing? The feed header component already has good font-weights, spacing, proportions, and responsive styling:

Desktop

CleanShot 2025-01-09 at 19 10 25@2x

Mobile

CleanShot 2025-01-09 at 19 20 02

@DustyReagan DustyReagan changed the title Reader: Fix user profile avatar width Reader: Make user profile header responsive Jan 10, 2025
@DustyReagan
Copy link
Member Author

Thanks for the review, @davemart-in!

Can we just re-use the component we use for the feed details page header instead of having separate components that do pretty much the same thing? The feed header component already has good font-weights, spacing, proportions, and responsive styling:

It's tricky because the ReaderFeedHeader component expects a site and feed as props. We could make a faux site and map user data to it, or we could refactor ReaderFeedHeader to also take a user as a prop, but ReaderFeedHeader also has additional functionality we can't use like the follow button and subscriber count. So, my concern is extending it to work for the user will get complicated because we'll need to add more conditional logic to it.

However, I lifted the styling from ReaderFeedHeader and I think it looks pretty good now. What do you think?

Screen.Recording.2025-01-10.at.2.52.39.PM.mp4

Copy link
Member

@mehmoodak mehmoodak 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 making the header responsive.


.reader-avatar {
margin: 0 24px 0 0;
@include breakpoint-deprecated( '<660px' ) {
Copy link
Member

Choose a reason for hiding this comment

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

Should we use @include break-small or @include break-medium here instead of using the deprecated mixin?

Copy link
Member Author

@DustyReagan DustyReagan Jan 13, 2025

Choose a reason for hiding this comment

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

Ideally, yes. This breakpoint combats additional margin added here. There is no standard breakpoint for 660px, and rather than pull on the string to unravel the use of 660px here, I opted to use breakpoint-deprecated( '<660px' ).

Copy link
Member

Choose a reason for hiding this comment

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

If its possible to change both and not use deprecated one then maybe that's best. Otherwise this is fine too.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd like to land this PR using breakpoint-deprecated( '<660px' ). I'll timebox an investigation to see if we can refactor the deprecated breakpoint here, and open a separate PR to replace if it seems feasible.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm noting that this style would be better at max-width: 781px for the Lists component, as there's no breakpoint-deprecated( '<660px' ) on that page that's when the sidebar collapses.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm noting that this style would be better at max-width: 781px for the Lists component, as there's no breakpoint-deprecated( '<660px' ) on that page that's when the sidebar collapses.

*We can handle this as part of a separate PR cleaning up styles for the Lists component.

Copy link
Contributor

@artemiomorales artemiomorales left a comment

Choose a reason for hiding this comment

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

Testing in responsive Chrome on desktop, the styles look pretty good to me! It collapses nicely. A couple of comments below.


&__details {
flex: 1;
min-width: 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need the min-width value here? I've checked and it doesn't seem necessary.

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 helpful for really long text. For example, a long name will prevent the flexbox from shrinking past a certain width due to it sizing to the content, and then the bio will also run off the screen with the name. This prevents that.

Comment on lines 75 to 78
&::after {
@include long-content-fade( $size: 15% );
height: 16px * 1.7;
top: auto;
Copy link
Contributor

@artemiomorales artemiomorales Jan 14, 2025

Choose a reason for hiding this comment

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

I think the long-content-fade isn't being properly applied. It has position: absolute, so the __display-name needs position: relative so that the fade doesn't appear at the bottom of the page. Even after adding the relative positioning, I don't think it's quite working since the display name content wraps:

Screenshot 2025-01-13 at 19 27 46

I believe we're looking more for something along the following lines, right? To do that, we'd need to add text-wrap: nowrap to the __display-name, and probably fix the positioning of the pseudoelement, as it doesn't seem to be elegantly covering the overflowing letters:

Screenshot 2025-01-13 at 19 32 26

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh, good find! I updated it, so now it's fading whatever flows out into the 16px padding of the header, and added nowrap to the name.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok great! Looking much better at smaller resolutions.

What's the expected behavior when we have long names at higher resolutions? It still looks off in those cases. Should we put overflow: hidden to hide the name past the pseudoelement, or should we wrap the text?

Screenshot 2025-01-14 at 10 24 51

Copy link
Member Author

Choose a reason for hiding this comment

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

Whoops! I added overflow: hidden. Thanks!

or should we wrap the text?

I'm a bit torn on this. /read/feeds/{feedId} wraps the text, but I'm not sure I like the result. 😅 I'm leaning toward hiding the overflow because it keeps the layout behavior predictable, especially on small screens. We could try this on for size and follow up if it's not working for our users? I could also be convinced otherwise if you feel strongly about it. 😆

Copy link
Member Author

Choose a reason for hiding this comment

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

@artemiomorales, I'm going to go ahead and ship this PR since it's behind the flag. I'm happy to follow up on it in a new PR! ☺️

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm going to go ahead and ship this PR since it's behind the flag. I'm happy to follow up on it in a new PR! ☺️

Ok! The overflow sounds good to me. We can also iterate if need be :D

@DustyReagan DustyReagan merged commit 633528c into trunk Jan 15, 2025
11 checks passed
@DustyReagan DustyReagan deleted the fix/reader-user-header-img branch January 15, 2025 00:32
@github-actions github-actions bot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants