Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Surface user's visual editor preferences into the post editor settings panel. #18351

Closed
jmichaelward opened this issue Nov 6, 2019 · 4 comments · Fixed by #52737
Closed

Surface user's visual editor preferences into the post editor settings panel. #18351

jmichaelward opened this issue Nov 6, 2019 · 4 comments · Fixed by #52737
Assignees
Labels
General Interface Parts of the UI which don't fall neatly under other labels. Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress

Comments

@jmichaelward
Copy link

Is your feature request related to a problem? Please describe.
As a WordPress user, if I have checked "Disable the visual editor when writing" option in my profile preferences, I may have a confusing onboarding experience once I'm finally ready to try the new block editor.

A friend of mine, who is an infrequent user of WordPress, long ago checked this preference in his user profile because he preferred to write his content in HTML-only mode. Today, he reached out to a local Slack community asking how to add blocks to his content. Disabling the visual editor presents the content in a different way (different fonts, in particular, but which also disables the "+" button in the toolbar that allows content authors to add blocks), which led me to believe there was some kind of error or bug in his system, and we went down the usual troubleshooting paths before we realized he'd disabled the visual editor altogether.

Describe the solution you'd like
At a minimum, I would like to see us surface the value of that user's preference into the "more options" panel in the post editor preferences pane. Users who have disabled the visual editor altogether are not provided the option to switch between Visual and Code modes, and there is no other editor-based preference that reminds them that they have disabled Visual Editing altogether. It seems to make logical sense to group that preference with others relating to the post editing experience.

Naturally, while support for the Classic Editor exists, we'll need to continue to keep the existing preference inside the user preferences, as Classic Editor users do not have the post editing screen options available to them.

Describe alternatives you've considered
n/a

@mtias mtias added the Needs Design Feedback Needs general design feedback. label Nov 7, 2019
@mtias
Copy link
Member

mtias commented Nov 7, 2019

This is a good point.

@phpbits
Copy link
Contributor

phpbits commented Nov 9, 2019

@mtias How about having button to enable the visual editor? About to add on EditorsKit plugin but there seems to be no slotfill available on that area.

Screen Shot 2019-11-09 at 2 11 27 PM

@jmichaelward
Copy link
Author

I feel there are two important elements for consideration here. As a user who has disabled visual editing in my profile:

  • I likely will not want to have a persistent call to action present in the editor suggesting I re-enable it.
  • I may not understand the relationship between that setting and the new editor experience.

Importantly, the "Editor" setting in the attached screenshot is not visible when a user has disabled visual editing via their profile. See:

Screen Shot 2019-11-10 at 2 59 37 PM

My thought is that surfacing that setting there will better satisfy the two scenarios described above: leaving it out of view for users who truly wish to continue to write their content in this fashion, but unifying that preference with other editor-related preferences so that it is more easily discoverable.

@karmatosed
Copy link
Member

Starting with a button seems to make sense. Let's remove the design feedback label and get it in to see what we think.

@karmatosed karmatosed added Needs Dev Ready for, and needs developer efforts and removed Needs Design Feedback Needs general design feedback. labels Dec 18, 2019
@skorasaurus skorasaurus added General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback. and removed Needs Design Feedback Needs general design feedback. labels Jan 24, 2021
@danielbachhuber danielbachhuber self-assigned this Jul 14, 2023
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Jul 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels. Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants