-
Notifications
You must be signed in to change notification settings - Fork 823
Forms: prepare Forms header for Next Admin visually #44242
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
base: trunk
Are you sure you want to change the base?
Conversation
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Code Coverage SummaryThis PR did not change code coverage! That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷 |
c86518e
to
d29273f
Compare
First off, apologies for the delay here. Looks good in my testing. Only have two minor comments about the resulting layout. Tabs not aligning with the title Could we use the version of the tabs where there's no horizontal spacing and see how it looks? Relevant Linear issue: https://linear.app/a8c/issue/DS-202/tabs-create-a-variant-where-tabs-do-not-have-horizontal-padding ![]() Overall layout not aligning with header Only the Responses tab content aligns with the new header. There's a bigger disparity of the layout in the Integrations page, but it's also applicable to the About page. The headers have been optimized for wider pages, so not sure if we need to solve this (or how we'd solve this), so just noting in case there's any ideas floating around. ![]() ![]() More importantly, how soon are we planning to land this? This is one of those changes that sounds great in theory but in practice it falls a bit short for now. If shipped right away, it creates inconsistency with other Jetpack analog pages that do have a branded header. Forms would be the only one that looks different, for no apparent reason. Especially since the Next Admin hasn't landed yet either. This is a change needed across the entire suite of products, so I wonder if we could apply this effort in a unified way. That would enable to update all of them at the same time, and be prepared for when Next Admin ships. |
Thanks for sharing!
I'd rather get it solid polish-wise before landing, but otherwise no blockers for getting this as soon in as we're ready. Next release in August? I'm not too concerned about inconsistencies across because managing those tends to hold us back more than I think it's worth in gains with consistency, but I do appreciate leaving things in half-state would not be great either. Would it help if we componentize this for Forms, and then it's ready to be picked for other headers? What if Zap updates a few products too?
Goal is to start preparing for Next Admin as we'll need to be ready for testing it early with CIAB where Jetpack Forms will be present. So now is the time, not later. :-) |
Note to self: explore if DataViews has (or will soon have) the header as ready-to-use component, or otherwise avoid needing to create a temporary component just within Jetpack. |
This would be fantastic, thank you.
This would obviously be the best! Perhaps creating the component and documenting its use would be a solid MVP? |
Since we've moved under "Jetpack", the Jetpack logo and "Jetpack" prefix in front of "Forms" becomes less critical for brand regognition.
To align more closely with design language of (still evolving) upcoming we can also adjust things like spacing. Here's Gutenberg's experimental "posts" page using DataViews:
The styles and component structure are taken from the above page (as of July 9, 2025), and adopted for our use:
Result is slightly more compact than what we had before.
Later we can componentise this within Jetpack in short term, and eventually hopefully use components from Gutenberg directly as componentry evolves.
Proposed changes:
Before
After
Other information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions: