-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Update Usage page design #17807
Conversation
Looking at this now! 👀 |
There was a problem hiding this 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 |
---|---|
![]() |
![]() |
|
||
return ( | ||
<ContextMenu menuEntries={entries} customClasses="left-0"> | ||
<DateDisplay value="Date Range" onClick={noop} /> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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} /> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
return ( | ||
<ContextMenu menuEntries={entries} customClasses="left-0"> | ||
<DateDisplay value="Date Range" onClick={noop} /> |
There was a problem hiding this comment.
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:
- Default to the current period of the organization found in billing.
- Change the label to Custom when you manually select dates on the right.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 → |
There was a problem hiding this comment.
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 |
---|
![]() |
56a0a06
to
fbe9127
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/unhold |
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.
?start=2023-01-15&end=2023-01-31&page=2
Related Issue(s)
Fixes WEB-434
How to test
Documentation
Preview status
Gitpod was successfully deployed to your preview environment.
Build Options
Build
Run the build with werft instead of GHA
Run Leeway with
--dont-test
Publish
Installer
Add desired feature flags to the end of the line above, space separated
Preview Environment
If enabled this will build
install/preview
If enabled this will create the environment on GCE infra
Valid options are
all
,workspace
,webapp
,ide
,jetbrains
,vscode
,ssh
/hold