Site editor: Add Browse Mode

[MichaelArestad]

Currently there are two cursor modes in the editor: Edit and Select. They look like this:

@mtias suggested it might be nice to explore the idea of a third mode allowing the user to browse around their site within the editor.

@shaunandrews quickly proposed some designs for it.

In order to focus the discussion, I create a prototype using Shaun's design to get an idea for the feel as well as a new issue. The other issue is a bit dated and messy and I'll likely close it shortly.

Prototype i1

Try the prototype.

The biggest change is the removal of the text at the bottom of the popover. I'm not sure that was scalable in the long run. Instead, there are short descriptions with each tool to help the user get a rough idea what each is for. Perhaps we could also integrate hotkeys like in other menus? The hover/focus states should not change so I didn't include them in the mockup.

Screenshot

Source figma file

Ideas for improvements

• Shaun mentioned it might be a good idea to show a visual indicator to make it clear what links can be clicked. Perhaps a hover/focus state?

CC @epiqueras since I know you were interested.

[epiqueras]

Nice.

The biggest change is the removal of the text at the bottom of the popover.

Which text?

Perhaps a hover/focus state?

A tooltip?

[husowisback]

I think it is a very nice feature but unsaved changes should not be lost.

[SchneiderSam]

And please give us shortcuts for the respective modes :-)

[ghost]

I always imagined this to be the intention of the Select mode. Reorganizing blocks, which currently is the reason for Select mode, is still editing, or sub-editing at best. While Browse mode, in fact, is when Selecting content happens (affecting links the most, but not only).

One can also point out that Browse mode is the Preview mode. (Just 2 diferent approaches on previewing/browsing on content - with or without the editor).

[MichaelArestad]

Which text?

@epiqueras The text shown in the current popover (Screenshot in the original comment above): "Tools offer different interactions..."

A tooltip?

Possibly. I'm not sure just what yet. In other prototype I outlined clickable links with sort of a blue border.

I think it is a very nice feature but unsaved changes should not be lost.

@husowisback I agree. Any ideas on what you would like to see? Perhaps clicking a link triggers an autosave (if possible)?

And please give us shortcuts for the respective modes :-)

@SchneiderSam Totally. There already are for Select mode and Edit mode (esc and enter)

One can also point out that Browse mode is the Preview mode. (Just 2 diferent approaches on previewing/browsing on content - with or without the editor).

@marceloaof You're right. The biggest difference is that hopefully, in the future, we won't have to ever preview in another tab. What is seen in the editor will be so close, if not identical, there would be no need.

[mtias]

Any ideas on what you would like to see? Perhaps clicking a link triggers an autosave (if possible)?

Any navigation should be caught by the unsaved changes handler.

[epiqueras]

The site editor holds on to changes across pages. When you save, you'll see everything that has edits.

[mapk]

Browse + Preview modes

Currently we default the user to a “Preview > Desktop” mode, but they’re not really in a Preview mode. They’re editing their content in the Editor. So I’d submit that the “Preview > Desktop” should not be toggled “on” by default.

Proposal

When “Preview” is toggled “on” for any of the screen sizes, the user cannot edit the page, but can only browse. They’d be able to click on any links and jump to those pages/posts/anchors. When toggled “off” they’d return to their editing.

CONS

We had looked at responsive block settings in the past (#13363) that hasn’t progressed much. This would not be possible if the Preview mode triggered the Browse mode.

Prototype

Screenshot of Preview mode topbar

In Preview/Browse mode there are a few things to notice:

• The topbar is void of any editing icons.
• The Document Inspector automatically hides and cannot be opened.
• An X to close the mode appears in the upper right corner replacing the ellipses that was there.

Desktop

Tablet

Mobile

[dubielzyk]

Here's another Browse/Preview mode idea. The goal was to make the Preview mode distinct from edit mode. Also added a tooltip to make it super clear how to exit this mode.

[mapk]

@dubielzyk I like your tip to draw attention to the close button. Smart!

[shaunandrews]

I like what I'm seeing here.

Looking at the GIFs above I have some hesitation around the message we send by having a distinct "Preview" separate from the WYSIWYG promise of the canvas. I didn't have this reaction when I was thinking of it as a Tool or Mode (like Select and Edit).

We had looked at responsive block settings in the past (#13363) that hasn’t progressed much. This would not be possible if the Preview mode triggered the Browse mode.

This is a bummer. I wonder if there's another way to go about solving the problem of device/viewport-specific settings? Or a way to adapt the above designs to still allow for #13363 to happen?

In Preview/Browse mode there are a few things to notice:
• The topbar is void of any editing icons.
• The Document Inspector automatically hides and cannot be opened.
• An X to close the mode appears in the upper right corner replacing the ellipses that was there.

This is interesting, but I wonder if there are scenarios where it makes sense to allow for some editing? Perhaps the block inspector could serve a different purpose when in Preview/Browse. How does the UI adapt for the explicit Browse mode option?

I really like exposing the URL/permalink in the toolbar.

In general, I still have questions around how this works in practice. When I click on a link or button that points to a WordPress entity that I have permission to edit, I assume it will just load that entity in the editor. But for other links (external links, or links that point to entities I don't have permission to edit) how does this work? Perhaps there's some sort of indicator, warning, or tooltip that appears to tell me where a link will take me.

Outside of just links and buttons, how does a Preview or Browse mode work when I interact with things like a gallery, a file download, an embed, or a comment form?

For either a Browse mode or Preview, would there be a keyboard shortcut? I've often thought it would be nice to also have a modifier key (cmd+option, for example) that I could hold down while clicking to quickly enable navigating to a link within the editor.

[mapk]

This is a bummer. I wonder if there's another way to go about solving the problem of device/viewport-specific settings? Or a way to adapt the above designs to still allow for #13363 to happen?

I think it's worth exploring if we continue down a path that leads to a more traditional "Preview" mode. I will share some thoughts/designs on this soon.

This is interesting, but I wonder if there are scenarios where it makes sense to allow for some editing?

Perhaps. Although, if I'm previewing, my mental modal is already shifting away from an Edit mode.

How does the UI adapt for the explicit Browse mode option?

Aside from the examples above, I imagine it would work similarly to the Customizer. But even this brings up scenarios that need to be thought about further.

Currently, the Customizer only allows internal links to other pages/posts. You cannot download files while in the Customizer, nor can you click to an external site. It also looks like the Customizer doesn't render certain forms added in Gutenberg, but it does render the comment form (the submit btn isn't clickable). Some of these details should be thought through more IMO.

Customizer example

Thinking through details

• External links should not be clickable.
• Form submissions should not be clickable.
• Downloads from the Media Library could work, and maybe should work.
• All internal page/post links should work.
• Any forms in Gutenberg should be rendered, but submit btns not clickable.
• Galleries should work if the image is linked to something from the site and/or Media Library. In Preview mode, I don't see a problem clicking the media and getting the media file displayed by itself.

So for the items that can't be clicked, currently WordPress shows an "unavailable" cursor.

For either a Browse mode or Preview, would there be a keyboard shortcut?

There could be a shortcut that opens the Preview mode. But I think any sort of hotkey that allows navigating links from within the Editor would be something separate because that's really not entering this combined Preview + Browse mode.

[jasmussen]

It seems like the most actionable next step is to add the cursor in the tools menu, as initially suggested. This would let us build the mode itself with minimal UI changes, learn in the plugin what works, and inform next steps.

[afercia]

Any navigation should be caught by the unsaved changes handler.

I'm not sure this would be ideal. There are legitimate cases where users would just want to not save their changes and navigate to another page. Scenario:

• user edits a post
• user changes its mind: "oh no, better I add this new info in the other post xyz"
• user navigates to the xyz post
• however, the editor automatically saved the user edits to the previous post and the user isn't informed of that

I do think the decision should always be up to the user and this kind of automatic behaviors generally try to be a bit too smart, which is often harmful.

[mtias]

Sorry for the confusion, I didn't mean an automated save with the above. I meant the unsaved changes handler would by default be catching the state and prompting the user for what to do.

[helen]

Hello! I see that this particular issue has not had recent commenting activity and there's a lot of related discussion in associated issues, but I thought I'd leave a "personal opinion" comment here.

I think the idea of a "browse"/"view-only" mode is very compelling and if the theme handles it right with editor CSS, should ease that feeling of needing to keep the front end open and continue to do the "save and refresh" routine. If on first edit I move from the front-end to the editor and it essentially looks like all that's changed is that a toolbar has loaded at the top, that goes a long way to establishing that trust in the editor. I think we broadly agree that the ideal preview experience should be that visual editor, without the need to save something to the DB and do a full refresh. I also think that the current preview control, which IMO is really "viewport" (not just in terms of web terminology but also its normal usage), is applicable to both edit and view modes (or whatever they end up called).

Leaving aside the device/media query-specific editing for the moment while still keeping it in mind so we don't back ourselves into a corner, maybe it's time to unify all these discussions and move toward a unified view/edit + viewport concept?

[mtias]

Fully agree the "preview" control for different viewports is orthogonal to whatever the interaction mode is (edit, select, browse). I think we are barely scratching what the different "views" could be, since they could offer things like member / non-member, ads / no ads for a publication, or even things like "design structure", rendering lines for the different alignments (content, wide, full).

I think to keep this moving we should outline what elements a "browse" mode needs. For example:

• No toolbars.
• No inline editing.

It might also make sense to disable some sidebar plugins (the block inspector, possibly other 3rd party plugins). @ellatrix explored a while ago a "view only" mode for blocks in the context of https://make.wordpress.org/core/2019/09/05/defining-content-block-areas/

Keyboard navigation would also need to be considered (as in tabbing through blocks).

We might want to make blocks that have built in previews (like HTML) always render in preview.

[mtias]

I'd like to focus a first set of tasks around allowing navigation to occur from the navigation block only as we figure out the best UX, which we can then expand to site title, post titles, etc.

A complementary part of browse mode is the ability of blocks to render "inert" in the editing context, which is also useful for restriction purposes and has some overlap with the locking mechanisms.

[mtias]

Closing in favor of #36667