8000 Update beatmap overlay to latest design logic · Issue #13712 · ppy/osu · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Update beatmap overlay to latest design logic #13712

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.

Sign up for GitHub

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

Jump to bottom
Open
frenzibyte opened this issue Jun 30, 2021 · 18 comments
Open

Update beatmap overlay to latest design logic #13712

frenzibyte opened this issue Jun 30, 2021 · 18 comments
Labels
area:overlay-beatmap type:cosmetic

Comments

@frenzibyte
Copy link
Member
frenzibyte commented Jun 30, 2021 •
edited by Joehuu
Loading

Given that it's deemed a cool thing to have for osu!lazer (upon discussing it), I'll begin working on this.

### Tasks
- [ ] https://github.com/ppy/osu/issues/24765
@frenzibyte frenzibyte self-assigned this Jun 30, 2021
@peppy
Copy link
Member
peppy commented Jul 1, 2021 •
edited
Loading
8000

By "port" do you mean implement or update instead? If not, intentions are unclear. Maybe link to the design you are aiming to implement.

@frenzibyte
Copy link
Member Author

I mean fully implementing it, this portion in particular:
image

@peppy peppy changed the title Port new beatmap info overlay design Update beatmap overlay to latest design logic Jul 1, 2021
@smoogipoo
Copy link
Contributor

Probably a given, but make sure that the components are reusable from the start. Because these same designs are to be used in song select (https://www.figma.com/file/DXKwqZhD5yyb1igc3mKo1P/Song-Select-Draft-2?node-id=0%3A1)

@frenzibyte
Copy link
Member Author

Yeah I'm separating each section and its details to their own set of components, so they should be fully reusable for that case.

@frenzibyte
Copy link
Member Author

I've got the initial structure ready and experimented with all the components in the overlay, and currently have a few questions:

  1. Does the proposed difficulty colour spectrum look good/ready for using it on the redesign?:
    CleanShot 2021-07-05 at 15 45 29

    Its implementation osu!lazer-side was pretty simple and "PR'able", relying solely on Interpolation.ValueAt. Would like to hear if it's good to go and I'll open a PR for that.

  2. Also from the difficulty colour spectrum design, are these proposed ways for how to display the star rating display on certain colours, with each being alternative to the other?
    CleanShot 2021-07-05 at 15 57 04

    And if so, has it been decided yet which way to follow? I think going white on 7.50* sounds the best of all (i.e. the middle one).

  3. Has it been defined what the exact levels of failures for the new fail bar should be?:
    image

    Currently went with the following:

    • 200,000 fails -> darker red
    • 50,000 fails -> red
    • 20,000 fails -> dark orange
    • 10,000 fails -> orange
    • 5,000 fails -> light orange

    But that's quite arbitrary and only based on certain maps I've seen, may need better investigation on what the values should be, maybe?

  4. Does a design exist for the circle display that's described on the preview button explainer:
    image

    I'm currently unsure of what should appear and how it should appear.

  5. Are the strips at the bottom of the difficulties representing the solid difficulty rating (easy, hard, insane, etc.) of the surrounded difficulties?
    image

    If so, did the colours get updated for them? they don't seem to match with what is present in osu! and osu!web. Would it be best to update the current method providing the old ones with the new colours? doesn't seem like it would cause any problems to the current existing lazer designs.

cc @peppy @arflyte

Also, as an aside, does this look to be the optimal way for asking certain things on the designs part? or would using Figma's comments system be a better choice for such? @arflyte what do you think?

@peppy
Copy link
Member
peppy commented Jul 5, 2021
  1. Does the proposed difficulty colour spectrum look good/ready for using it on the redesign?:

Should be its own PR / issue / whatever. You're overloading this.

  1. Also from the difficulty colour spectrum design, are these proposed ways for how to display the star rating display on certain colours, with each being alternative to the other?

no idea. make a new issue or discussion thread, this is not related to this thread.

  1. Has it been defined what the exact levels of failures for the new fail bar should be?:

Should be relative. Also no guarantee raw numbers are even going to be returned (they shouldn't).

  1. Does a design exist for the circle display that's described on the preview button explainer:

Who knows. @arflyte should provide this as part of the figma document. Along with hover states for everything (nothing has hover states??? how are you even implementing?)

  1. Are the strips at the bottom of the difficulties representing the solid difficulty rating (easy, hard, insane, etc.) of the surrounded difficulties?

Should be based off the ranges.

@frenzibyte
Copy link
Member Author
  1. Does the proposed difficulty colour spectrum look good/ready for using it on the redesign?:

Should be its own PR / issue / whatever. You're overloading this.

It is gonna be its own PR. And I'm planning to separate the sections all into reviewable chunks which are pieced out by one final PR at the end anyways, not overloading one PR with multiple things at once.

Asked about this since it's used in the overlay design and I've been wondering if it's good to add, I'll open a PR and things can be decided there.

  1. Also from the difficulty colour spectrum design, are these proposed ways for how to display the star rating display on certain colours, with each being alternative to the other?

no idea. make a new issue or discussion thread, this is not related to this thread.

I thought it is related since the component is used in this new overlay design, and this problem will have to be sorted out for the component to be usable in the overlay? either way I'll follow the middle way (black on <7.50, white on >=7.50) and it can be decided how it should go in the PR that's adding it.

  1. Has it been defined what the exact levels of failures for the new fail bar should be?:

Should be relative. Also no guarantee raw numbers are even going to be returned (they shouldn't).

Alright, will see what I can do and it can be further discussed in the PR adding it.

  1. Does a design exist for the circle display that's described on the preview button explainer:

Who knows. @arflyte should provide this as part of the figma document. Along with hover states for everything (nothing has hover states??? how are you even implementing?)

Well, I don't see it, and that's why I've mentioned him since I'm confused as well. As for the hover state, also not sure, don't see anything about it.

@frenzibyte
Copy link
Member Author
frenzibyte commented Jul 6, 2021 •
edited
Loading
  1. Has it been defined what the exact levels of failures for the new fail bar should be?:

Should be relative. Also no guarantee raw numbers are even going to be returned (they shouldn't).

Just to clarify on this part actually, do you mean that the numbers returned from the web API should be in the [0-1] range instead? (i.e. relative)?

@bdach
Copy link
Collaborator
bdach commented Jul 6, 2021

How else could that be interpreted? That is what relative means. Whether it's [0,1] or [0,100] is mostly an implementation detail. Using raw absolute numbers is all kinds of wrong anyway because if you used absolute numbers you would have a reduced colour palette on less-played maps.

@frenzibyte
Copy link
Member Author
frenzibyte commented Jul 6, 2021 •
edited
Loading

Because on the original question, I wasn't specifically talking about what the API will return, I was talking about how the fails should be displayed given that the API returns raw numbers. Therefore I got slightly confused and wanted clarification for the given answer, which I presume now to have actually meant that the numbers returned by the API should have been relative and not raw.

@peppy
Copy link
Member
peppy commented Jul 7, 2021

It's as @bdach said: treat them as relative.

@frenzibyte
Copy link
Member Author

@arflyte here is the list of things currently missing from the beatmap info design file:

  • Hover states for all buttons/clickable components, as mentioned previously.
  • Design for the "circle display" which appears when playing the preview.
  • Ranking section.
  • Comments section.

Also small details I need clarification on:

  • Is there meant to be a limited bar for both the "circle count" and "slider count" in the metadata/statistics section? if so, what are the maximum values?

  • There seem to be different designs for the metadata/statistics section, the one in "Beatmap Info" being:

    CleanShot 2021-07-15 at 08 06 27

    And the one in "Song Select" being:

    CleanShot 2021-07-15 at 08 06 41

    Which one is up to date and should be used for both places? and if they're intentionally different, what part of it is intended to be different?

@arflyte
Copy link
arflyte commented Jul 15, 2021
  • No changes to hover states for all buttons for now; it just lights up like current buttons
  • It's just a small circle progress icon. It's implemented somewhere, I'll look for it.
  • Ranking and comment uses the current design.
  • Use the design in here, not any other files https://www.figma.com/file/HDSXf4LPPV7hnD5wrWYG4jix/Web-Beatmap-Info?node-id=0%3A1
  • Circle count and slider count bar's min is the easiest diff and the max from hardest diff

@bdach bdach mentioned this issue Jul 21, 2021
Closed
@Joehuu Joehuu mentioned this issue Sep 6, 2023
Closed
8000 17 tasks
@Joehuu
Copy link
Member
Joehuu commented Sep 6, 2023

@frenzibyte have you started on any parts that can be used in song select (e.g. the metadata/statistics) or do I start from scratch?

@frenzibyte
Copy link
Member Author

Not at all, feel free to begin.

@frenzibyte frenzibyte assigned Joehuu and unassigned frenzibyte Sep 6, 2023
@frenzibyte
Copy link
Member Author

Oh, I thought this is the song select redesign thread, my bad...

@Joehuu I have some branches that you may find useful, as they contain components like the beatmap details breakdown, ready to be used outside of the beatmap info overlay.

I'll bring the branch up later today or tomorrow.

@frenzibyte frenzibyte assigned frenzibyte and unassigned Joehuu Sep 19, 2023
@frenzibyte frenzibyte removed their assignment May 9, 2025
@frenzibyte
Copy link
Member Author

As an update, I do not intend on working on this at all anymore. This branch contains all of my work from the times I've been working on this: master...frenzibyte:osu:beatmap-info-redesign/epic

@peppy
Copy link
Member
peppy commented May 12, 2025

Not sure how useful that branch is based on how long it's been since any work has been done.

Given that the osu-web version is also dead in movement, we should probably just throw this whole thing away unless there's community push for it, I dunno.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area:overlay-beatmap type:cosmetic
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@peppy @smoogipoo @arflyte @bdach @frenzibyte @Joehuu
0