Open simison opened 6 months ago
Related conversations:
Related PR for another approach to promoting the blocks together:
Allow inserting sharing block with block hook (after posts, in archives, in blog post lists)
Noting #35542 as the first step for this, currently gated behind an option, pending UI for it.
Add great defaults to the sharing block instead of leaving it empty in insertion, allowing editing in the block editor.
I have mixed feelings about this. I think it makes a lot of sense to have a better onboarding experience for the block. At the same time, I think it would make more sense for us to follow Core's lead on this. We developed the sharing buttons block to offer an experience that was very close to Core's Social Icons block. Given that Core is currently working on improvements to the UX for that block (see https://github.com/WordPress/gutenberg/issues/56259 ), I think we should follow the same path with our own block, to offer a consistent experience in the block editor.
I have mixed feelings about this. I think it makes a lot of sense to have a better onboarding experience for the block. At the same time, I think it would make more sense for us to follow Core's lead on this. We developed the sharing buttons block to offer an experience that was very close to Core's Social Icons block.
It might make sense to have the defaults only in block hooks situations and patterns, and when they are adding just the block manually, leave it as it is today. Needs a bit thinking/exploring for sure.
@jeherve, can your team check what's up with the margins and button sizes with the sharing/likes block? I was using Lettre theme but I've seen it few times in other themes as well.
can your team check what's up with the margins and button sizes with the sharing/likes block? I was using Lettre theme but I've seen it few times in other themes as well.
Done in #36386.
cc @keoshi since I'm not sure Oracle monitors the Jetpack Design board anymore.
Thanks for the ping @jeherve. How can we help here?
This looks great and I love the thinking here. The block editor is still daunting for many so whatever we can do to ramp people up to that world is excellent.
Two immediate thoughts:
It might make sense to have the defaults only in block hooks situations and patterns, and when they are adding just the block manually, leave it as it is today. Needs a bit thinking/exploring for sure.
Agreed that we should try to auto-populate our blocks in situations where they are being added as part of a product flow or introduction to a feature; i.e.: not being added by the user in the block editor.
One of the things we discussed while working on the Sharing block was also being able to transition people from traditional themes and Sharing options in Jetpack to a block theme. One key thing to do there would be read all the current Jetpack sharing options and auto-populate a Sharing block with the same networks and settings.
Turn key toggles in Jetpack settings to add sharing and likes blocks to the site
One thing to note is that while the blocks being discussed currently are system-wide (or "things that apply to a site universally"), but in the future we should also think about:
@keoshi I was thinking it would be great if you could help us figure out flows and interfaces for the different use-cases I mentioned here: https://github.com/Automattic/dotcom-forge/issues/5915#issuecomment-1983640984
That would include a lot of the scenarios you mentioned above.
@jeherve Thanks for speedy fix! The buttons should also be more defensive about theme CSS leaking in (or allow some CSS in, but in the same way for both buttons, whichever works better). I think the like is an iframe so being more defensive might be better. Now they end up looking different size, and different hover effects depending on theme:
Shadow dom might also be helpful here.
I'm not sure what's the best way to go about this. On one hand, the design should be consistent between the 2 buttons. On the other, wouldn't we want the fonts and styles to match the rest of the site?
@jeherve happy to help think it through, maybe in a separate GH issue?
Sure thing. I created #36410 so we can keep track of that.
CC'ing @eeeeeevon2023 for awareness. I'll be at a meetup next week and won't be able to look at this until the 27th.
Now that likes & sharing functionalities are blocks, the next step would be figuring out how to make the experience "turn-key" and magical.
We've also introduced the first steps to "turn-key" the site into a subscription site and inject subscription blocks to templates automatically (See p1HpG7-rwo-p2):
We shouldn't require customers to add blocks manually to templates in the site editor. Instead, there should be a single switch that does everything for you, with excellent presets, just like with classic themes. Customers' WP and theme should also not affect the turn-key experience; the main toggle needs to be available consistently regardless of their theme (classic or block) or version of WP (with the latest block hook APIs or not).
We need to ensure these features are easily discovered and understood; consider using visuals instead of excessive copy like the above screenshot from production.
With classic themes, customers would need to change the appearance of blocks outside the block editor; with the block editor, we should link them to templates in the right places, where they can change the order of blocks and make changes to them:
WordPress and Jetpack can feel complicated, but we must make it easy and turn-key. Meanwhile, we shouldn't lose the power of allowing customizing everything or having excellent support for all the 12K WP themes.
While each feature should feel great individually, they also all need to be tied together and work well: