Skip to content

Conversation

@mdperez86
Copy link
Contributor

@mdperez86 mdperez86 commented May 16, 2023

Submission Review Guidelines:

Changes proposed in this Pull Request:

Closes #38202

How to test the changes in this Pull Request:

Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:

  1. Got to /wp-admin/tools.php?page=woocommerce-admin-test-helper
  2. Under Features tab make sure to enable product-block-editor
  3. Then visit /wp-admin/admin.php?page=wc-admin&path=/add-product
  4. The product form should not have the problem described in [MVP QA #1] Visual: spacings #38202

@mdperez86 mdperez86 requested a review from a team May 16, 2023 20:23
@mdperez86 mdperez86 self-assigned this May 16, 2023
@github-actions github-actions bot added the package: @woocommerce/customer-effort-score issues related to @woocommerce/customer-effort-score label May 16, 2023
@github-actions
Copy link
Contributor

github-actions bot commented May 16, 2023

Hi @joshuatf,

Apart from reviewing the code changes, please make sure to review the testing instructions as well.

You can follow this guide to find out what good testing instructions should look like:
https://github.com/woocommerce/woocommerce/wiki/Writing-high-quality-testing-instructions

@github-actions
Copy link
Contributor

github-actions bot commented May 16, 2023

Test Results Summary

Commit SHA: ab0329f

Test 🧪Passed ✅Failed 🚨Broken 🚧Skipped ⏭️Unknown ❔Total 📊Duration ⏱️
API Tests25900202610m 50s
E2E Tests1940010020421m 43s

To view the full API test report, click here.
To view the full E2E test report, click here.
To view all test reports, visit the WooCommerce Test Reports Dashboard.

@mdperez86 mdperez86 force-pushed the add/38202 branch 3 times, most recently from fa4d6f0 to d65b303 Compare May 23, 2023 15:41
@github-actions github-actions bot added focus: react admin [team:Ghidorah] package: @woocommerce/components issues related to @woocommerce/components plugin: woocommerce Issues related to the WooCommerce Core plugin. labels May 23, 2023
@mdperez86 mdperez86 force-pushed the add/38202 branch 2 times, most recently from afa3a79 to 0bb738d Compare May 24, 2023 16:03
Copy link
Contributor

@joshuatf joshuatf left a comment

Choose a reason for hiding this comment

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

Looking great on my end! Thanks for the additional clean-up with notices in this PR.

Just left one question we discussed before. Let's see what @jarekmorawski says and we can update our naming accordingly.

}

&__content {
&--block-gap-lg > * + * {
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice! 🎉

},
"blockGap": {
"type": "string",
"enum": [ "lg", "2xlg" ],
Copy link
Contributor

Choose a reason for hiding this comment

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

We discussed this in our grooming call, but this is the only area the feels a little weird with the naming.

It would be great if we could match the gaps to our existing variable gap sizes (24px, 36px, 40px) and then match the naming there as well. @jarekmorawski is that feasible or do these gaps need to be different than our current gaps?

Choose a reason for hiding this comment

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

Meaning that we'd change all the gaps between fields and sections to those you listed? I'd prefer to avoid that. The ones in Figma are consistent with WordPress (more or less) and balance white space and density well. For example, increasing the gap between sections from 32 px to 36 px or 40 px will impact how much content is visible before scrolling.

By the way, where do our current gap sizes come from and can we adjust them to the new ones?

Copy link
Contributor

Choose a reason for hiding this comment

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

Those gaps came from the previous designers, but I'm unsure on the specifics of how they were chosen.

It would be really great to adjust them, though that would require changes in many places (a quick scan shows that we're using some form of the $gap variable in 762 files).

But if this is something we plan on doing one day, we could at least update the naming in this PR to match those. @jarekmorawski do you have ideal sizes for gaps/spacing for smallest, smaller, small, default, large, larger, and largest?

Choose a reason for hiding this comment

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

If we update the gaps, it'll affect all of wc-admin, correct? We'd have to do an audit to make sure we wouldn't break the visual rhythm outside the form, so I can't specify them yet. For the form, let's use the sizes below.

I'll leave it to your judgment and BEM best practices regarding naming.

  • XXS: 8px
  • XS: 16px
  • S: 24px
  • M: 32px
  • L: 40px
  • XL: 48px
  • XXL: 56px

We'll unlikely ever use gaps larger than 56 px for form elements or cards like in the Home screen. The only things I can think of are margins and paddings, but I'm not sure we should include them in the system.

Copy link
Contributor

@joshuatf joshuatf May 30, 2023

Choose a reason for hiding this comment

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

If we update the gaps, it'll affect all of wc-admin, correct?

Correct, but we're not looking at tackling that in this PR. Mostly just curious if it's something we'll eventually make sizes consistent between these and the existing gaps. If so, we can match the naming and eventually replace them.

On the other hand, providing new sizes (xxs, xs, s, etc) provides us an easier way to transition over. I'm indifferent between those sizes and using the previous semantics (smallest, smaller, small, etc). @mdperez86 do you have an opinion on this?

Copy link
Contributor Author

@mdperez86 mdperez86 May 31, 2023

Choose a reason for hiding this comment

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

@joshuatf in popular UI frameworks out there using (xs, sm, md, lg, xl) have become in a standard not only referring to a screen size but also to text-size and sometimes to spacing. But the problem this convention has is that the values are always fixed and we'll face the same problem in future if a new value appeared like now. Because of that some frameworks adopted a more scalable solution like using gap-1, gap-2, gap-3 -> 0.25rem /* 4px */, 0.5rem /* 8px */, 0.75rem /* 12px */ which give us infinite flexibility if a new value is required like 0.375rem /* 6px */ that can be represented as gap-1.5. Of course the downside of this approach is that is more difficult to recognize than a more descriptive names like xs or lg.
So I'm ok using the convention suggested by @jarekmorawski but just consider we could face the same problem we have now in the future.

Copy link
Contributor

Choose a reason for hiding this comment

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

@mdperez86 I like that style better as well and I think WooCommerce is the only one tied to a system using our current style of naming. I think that bodes well for us switching to a new relative gap system.

Looks like WordPress has adopted a similar approach.. And luckily we already have access to those variables here:

https://github.com/WordPress/gutenberg/blob/b2c16f3c684098a8dabff3911c610caa5c053701/packages/base-styles/_variables.scss#L31-L41

Let's follow that convention and we can slowly deprecate our previous gap system in time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done -> ab0329f

@mdperez86 mdperez86 requested a review from joshuatf May 31, 2023 21:16
Copy link
Contributor

@joshuatf joshuatf left a comment

Choose a reason for hiding this comment

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

Thanks for all the hard work on this, Maikel! This is a big improvement on our current spacing and how we organize things.

I noticed some oddities around spacing and background color in my environment, but I think this is unrelated to this PR and has to do with Gutenberg styles bleeding through since I have the latest GB enabled. We can address that in a follow-up so we don't block this issue further.
Screen Shot 2023-06-01 at 10 28 29 AM

{
className: classNames(
'wp-block-woocommerce-product-section__content',
`wp-block-woocommerce-product-section__content--block-gap-${ blockGap }`
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice 👍

const noticeContent = isCreating
? __( 'Product successfully created.', 'woocommerce' )
: __( 'Product published.', 'woocommerce' );
const noticeContent = isPublished
Copy link
Contributor

Choose a reason for hiding this comment

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

Noted this in the other PR, but won't let it block this PR since it's fixed there.

#38507 (comment)

@mdperez86 mdperez86 merged commit abcedbe into trunk Jun 1, 2023
@mdperez86 mdperez86 deleted the add/38202 branch June 1, 2023 17:56
@github-actions github-actions bot added this to the 7.9.0 milestone Jun 1, 2023
}
}

.components-modal__content {
Copy link
Contributor

Choose a reason for hiding this comment

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

Hi, @mdperez86! It looks like .components-modal__content is way too general, it's affecting all modals in admin.

image

Originally reported by Vlad Olaru in this slack p1686918124623299/1686328973.559239-slack-C01SFMVEYAK.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hi @ilyasfoo, thank you for reporting that.
I created this issue and I'm working on a fix now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

package: @woocommerce/components issues related to @woocommerce/components package: @woocommerce/customer-effort-score issues related to @woocommerce/customer-effort-score plugin: woocommerce Issues related to the WooCommerce Core plugin.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[MVP QA #1] Visual: spacings

6 participants