Gutenberg-mobile: Default to Gutenberg upon opening a block based post

[hypest]

Let's flip the "default for new posts" switch to true the first time the block editor is launched, if the switch is off.

We currently have a popup showing up the first time the block editor launches that informs the user This post was originally created in the Block Editor, so we've also enabled it on this Post. Switch back to Classic at any time by tapping ⋮ in the top bar..

The idea now is to flip the switch and inform the user that it's now default for new posts. The same popup may be used for the purpose.

PR's:
WPAndroid: https://github.com/wordpress-mobile/WordPress-Android/pull/10133
WPiOS: https://github.com/wordpress-mobile/WordPress-iOS/pull/12066

[hypest]

👋 @iamthomasbishop, we chatted about that over video in the recent team hangout but, can you confirm that this is OK with you too? Thanks!

[iamthomasbishop]

Sounds good! 👍 :shipit:

[marecar3]

@hypest @etoledom I have updated the description with WPAndroid's PR.

[etoledom]

inform the user that it's now default for new posts.

The current alert says:

This post was originally created in the Block Editor, so we've also enabled it on this Post. Switch back to Classic at any time by tapping ••• in the top bar.

Since we are reusing the same popup, we probably need to change the text.

This post was originally created in the Block Editor, so we've also enabled it ~on this Post~. Switch back to Classic at any time by ~tapping ••• in the top bar.~ [explain how to toggle the switch off from the app settings?].

Also, what will happen with users that already closed the alert but haven't opted in to gutenberg?

[iamthomasbishop]

Since we are reusing the same popup, we probably need to change the text.

The more I think about this issue, the more I wonder if we should remove the dialog/alert altogether. Considering GB is in a stable enough state that we're considering activating it for new-posts by default, I think this dialog will cause more confusion than it's worth.

If we want to keep it, I would change the messaging to something along the lines of:

"This post uses the Block Editor, which is now the default editor for new posts. You can change this setting by going to Me > App Settings."

Thoughts? We'll also want to apply this same thing to Android when we've come to a solution. // cc @daniloercoli @hypest

[hypest]

The more I think about this issue, the more I wonder if we should remove the dialog/alert altogether. Considering GB is in a stable enough state that we're considering activating it for new-posts by default, I think this dialog will cause more confusion than it's worth.

👋 @iamthomasbishop , hmm, not quite following. At present, what we're looking to is make it the default only after the user opens a block-based post. Upon opening, an app setting will be flipped and it will be surprising to do such without giving a heads up to the user, no?

Also, the dialog itself only pops up the first time such a post is opened so the user gets informs it's not the editor they've been using before. Just removing the popup without replacing it with an onboarding flow can be surprising.

So, can you expand? What am I missing? 🤔

If we want to keep it, I would change the messaging to something along the lines of:

"This post uses the Block Editor, which is now the default editor for new posts. You can change this setting by going to Me > App Settings."

The previous message had instructions on how to switch to Classic for the just-opened post. You think it's better to remove it?

[etoledom]

The previous message had instructions on how to switch to Classic for the just-opened post. You think it's better to remove it?

Since we are changing the switch from settings, I think that the instructions should be about the switch itself. Keeping both instructions (switch from settings and go to classic from the current post) might be confusing.

[marecar3]

I am giving +1 to @etoledom's proposal. It would be very clear to the user.

[marecar3]

Hey @etoledom, please, can you confirm, did you implement on iOS like it's described here: https://github.com/wordpress-mobile/WordPress-Android/pull/10133#issuecomment-507678682?

[etoledom]

I haven't really implemented this yet. But I did have a fast look to the implementation and I believe that what is described there would be the default behavior. 👍

[marecar3]

I have put these strings in the WPAndroid app :

This post was originally created in the Block Editor, so we\'ve enabled it for the new Posts.
This post was originally created in the Block Editor, so we\'ve enabled it for the new Pages.

Let me know what do you think.
@hypest @etoledom @iamthomasbishop @daniloercoli

[etoledom]

Updated description with WPiOS PR.

I used the text from https://github.com/wordpress-mobile/gutenberg-mobile/issues/1186#issuecomment-508231868 for consistency, with a small tweak:

... so we've enabled it for ~the~ new Posts.

Always open to edit this text if needed.

I also noticed two more small details:

• If the user flip the switch ON before opening any gutenberg post, should we still show the alert?
  
  
  
  • I though we shouldn't since the user already opted in. I implemented it in this way.
  
  
• This automatically flipping of the switch will trigger the track event: AppSettingsGutenbergEnabled on iOS.
  
  
  
  • I though this still is desirable so I kept it. But whether we want this or not, we should be sure that we do the same on iOS and Android regarding this.
  
  

[etoledom]

There is also one more small detail found by @koke here: https://github.com/wordpress-mobile/WordPress-iOS/pull/12066#pullrequestreview-257903408

I would argue that it would be good to make it flawless ✨
It's true that it would be a very uncommon case, but for the few who would experiment it, it would be quite annoying.

[hypest]

• This automatically flipping of the switch will trigger the track event: AppSettingsGutenbergEnabled on iOS.
  
  
  
  • I though this still is desirable so I kept it. But whether we want this or not, we should be sure that we do the same on iOS and Android regarding this.
  
  

Same on Android as far as I see in the WPAndroid PR. Should be fine but, I'm not sure what value this track would offer if we trigger it in this (automatic flipping) flow too. I think we should either add a property to differentiate between the user-initiated switch flip and the automated flip or, not trigger the track at all when in the automated flip.

[etoledom]

So, we propose this text as the final text for the Popover to show users:

"This post uses the Block Editor, which is now the default editor for new posts. You can change this setting by going to Me > App Settings."

cc Editorial 🙏

[kristastevens]

Hello @etoledom, thanks for the ping! I have some suggestions:

Block Editor Enabled
This post uses the Block Editor, which is the default editor for new posts. To enable the Classic Editor, go to Me > App Settings.
OK

[marecar3]

Hey @kristastevens not sure if we should use capital letters when we are referring to Block Editor or Classic Editor: https://make.wordpress.org/core/handbook/best-practices/spelling/
cc : @etoledom

[kristastevens]

Curses! Foiled by capitalization.

USE “classic editor” instead of “Classic Editor” WHEN referring to the classic editor interface and not the plugin.

Revised:

Block Editor Enabled
This post uses the block editor, which is the default editor for new posts. To enable the classic editor, go to Me > App Settings.
OK

[marecar3]

Thanks @kristastevens !

[marecar3]

On WPAndroid strings are updated based on the latest proposal from @kristastevens.
I think we are ready on the Android side.

cc: @etoledom, @hypest, @iamthomasbishop, @daniloercoli

[koke]

Same on Android as far as I see in the WPAndroid PR. Should be fine but, I'm not sure what value this track would offer if we trigger it in this (automatic flipping) flow too. I think we should either add a property to differentiate between the user-initiated switch flip and the automated flip or, not trigger the track at all when in the automated flip.

I think the event should fire, as it was meant to track the opt-in rate. Even if the opt-in isn't voluntary, we still want to know how many users are getting it. Adding a property to differentiate auto vs manual sounds fine in theory, but do we have any actionable use for it?

[etoledom]

but do we have any actionable use for it?

I agree that this might not be needed. We should expect a bump on this event overall and we will know that this change had an effect. That's probably enough specially given the short-living time of this change.

[hypest]

but do we have any actionable use for it

and

We should expect a bump on this event overall and we will know that this change had an effect

That's the thing. The spike will be equivalent to "application upgraded" ∩ "editor opened" ∩ "has blocks" at that point and will be unrelated to user's intentions or preference. Being able to filter that out via a property should be enough. In any case, this is not a blocker for the PR.

[etoledom]

Updated the WPiOS with the last version of the string.

Since we haven't changed behavior, WPiOS is ready to merge as soon as WPAndroid is ready too 👍

We can update the Analytics property on a next PR if we decide to.

[marecar3]

Hey, @etoledom WPAndroid is merged right now.
Be free to merge WPiOS!

[etoledom]

Merged WPiOS! 🎉