View and edit modes

[koke]

The design for 1.0 has two different editor modes: view and edit.

@iamthomasbishop I have a few clarifying questions about these:

• How do you go from one to the other? From view you need to tap the edit button, or tapping on any block switches to edit mored? From edit, dismissing the keyboard goes back to view or is there another way?
• Does the "Save changes" button just go back to view mode or starts the publishing flow?

[iamthomasbishop]

@koke Happy to see this part being tackled :)

How do you go from one to the other?

I hope this blueprint flow attached below helps clarify. Essentially:

• From edit mode, the checkmark icon will save the changes
• From view mode, you can double-tap on any part of the canvas, and the cursor should be placed as close to that point as possible. You can also tap on the Edit button on the bottom toolbar

Does the "Save changes" button just go back to view mode or starts the publishing flow?

This saves changes (remote if possible, locally if necessary). The publishing flow should start when the user taps Next. I've also considered that we might want to include publishing directly from the ••• menu in Edit mode, but I'd like to keep the publishing entry point to a single spot (via "Next" button on View mode).

[iamthomasbishop]

It's also worth noting that the flow above represents what it could look like on Android. This flow should be roughly the same on iOS, and look like this:

Notable difference is text labels instead of icons in most places, general flow is basically identical.

[koke]

That's clarifying, thanks. I only have some doubts about the double tap to edit, why not a single tap? What would happen instead when you single tap on a block?

[hypest]

To add to what Koke asked above, this seems to also be related to the focusing logic? Do focusing/unfocusing and view/edit relate to each other in some way?

[koke]

Considering we're reusing the apps' existing top bars for 1.0 and we're also not doing the new publish confirmation flow yet, this can wait until after the first beta.

[iamthomasbishop]

That's clarifying, thanks. I only have some doubts about the double tap to edit, why not a single tap? What would happen instead when you single tap on a block?

@koke this behavior mimics other apps that utilize similar edit/view flows. IMO it adds just the right amount of friction between the modes, and feels natural. I'm not opposed to single-tap focusing, this is just utilizing a common pattern.

Do focusing/unfocusing and view/edit relate to each other in some way?

@hypest I'm not exactly sure what you mean here, but the intention here is to separate writing vs. viewing contexts so that actions are clearer and more appropriate to the task. In terms of focusing/unfocusing – that's mainly left to edit mode, but you should be able to "enter" into focusing a single block as described above. Nothing groundbreaking, just following established patterns.

[hypest]

The web implementation of Gutenberg now has a "Unified Toolbar" mode which is ofc very similar to the mobile bottom toolbar, and where almost all block controls are living. Only the up/down buttons to move the block are outside that toolbar. I wonder if that toolbar mode can help clarify or remove the distinction between a view mode and an edit mode. I.e. can we try moving all controls to the bottom toolbar, remove the inline toolbar and find a place for the up/down functionality?

[iamthomasbishop]

The web implementation of Gutenberg now has a "Unified Toolbar" mode which is ofc very similar to the mobile bottom toolbar, and where almost all block controls are living

IIRC, the unified toolbar doesn't exist on small breakpoints on web. On desktop, the unified toolbar is a win in terms of consistency of placement, but the top bar quickly starts to feel very visually cluttered, and mixes a bunch of different types of tools. IMO, if we start shoving all of the tools into a single toolbar, we start to dilute clarity.

can we try moving all controls to the bottom toolbar, remove the inline toolbar and find a place for the up/down functionality?

Undo/redo: I'm unsure about placing the undo and redo in our Quick Toolbar because for the same reasons as above (clutter and mixing functions). But because undo/redo is requested so regularly, we decided to roll this into the toolbar as a start.

Up/down arrows: I think these can probably be removed altogether eventually, but only if we drag & drop is seamless, which I'm unsure is likely in the initial versions.

Block Settings: I can see moving the block settings (cog icon) to the Quick Toolbar, but I worry about them getting buried and therefore being less discoverable. From various observations/tests, we've gathered this is an important function to keep surfaced.

Ellipsis/overflow: Depending on its importance (and what we end up putting in there), we could also move this to the toolbar but again the concern is discoverability. If there is something they want to do that's in that menu and it's buried, they'll have to dig for it.

---

With all of this, this is just a starting point. We should plan on testing more extensively when we have a functioning prototype and iterate quickly where necessary.

[shiki]

This looks really nice!

I'm concerned about the Save Changes (checkmark) button in Edit mode. I would expect that to be a Cancel button instead. Based on the funnel created by @maxme (see paCBwp-84-p2), about 84% of iOS users open the Editor only to eventually exit and discard their changes. But perhaps showing the View mode first would fix this. 🤷‍♂

[koke]

about 84% of iOS users open the Editor only to eventually exit and discard their changes

That funnel was using an unreliable event, the number is more like 33%.

I would expect that to be a Cancel button instead

Keep in mind that Android already saves without asking on closing, and iOS is headed in that direction.

I think when this was first explored, we didn't have any sort of autosaving (except on closing on Android), and I still think that's the right direction to go.

I don't know what the exact roadmap for autosaving is, but ideally, the editor would autosave periodically as you edit, and the checkmark/done button should just switch modes, encouraging the editor to save the content remotely if it hasn't already.

[iamthomasbishop]

Ideally, the editor would autosave periodically as you edit, and the checkmark/done button should just switch modes, encouraging the editor to save the content remotely if it hasn't already.

Completely, 1000% agree – this was the intention. In cases where auto-save is not successful while editing, tapping the checkmark should at very least save the changes locally. My hope is that we can do all of this behind the scenes so that the user doesn't have to stress about it.

Related to autosaving: We have heard in usability tests that users appreciate being able to see a small indication of some sort, so they have confidence their changes are saved – this is because people find writing on mobile, in general, to be unreliable.

[shiki]

Thank you for the answers, @koke and @iamthomasbishop. I agree with what y'all said. 👍

[SergioEstevao]

@iamthomasbishop do we still need to implement the edit/view modes? or are the design aboves outdated?

[iamthomasbishop]

@SergioEstevao Yes, we still need to implement this. We decided early on in the project to postpone this feature because it was expected to be a large one and could wait until we had the foundation built. Maybe now’s the time 🙂

We haven’t substantially changed the designs/concept since the original proposal, so when we’re ready to prioritize it, I can do an updated blueprint and make some more detailed notes.