Visual / Text Toggle Design Clarity

[Titanas0]

The Visual / Text toggle offers a selection of one option but the design communicates there are more options available. Since the selection is binary a simpler design can reduce cognitive load, speed up the user's decision and provide more clarity.

An idea that works on desktop and mobile.

[jasmussen]

Thanks for the design suggestion!

I think the top left area is one we need to discuss, though perhaps we should do it as part of #1375, which discusses the concept at a higher level. The idea is that we have:

1. a visual editor you'll see in a stock installation.
2. a text editing mode letting you see the underlying markup
3. potentially other methods of editing

3 could potentially mean an other editing mode added by Markdown, or it could be a page builder.

Initially I designed the dropdown to essentially scale to having more than the classic two options, as seen here: #1375 (comment)

However switching from a page builder to text mode might not make sense. Similarly, switching from markdown to visual wouldn't either. So the question becomes, is it a binary switch or not? It certainly was in the old editor, but is there a better approach we can take?

One idea is to make the area as a whole editable by plugins. That is, we have one switch between visual/text, could be tabs like yours, and we let plugins replace the entire field with something else.

Another idea is to re-do the dropdown to be more expressive. Quick and dirty mockup:

[Titanas0]

To answer your question, it's not a binary switch anymore. And that's great. I think that's the answer to the problem.

A page builder exists because someone installed it. Either to solve a problem or just try it out. Someone put the effort to install something. The design should honor this decision and effort by showing the builder option right and front, next to the Visual and Text option.

Not only user preference is honored but the design language, the design pattern if you will, is consistent with mobile UX and UI from iOS (Segmented Controls) and Android (Swipe View with Tabs).

By selecting the Page builder option, a place holder text can be shown to notify the user that this is the page builder. No matter what the page builder UI and UX is, the placeholder text will offer a consistent experience among all page builders with no content.

If there are more than two page builder, the label can change to page builder with a a drop down.

A quick an dirty mockup as well.

[jasmussen]

Good thoughts here. Thanks so much for the mockups.

I'm still unconvinced that there's room for tabs, though. Your mockup is fairly wide, and doesn't include the save state. The bigger problem with tabs in that space is that they can be translated, and some languages like german usually have up to 30% wider text. We could JavaScript ourselves out of calculating the available space and converting it into a dropdown if there's not enough room — that's certainly an option — but I was hoping we could find something simpler.

[Titanas0]

Very good points i didn't think thoroughly. Will come up with something better.

[Titanas0]

@jasmussen i created a new idea, interactive prototype for a new, yet familiar design. https://framer.cloud/cqHDT/ (click on buttons)

If a page builder is installed only then the page builder button appears, honoring the user's decision and make it easy to find the builder. If there is no page builder then the Visual / Text button works as a switch.

[jasmussen]

Ah, great prototype! That's really interesting.

How would a user discover that the Visual block can be "double clicked"? Thanks for exploring this.

[Titanas0]

For starters it looks like a button, similarly to the Publish and Post Settings.
I am working on another idea to make it clear it's a button that can be clicked. Will update with another prototype

[hedgefield]

I see what you're going for - with only two modes of viewing the content, it makes sense that in one mode, you only want to go to the other mode (via a button). And a pagebuilder then is a different thing altogether. But there's indeed something in the way it's presented that makes it seem like Visual and Beaver are the only two options. One is selected, the other not. So I too was quite confused that you can click again on one of them to reach yet another mode. It seems logical to either have everything under one control, like the inserter, or split all options out as their own controls.

With the lack of document content in the prototype, it wasn't clear whether you are treating the button text as the state (this is visual mode) or as the action (this will take you to visual mode)?

[Titanas0]

@hedgefield i hear you and i've been thinking how this can be done.. a new design idea is attached addressing your concerns and previous comments. It's still buttons but it's a button - switch twist to make it more clickable and honor the presence of a builder.

This is the design with a button - switch in cases there is no builder available

This is the design for a builder installed but the is user still in Visual mode

This the design for when the builder is installed and activated

[hedgefield]

Hey nice, that's a cool look!

[Titanas0]

@hedgefield thank you.. i hope we can find how we can improve even further 👍

[mtias]

Going to close as the "text mode" has been moved to the ellipsis menu. Thanks for all the explorations, very helpful to present all the possibilities and see where they lead.