Skip to content

Update Usage page design #17807

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

Merged
merged 10 commits into from
Jun 6, 2023
Merged

Conversation

selfcontained
Copy link
Contributor

@selfcontained selfcontained commented Jun 1, 2023

Description

This makes some design updates to the org Usage page. I've split some of the pieces of the UI into their own components/files as well to make this easier to maintain in the future.

  • Removes sidebar & shifts filters into a row under heading
  • New Date Range selector instead of sidebar links for quickly selecting a month
  • Adjusted loading state to make UI a bit more stable
  • Filter options stored in url query string now vs. component state: ?start=2023-01-15&end=2023-01-31&page=2
  • Range > 300 days will be adjusted to be within max range when start/end dates changed manually
image

Related Issue(s)

Fixes WEB-434

How to test

  • Check out the Usage page for your org. Start a workspace to create an entry.

Documentation

Preview status

Gitpod was successfully deployed to your preview environment.

Build Options

Build
  • /werft with-werft
    Run the build with werft instead of GHA
  • leeway-no-cache
  • /werft no-test
    Run Leeway with --dont-test
Publish
  • /werft publish-to-npm
  • /werft publish-to-jb-marketplace
Installer
  • analytics=segment
  • with-dedicated-emulation
  • with-ws-manager-mk2
  • workspace-feature-flags
    Add desired feature flags to the end of the line above, space separated
Preview Environment
  • /werft with-local-preview
    If enabled this will build install/preview
  • /werft with-preview
  • /werft with-large-vm
  • /werft with-gce-vm
    If enabled this will create the environment on GCE infra
  • with-integration-tests=all
    Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh

/hold

@gtsiolis
Copy link
Contributor

gtsiolis commented Jun 2, 2023

Looking at this now! 👀

Copy link
Contributor

@gtsiolis gtsiolis left a comment

Choose a reason for hiding this comment

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

Woohoo! Thanks for making this change, @selfcontained. 🌮 🌮

Left some UX comments below but let me also visualize the suggested changes here.

BEFORE AFTER
Frame 1396 RangePicker


return (
<ContextMenu menuEntries={entries} customClasses="left-0">
<DateDisplay value="Date Range" onClick={noop} />
Copy link
Contributor

Choose a reason for hiding this comment

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

suggestion: It would be great if this could default to the current period of each organization. This works when users visit from the billing page but not when you directly visit the usage page, see #15544.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, instead of start/end of month, it would use their billing cycle start and end?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, this is what happens when you first go to billing and click view usage. The usage page renders using the current period dates. I believe this is what the usage page should show when you visit usage directly without going to billing first. For more context, see #15544. Let me know if you think it's not a good idea.


return (
<ContextMenu menuEntries={entries} customClasses="left-0">
<DateDisplay value="Date Range" onClick={noop} />
Copy link
Contributor

Choose a reason for hiding this comment

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

thought: Now that we moved these out of the header we could fall back to regular dropdown inputs for better accessibility, but maybe this is more effort than I can estimate since the range picker is a weird library we're using.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I’ll take a look.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Something like this maybe?

Light Dark
image image


return (
<ContextMenu menuEntries={entries} customClasses="left-0">
<DateDisplay value="Date Range" onClick={noop} />
Copy link
Contributor

Choose a reason for hiding this comment

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

issue: Having the value acting as the label here feels confusing. Is this element pre-selected? I'd expect this to:

  1. Default to the current period of the organization found in billing.
  2. Change the label to Custom when you manually select dates on the right.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yah this is a trade off I felt was worth it for now. Synchronizing the state of the drop-down and date pickers was a decent amount of effort I wanted to avoid initially. I agree though, it isn’t like a normal drop-down and behaves more like a menu, as there’s no active selection that is changing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had some time and ended up figuring out a solution here, so it reflects the current selected state now.

<div className="flex text-xs text-gray-600">
<span className="dark:text-gray-500 text-gray-400">
<Link to="/billing" className="gp-link">
View Billing →
Copy link
Contributor

@gtsiolis gtsiolis Jun 2, 2023

Choose a reason for hiding this comment

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

suggestion: We can keep this around until we figure out a better way to incorporate with new designs for this page. A boring (simple) solution to keep it with the layout suggestion made earlier could be to use a second secondary button on the top right, near the upcoming Export as CSV button. WDYT?

View Billing link in usage
view-link

@selfcontained selfcontained force-pushed the brad/web-434-update-design-of-usage-page branch from 56a0a06 to fbe9127 Compare June 5, 2023 16:22
@selfcontained selfcontained marked this pull request as ready for review June 5, 2023 22:00
@selfcontained selfcontained requested a review from a team June 5, 2023 22:00
@github-actions github-actions bot added the team: webapp Issue belongs to the WebApp team label Jun 5, 2023
Copy link
Member

@easyCZ easyCZ left a comment

Choose a reason for hiding this comment

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

@selfcontained
Copy link
Contributor Author

/unhold

@roboquat roboquat merged commit 2b4c216 into main Jun 6, 2023
@roboquat roboquat deleted the brad/web-434-update-design-of-usage-page branch June 6, 2023 12:46
@roboquat roboquat added deployed: webapp Meta team change is running in production deployed Change is completely running in production labels Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production deployed Change is completely running in production size/XXL team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants