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

Fix remaining issues for simplified team plans #10182

Merged
merged 5 commits into from
May 30, 2022
Merged

Conversation

jankeromnes
Copy link
Contributor

@jankeromnes jankeromnes commented May 23, 2022

Description

Improve and ship the simplified Team Billing. ✨

TODO:

  • Un-hide the new Team Billing menu entry
  • Polish the UI
  • Fix race condition on multiple team joins 🐞

Related Issue(s)

Fixes #10057

How to test

  1. Create a Team
  2. Navigate to Team Settings > Team Billing -- it should look nice ✨
  3. Upgrade your Team to either Professional or Unleashed
    • (provide bogus billing details, for example type "a" into every required field, and use the proposed fake credit card)
  4. Invite two more members, who should join at almost exactly the same time (within ~30s)
  5. Check Chargebee-test for new charges. There should be:
    • one "Pro-rated upgrade from 1 to 2"
    • one "Pro-rated upgrade from 2 to 3"

(If the bug isn't fixed, you'd see one "from 1 to 2" invoice, and another "from 1 to 3" invoice(!) that's double the amount)

Screenshot of a successful test:

Screenshot 2022-05-27 at 10 21 45

Release Notes

Fix, polish, and release new simplified Team Billing

Documentation

  • /werft with-payment=true

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 23, 2022

The UI currently looks like this:

No Billing Active Billing
Screenshot 2022-05-23 at 10 03 46 Screenshot 2022-05-23 at 11 00 21
Screenshot 2022-05-23 at 10 04 06 Screenshot 2022-05-23 at 10 50 47

A few issues when comparing with the Figma spec:

  • The currency switcher should be blue
  • Dark theme font color should be fixed
  • Reword price label?

@gtsiolis do your keen eyes spot anything else? 🐞 πŸ” πŸ‘€

@gtsiolis gtsiolis self-requested a review May 23, 2022 09:34
@gtsiolis
Copy link
Contributor

gtsiolis commented May 23, 2022

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.

Thanks, @jankeromnes! Overall looks great. ✨

I couldn't find any code changes in this PR related to the UX comments left below, which made it harder to gather all these comments and find a place to add them. I assume these visual changes were part of another pull request, right?

Left some first round review comments. Let me know what you think.

components/dashboard/src/teams/TeamBilling.tsx Outdated Show resolved Hide resolved
components/dashboard/src/teams/TeamBilling.tsx Outdated Show resolved Hide resolved
components/dashboard/src/teams/TeamBilling.tsx Outdated Show resolved Hide resolved
components/dashboard/src/teams/TeamBilling.tsx Outdated Show resolved Hide resolved
components/dashboard/src/teams/TeamBilling.tsx Outdated Show resolved Hide resolved
@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 24, 2022

Wow, many thanks @gtsiolis for the in-depth UX review and spot-on suggestions! πŸͺ„

I couldn't find any code changes in this PR related to the UX comments left below, which made it harder to gather all these comments and find a place to add them. I assume these visual changes were part of another pull request, right?

Ah, whoops, indeed. Most of these rough visual changes were actually implemented in #8041, but were left hidden from users by removing the new menu entry. πŸ•ΆοΈ

Thank you for still managing to do the in-depth review! πŸ™

@roboquat roboquat added size/L and removed size/M labels May 27, 2022
@jankeromnes jankeromnes force-pushed the jx/fix-better-team-plans branch 3 times, most recently from b12a4ea to ef668ad Compare May 30, 2022 09:37
@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

Another UI pass done ✨ Current state of the UI:

No billing Team Unleashed
Screenshot 2022-05-30 at 14 44 47 Screenshot 2022-05-30 at 14 46 01
Screenshot 2022-05-30 at 14 44 22 Screenshot 2022-05-30 at 14 45 45

Remaining open questions:

  • Hide the word "Team" in plan names?
  • Replace card hover/click by a big primary button?

@jankeromnes jankeromnes marked this pull request as ready for review May 30, 2022 12:09
@jankeromnes jankeromnes requested a review from a team May 30, 2022 12:09
@github-actions github-actions bot added the team: webapp Issue belongs to the WebApp team label May 30, 2022
@jankeromnes

This comment was marked as resolved.

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.

UX LGTM, @jankeromnes! Left one last round of non-blocking comments.

components/dashboard/src/teams/TeamBilling.tsx Outdated Show resolved Hide resolved
return (
<ContextMenu menuEntries={enhancedEntries} classes={`${props.contextMenuWidth} right-0`}>
<span className={`py-2 cursor-pointer ${font}`}>
<ContextMenu menuEntries={enhancedEntries} customClasses={`${props.customClasses} right-0`}>
Copy link
Contributor

Choose a reason for hiding this comment

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

thought: Wondering if we need the custom classes altogether here. πŸ’­

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 believe we do, because the context-menu sometimes need to be left-aligned or right-aligned, among other things.

Copy link
Contributor

@gtsiolis gtsiolis May 30, 2022

Choose a reason for hiding this comment

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

It's better to only use left-aligned items inside the dropdown menus. πŸ’‘

Do you have a handy instance of a right-alignment you're referring to?

I've only seen the dropdown in the workspace start page when using a desktop editor that's using center alignment and this should also change, see #6910.

If this is about the alignment of the component itself with the rest of the elements around it, we could probably move the alignment control outside this component, 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.

It's better to only use left-aligned items inside the dropdown menus. πŸ’‘

Ah, sorry, I meant how the collapsible elements horizontally align with respect to the control, e.g.:

Screenshot 2022-05-30 at 16 01 13 Left Screenshot 2022-05-30 at 16 01 18 Right Screenshot 2022-05-30 at 16 01 31 Left
Screenshot 2022-05-30 at 16 01 56
Right
Screenshot 2022-05-30 at 16 02 41 Right Screenshot 2022-05-30 at 16 40 43 Center

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, thanks for clarifying, @jankeromnes!

<div className="w-full h-full flex flex-col items-center justify-center">
<Spinner className="h-5 w-5 animate-spin" />
</div>
</SolidCard>
) : (
<SolidCard>
<SolidCard className="w-72 h-64">
Copy link
Contributor

Choose a reason for hiding this comment

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

thought: Hoping in the future we can drop these by introducing component variants that include card size, etc. instead of hard-coding sizes like this. We'll get there!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are ways to achieve this with a single component, e.g. by using:

  • min-height on the card (to allow it to grow arbitrary tall depending on its content, but not below some minimum height)

  • items-stretch on the card container (to make all the cards the same height, even if one card has a lot of content but the others don't)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, but let's keep this as is for now until the card component matures enough from design perspective to set a foundation of card sizes, size steps, etc.

Long-term, to keep the component flexible I'd love to introduce a stepper property to increase the width or height without using Tailwind's classes. 🧑

But no need to do this in the scope of this PR. πŸ›Ή

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, it's good to keep in mind that Tailwind is so nice because it allows directly "hard-coding" style in a nice way (as opposed to hiding style under multiple levels of abstractions, making them really hard to adjust afterwards). πŸ’­

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Long-term, to keep the component flexible I'd love to introduce a stepper property to increase the width or height without using Tailwind's classes. 🧑

But, even better would be if the Cards always look perfectly-sized, depending on their contents, without needing a stepper or Tailwind classes, right? πŸ˜‡ ("Default correct" is better than "lots of knobs and switches")

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, it's good to keep in mind that Tailwind is so nice because it allows directly "hard-coding" style in a nice way

I'm also in favor of duplication over abstraction as it comes with multiple benefits, but in the long run it makes sense to abstract some component aspects to help a) avoid running into code reviews nitpicking dimensions or other attributes, b) avoid requesting UX reviews when possible to avoid, c) feeling more confident about the product UX, and more.

However, this issue will become more relevant as these components mature and are widely used. For now, as long as we have two component instances of the solid card component, any approach would suffice and does not worth keeping this PR from being merged. 🀝

But, even better would be if the Cards always look perfectly-sized, depending on their contents, without needing a stepper or Tailwind classes, right?

Debatable! πŸ™‚

In most cases, the card component would need to use a specified width or height, which could be challenging to maintain when having multiple cards side-by-side that from a design perspective have to use fixed and specific dimensions regardless if some contents are missing. For example, see editor preferences, etc.

However, there's still need for having flexible card layouts without fixed width that fill the parent container on smaller viewports, etc.

@jankeromnes
Copy link
Contributor Author

/hold

@gtsiolis
Copy link
Contributor

/hold

@jankeromnes Also, regarding the hold comment in #10182 (comment), in case it helps, this still needs a review from @gitpod-io/engineering-webapp to be merged.

At least 1 approving review is required to merge this pull request.

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

At least 1 approving review is required to merge this pull request.

Oh. Sounds like a bug if it's true -- you should absolutely be able to approve at least dashboard fixes & improvements. 🚒

Co-authored-by: George Tsiolis <tsiolis.g@gmail.com>
@jankeromnes
Copy link
Contributor Author

/unhold

@geropl geropl self-assigned this May 30, 2022
@geropl
Copy link
Member

geropl commented May 30, 2022

Starting review now...

Copy link
Member

@geropl geropl left a comment

Choose a reason for hiding this comment

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

@jankeromnes Tested and fixed: Thx for that, and approve! βœ”οΈ

I think I still managed to break it:
image

I think the reasons is the "Quantity" dropdown:

  • during initial upgrade I choose 10 (or sth)
  • I got billed 175 € - without gaining anything 😬
  • the subsequent 1st quantity upgrade (10 -> 2) did not trigger an addition charge being created (:+1: )
  • the 2nd quantity upgrade (2 -> 3) incurred the charge (+35€) for the current month (:+1: )

IMO we should remove the quantity dropdown if possible.

/hold feel free to address this in this PR or let's discuss/fix in a follow up! πŸ‘

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

@jankeromnes Tested and fixed: Thx for that, and approve! βœ”οΈ

Woohoo πŸ™Œ many thanks!

  • during initial upgrade I choose 10 (or sth)
  • I got billed 175 € - without gaining anything 😬

"User buys too many seats on purpose, is then surprised to pay for too many seats" πŸ˜…

Joking aside, I agree that it would be best to hide this quantity selector that isn't needed. It's confusing at best, if not actively harmful.

Will see if there is an easy fix, but if there isn't, I'll just merge this as is and open a follow-up issue.

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

I think the quantity selector can only be disabled in Chargebee's settings:

Chargebee plan settings Disallow editing quantity
Screenshot 2022-05-30 at 18 10 56 Screenshot 2022-05-30 at 18 10 20

Happy to do this, but since it's a follow-up issue, let's unblock this PR first.

/unhold

EDIT: Filed this follow-up issue: https://github.com/gitpod-io/ops/issues/2543

@roboquat roboquat merged commit 39d66bc into main May 30, 2022
@roboquat roboquat deleted the jx/fix-better-team-plans branch May 30, 2022 16:15
@roboquat roboquat added deployed: webapp Meta team change is running in production deployed Change is completely running in production labels May 31, 2022
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 release-note size/L team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remaining issues for simplified team plans
4 participants