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

Update UserGridPanel layout #22184

Draft
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

stanriders
Copy link
Member

@stanriders stanriders commented Jan 13, 2023

@stanriders stanriders mentioned this pull request Jan 13, 2023
8 tasks
@bdach
Copy link
Collaborator

bdach commented Jan 13, 2023

Test failures appear to be relevant.

@bdach bdach self-requested a review January 14, 2023 13:22
@stanriders
Copy link
Member Author

From going through card usages I've found that some API calls that populate user data seem to not have information required for the cards:

  • GetUsersRequest (used in currently playing dashboard and solo spectator screens) doesn't have PlayMode and Statistics/Level set
  • GetFriendsRequest (used in dashboard) doesn't have PlayMode

Should I create an issue on osu-web or just hide the parts that are not being populated (as I already do with the playmode)?

@@ -61,27 +61,31 @@ protected UserPanel(APIUser user)
[Resolved]
protected OsuColour Colours { get; private set; } = null!;

protected virtual bool ShouldCreateUserCoverBackground { get; set; } = true;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I have a real strained relationship with these sorts of properties. Half the time these work ok, half the time they turn out to be a horrible mistake N months later down the lane when another design comes that doesn't fit the overfitted abstraction that these provide.

It's probably fine to have it for now, but it's written weird/wrong right now. It should be either a get-only virtual property, or a get; init non-virtual one - having it settable at any point is kind of a lie since it only has an effect when read once in BDL.

If I were to change this any further, I'd probably go for something like a IEnumerable<Drawable> CreateBackground() method, that in this implementation creates the box and the cover, and only the box in the one that doesn't want the cover. That's slightly less specific than this current setup.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, I'll go with the CreateBackground()

@@ -28,7 +28,7 @@ public UserListPanel(APIUser user)
[BackgroundDependencyLoader]
private void load()
{
Background.Width = 0.5f;
Background!.Width = 0.5f;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah no please don't do this. Debug.Assert() is much preferred.

That said if you go with my other CreateBackground() suggestion then this all can be refactored out to not require any of these gymnastics. It will result in some code duplication but I think it's fine.


protected override bool OnHover(HoverEvent e)
{
hoverDim?.FadeTo(0.2f, 200);
Copy link
Collaborator

Choose a reason for hiding this comment

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

You might wanna put an easing on these, it looks pretty bad right now. OutQuint is what most of everything uses.

@bdach
Copy link
Collaborator

bdach commented Jan 14, 2023

  • GetUsersRequest (used in currently playing dashboard and solo spectator screens) doesn't have PlayMode and Statistics/Level set
  • GetFriendsRequest (used in dashboard) doesn't have PlayMode

I think web is well within its right to not return these. They are both ruleset-sensitive pieces of data and it is unclear for which ruleset data should be returned in both cases.

@stanriders
Copy link
Member Author

I think web is well within its right to not return these. They are both ruleset-sensitive pieces of data and it is unclear for which ruleset data should be returned in both cases.

PlayMode is supposed to return ruleset which is set as default for the user, I believe its set for everyone.
Statistics is a more weird one as the level badge is a big piece of the design, but I agree - it's not clear what is even supposed to be returned

@bdach
Copy link
Collaborator

bdach commented Jan 14, 2023

PlayMode is supposed to return ruleset which is set as default for the user, I believe its set for everyone.

I suppose it is, although I don't know if that makes sense either. Like even bots seem to have ruleset set, while I'd probably accept null as the most viable alternative there.

Dunno. Maybe worth asking the web team, but I feel like the endpoints in question are likely to be returning UserCompact rather than User to manage load.

@peppy peppy self-requested a review January 14, 2023 17:38
@peppy
Copy link
Member

peppy commented Jan 14, 2023

I don't quite get this design. Feels like a regression from what we currently have.

Here's some initial feedback:

The level badge looks wrong proportionally. There's too much empty space or the font weight is too low or something

2023-01-15 02 45 54@2x

@arflyte

Dimming on hover feels back-to-front. No border makes it feels like the cards are hardly even responding to the mouse.

2023-01-15.02.46.27.mp4

Also the bottom status part of the card not changing on hover feels bad.

Corner radius mismatches feel bad

2023-01-15 02 43 06@2x

Colour lines feel unbalanced and hard to read

2023-01-15 02 44 34@2x

Overlap galore

2023-01-15 02 45 01@2x

I dunno. The balance is just off

2023-01-15 02 47 42@2x

Copy link
Member

@peppy peppy left a comment

Choose a reason for hiding this comment

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

Not looking at code, but design-wise this needs some further thought.

@bdach
Copy link
Collaborator

bdach commented Jan 14, 2023

Dimming on hover feels back-to-front

For whatever that's worth I suggested that (out of thin air) because as usual there are no hover states on design. The thought process was that the beatmap listing is also doing a similar thing by dropping colours a shade darker on hover.

@peppy
Copy link
Member

peppy commented Jan 14, 2023

I have a feeling I made the same comment for the beatmap cards too. I guess as long as they match let's go with it, but it definitely doesn't feel good here. Maybe the dim needs to be increased. The transition time definitely needs to be faster (match beatmap card?), and it should affect the status area too.

@stanriders
Copy link
Member Author

A lot of overlap/balance issues might be coming from the card width - designs keep them at 375, which most of the card usages in game have them way smaller (as well as incosistent). I can try updating widths to the design, at least to see if that helps.

I will update the hover state to be the same as beatmap cards

@peppy peppy self-requested a review January 17, 2023 04:55
@arflyte
Copy link

arflyte commented Jan 17, 2023

Hmm, probably this needs to go back to the drawing board (without changing too much).

@peppy
Copy link
Member

peppy commented Jan 17, 2023

@arflyte for the corner radius issue, adding a small amount of padding around the avatar will likely fix it. for the level badge, making the edge (shape) border thicker and changing the text size based on how many digits to better fit will likely work well.

not sure about the colour lines. the height definitely feels weird no matter how long i look at it.

@stanriders stanriders marked this pull request as draft December 21, 2024 10:25
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.

4 participants