Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

Let's not forget to add release notes, though.

Hey there 👋 @iamthomasbishop !

Whenever you have a chance, could you please test this feature and give us your feedback?

Here you'll find the builds:

WordPress iOS PR-> wordpress-mobile/WordPress-iOS#14309
WordPress Android PR-> wordpress-mobile/WordPress-Android#12187

More info and screenshots here.

Thank you so much!

@geriux This is looking pretty solid already — nice work! After testing out pretty extensively, I've got a bunch of feedback which I'll try to keep succinct 🙂 I'm sure we'll need another round of review, but this should cover the big picture things.

Overfow menu

• Can we hide the paste action when there isn't anything in the clipboard to paste? (rather than just disabling it)
• On iOS, do we have access to the native Context Menu component? That might help to condense the menu a bit and also if we can get the menu to appear from near the ••• menu, we can have some proximity benefits. If we used that on iOS, perhaps it would be trying the Menu component on Android for consistency. (Examples of how this might work)
• I'm not sold on the "Cut" option, and because web also doesn't have it, I vote we remove it to conserve space as we add more items.
• I think we might want the labels on the sheet slightly more descriptive — "Copy block" and "Duplicate block", "Paste block", so it doesn't conflict/confuse with the native side (eg. while copying one part of a broader text string, "copy" means copy only that text, whereas in this context "copy" means the whole block).

Native select/copy/paste

• Are we able to connect with the native paste function so users can use the native edit/selection menu components to paste? For example, if I’ve copied a block from the overflow menu, tap on a rich text input to see the edit menu, then tap paste, the block I’ve copied is pasted. (example on iOS)

Notice component

• Can we also show notices when blocks are duplicated, pasted, or removed?
• Instead of stacking multiple notices when there are multiple at a given moment, can we substitute them? For example, if I perform an action that triggers a notice and then another action that triggers a second, they currently stack on top of each other. I think it might feel smoother if the second one simply replaces the first one (in the same Y-position, via a cross-fade or instantly)
• I've dropped updated styling for the component in the design docs here. The key thing you'll see is that I'm attempting to replicate the iOS-system materials on iOS, which produces a background blur and translucency. I talked to @wppinar today about potentially using a third party library called Blur if we're unable to access the system materials directly. Android uses solid colors, which we can fine-tune to use available colors if necessary.

Unrelated

• For the overflow menu in general, I wonder if long-pressing on an un-selected block (or the surrounding UI on a selected block aka inline toolbar) should show the overflow/menu sheet with all of the options? Here is an example flow

I'm not sold on the "Cut" option, and because web also doesn't have it, I vote we remove it to conserve space as we add more items.

Actually "Cut block" is implemented behind the scenes on web, but it is connected with Cmd+X. It is just not in the menu but the functionality is there. You can see this small notice on web when you do cmd+x:

And as you know you can drag&drop blocks inside/outside a nested block by pressing down the up/down buttons on web.

But we don't have a way to move a block inside/outside a nested block. In this sense Cut functionality is quite useful imo, and it is a quick win for us since we are already implementing Copy/Paste/Duplicate, wdyt?

👋 @geriux ! We're close to merging the monorepo changes 🎉 , and we will be cutting the release branches as soon as the monorepo changes are merged to gutenberg-mobile. As a result, we may be cutting the 1.31 release branches earlier than normal.

Because every merge further delays the monorepo work (ends up requiring conflicts to be fixed and other work due to the monorepo feature branch and the squash policy in gutenberg), we want to cut the release branch with no further changes. For that reason, I'll bump this milestone to 1.32. Of course, if this has to make the 1.31 release, go ahead and move it back to the 1.31 milestone, and let me know. 🙇

👋 @geriux ! We're close to merging the monorepo changes 🎉 , and we will be cutting the release branches as soon as the monorepo changes are merged to gutenberg-mobile. As a result, we may be cutting the 1.31 release branches earlier than normal.

Because every merge further delays the monorepo work (ends up requiring conflicts to be fixed and other work due to the monorepo feature branch and the squash policy in gutenberg), we want to cut the release branch with no further changes. For that reason, I'll bump this milestone to 1.32. Of course, if this has to make the 1.31 release, go ahead and move it back to the 1.31 milestone, and let me know. 🙇

Sounds good! Thanks for letting me know Matt 🙌

• I've dropped updated styling for the component in the design docs here. The key thing you'll see is that I'm attempting to replicate the iOS-system materials on iOS, which produces a background blur and translucency. I talked to @wppinar today about potentially using a third party library called Blur if we're unable to access the system materials directly. Android uses solid colors, which we can fine-tune to use available colors if necessary.

Hey, @iamthomasbishop 👋 I've added the library to test how it'd work, here's a light mode example and a dark mode one.

Is that what you had in mind? If it is I can prepare a build for you to test. Also, to double check, this is only for iOS right?

Thanks!

@geriux That looks great, glad to see you were easily able to implement it! I'm not sure what values you're using, but it feels a little thin esp on light mode. I'm looking over the library readme and it looks like we have access to various blurType properties — can you tell me which one you're using in the examples above?

In this sense Cut functionality is quite useful imo, and it is a quick win for us since we are already implementing Copy/Paste/Duplicate, wdyt?

@pinarol Fair points you made above, let's keep cut for now.

@geriux That looks great, glad to see you were easily able to implement it! I'm not sure what values you're using, but it feels a little thin esp on light mode. I'm looking over the library readme and it looks like we have access to various blurType properties — can you tell me which one you're using in the examples above?

I was using light and dark, here are other examples:

light (before)	regular (after)

dark (before)	prominent (after)

What do you think of those? If you want other examples let me know =)

Thanks!

@geriux I pulled these screenshots into Figma to compare against the system material equivalents I have.

• Dark mode: "Prominent" (RN) looks roughly equivalent to "Regular" (System), which is what I was going for 👍
• Light mode: "Regular" (RN) looks roughly equivalent to "Ultralight" (System), which is a bit thin 👎
  Can we try "Prominent" in light mode as well and see if that aligns w/ the "Regular" system material in the same way?

Another thing I think I'd like to do is to remove the border-bottom from both iOS and Android — I thought it might be necessary for separation, but it doesn't quite look right esp on iOS. I'll update the component on the Figma + design docs side.

Can we try "Prominent" in light mode as well and see if that aligns w/ the "Regular" system material in the same way?

Prominent (light mode)	Prominent (dark mode)

I think this one does look like your example, what do you think? I also removed the border bottom.

Let me know, thanks!

That looks great, let's roll with it. Nice work @geriux !

Side note: I think this will only look better when the Navigation Bars on the apps are all (eventually) changed to use the translucent materials. 😄