Iterating on the "Options" settings

[mtias]

The settings screen has been growing gradually over time. It harbors important features and new items are already being worked on (like text only buttons). We should improve a bit its design to make it more usable and scalable.

Thoughts:

• Length of options name is all over the place. Some options require additional context, but it should be provided by proper description text.
• Some of these options should be toggles and not checkboxes compared to their function in other places of the user interface.
• Categorization can be improved: a name like "Keyboard options" is redundant when we are already within an "Options" modal. It could make sense, for example, to have a "Blocks" category for the "most used" item and to also link to the "block manager". Disabling the "block directory" as a whole is also something that might be required here.
• Some of the settings explored in Add more writing flow options: Reduced UI, theme styles, spotlight #22494 also make sense to be configured here.
• We need designs for things that might have more than one state (like buttons: icon only, text only, icon + text).
• It's likely the design would need higher level navigation as it grows in categories. Perhaps a design like what @dubielzyk is exploring for the document header could be a good fit down the road.

Example from iOS on a good use of description text to contextualize settings:

[ZebulanStanphill]

I think options like "Top toolbar", "Spotlight mode", and "Fullscreen mode" ought to be moved into this panel. To me at least, they seem like user preferences that one isn't expected to toggle on/off very often... so why are they always taking up space as the first things in the ellipsis menu, and not even grouped next to the Options modal?

Thumbs up on renaming "Keyboard options" to just "Keyboard" or something like that.

I'd consider renaming "Document panels" to "Visible document panels" to make it a bit clearer what the checkboxes actually do.

Adding extended descriptions to some controls is definitely a good idea, particularly in the case of the "Contain text cursor..." option.

I wonder if perhaps we should rename the whole modal to "Preferences" or "Editor preferences". "Options" feels a bit too broad of a term, in my opinion; the term "options" could technically refer to a tool like the "Copy all content" button. Additionally, a label like "Editor preferences" helps to clarify what actually belongs in the modal, and distinguishes it from the "More tools & options" label that the ellipsis menu uses.

[mtias]

Another thing I'd like to try here is to employ the "drill-down navigation" pattern that is being developed for a few of the site editing features to scale setting groups better. That might allow us to combine the block manager fully as well.

[ZebulanStanphill]

One thing we need to keep in mind regarding the organization/layout is accessibility. What's this "drill-down navigation" like? Is it like the Customizer's navigation? Because I've seen the accessibility team criticize that for being very inaccessible due to how its implemented. That's not to say it can't be implemented accessibly, but we need to tread carefully to ensure what we end up with is an improvement for everyone.

In terms of immediate actions to improve the Options modal, what do you think of renaming the modal to "Editor preferences"? That would help specify what kind of "options" it's supposed to provide, and prevent it from sounding too similar to "More options" and "More tools & options". I can spin up a PR with that change, if you think it's a good idea.

[karmatosed]

I am exploring this and wanted to first cover what are the requirements and scope for this. After that, I have a design.

The end goal for iterating the Options settings is:

• Improve scalability and be able to grow as more are added.
• Increase usability of options, including more than just toggles/checkboxes.
• Increase understanding of options through helper text, categorization and editing of copy.
• Consider what can be brought in and combined.
• To bring inline with the latest styling. There is an opportunity to iterate the screen to reduce things like horizontal lines and align with recent interface changes.
• To explore what adding higher-level navigation could bring taking the work explored with document settings as a grounding here. A further suggestion of exploring the navigation from site editing was also added last week.

I would love feedback on anything that should be added or removed from this list.

Exploration

I have explored a flow based on the above. This uses a modal but brings in navigation where options are all surfaced. Here is the flow:

Here you can see in the context of the full screen:

A few points around this:

• Block manager has been brought into this area.
• The splitting of sections can be reduced, the deciding factor should be how much a section will grow.
• The modal would be fixed height, the content would scroll, following, for example, the Slack preferences interface pattern.
• During the explorations I did explore the drill-down menu, however, for this type of menu in a modal, it felt more fitting to have everything surfaced. Whether as more content is added revealing menus are needed will be something to discuss, however, the surfaced single-level menu is my recommendation based on the near future.

Discussion

I am looking for feedback on a few specific areas:

• The goals I outlined, specifically anything to add or remove.
• The design shared and where to take or not take, the next iterations.
• I am also interested in feedback on what other options to bring into this area, getting a list would be a great benefit if more than I have considered should be brought in.

[enriquesanchez]

I really like this exploration, @karmatosed!

The goals I outlined, specifically anything to add or remove.

I think this exploration addresses the goals you outline above. It's simple and easy to understand and I think it will scale well with time. There's now enough room to improve and expand how we present all of the options and as I've started working on #3218, I can already see how this new layout will accommodate the UI we'll need.

The splitting of sections can be reduced, the deciding factor should be how much a section will grow.

I agree we should try and be mindful of this. We don't want the list of sections to grow unwieldy. I will start by removing 'General' from this list. I think it'll just end up being the place where things end up by default.

How about something like this?

• Appearance
  • Fullscreen
  • Show button text labels
  • Top toolbar
• Blocks
  • Enable the Most Used Blocks category in the block library
  • Block manager
  • Reusable blocks
• Document
  • Pre-publish checks
  • Panels
• Keyboard
  • Shortcuts
  • Customize shortcuts
• Writing mode
  • Compact UI
  • Spotlight
  • Theme styles

[ZebulanStanphill]

Nice mockup, @karmatosed. I like the idea of making more use of the horizontal space. I just have two questions:

• How does it work on mobile?
• How does keyboard navigation through it work?

[enriquesanchez]

How does keyboard navigation through it work?

@ZebulanStanphill I think we should follow the Tab panel design pattern from the WAI-ARIA Authoring Practices.

[ZebulanStanphill]

In terms of immediate actions to improve the Options modal, what do you think of renaming the modal to "Editor preferences"? That would help specify what kind of "options" it's supposed to provide, and prevent it from sounding too similar to "More options" and "More tools & options". I can spin up a PR with that change, if you think it's a good idea.

I went ahead and made a PR for this: #25683.

[ZebulanStanphill]

@enriquesanchez I see how that would work for large viewports, but what about skinny mobile viewports? Wouldn't we have to collapse the tabs into a hamburger menu or something?

[kellychoffman]

Design feedback:

• Hierarchy needs to be clearer. For example, Options look like the header for the sidebar only, when its the header for the entire modal.
• Has the appearance of a wireframe and could use more attention to detail and visual refinement. Use the research you did into competitor analysis as reference to ensure this ui is as good or better.
• Sidebar and content are visually treated the same and their functions are not immediately clear.
• Explore adding a section header in the content area.
• +1 to designing the mobile view

[ZebulanStanphill]

The header should probably just be styled exactly like it does right now in master, for consistency with other modals.

Thumbs up on adding a section header to the content area.

[karmatosed]

Thanks, everyone for such great feedback. I took a bit some time to iterate using the following as my guide:

• Clarify hierarchy: not only with options but throughout.
• Refine the visuals: focusing still on not bringing in additional grey, but increasing spacing and use of line-height, type. This will be covered more as additional screens are worked on.
• Create a header: add in a header for options text to modal and bringing back in a horizontal line for that definition, something Slack for example does.

Iterations

For now, I have iterated just single screens as a start, I will then create the flow again once have feedback.

The second changes the header in content to be a call to action, which other applications use, some of ours might fit this more easily than others.

Feedback

I want specific feedback around those 3 areas of hierarchy, refinement and the header. Of course, I welcome more general feedback. My next goal is to iterate and then work on mobile along with rest of feedback, I wanted to focus on specific points first.

[ZebulanStanphill]

I think the tabs still need more headings, e.g. the "General" tab's content are should begin with a "General" heading before any sub-headings.

Headings are used for identifying the names of areas to screen readers... I don't know if "Adapt how block work:" is a proper heading with that in mind. I'll defer to @afercia on that question.

One thing I'm wondering about is why the first mockup uses checkboxes and the other uses toggles. If I recall correctly, we're using the toggle design whenever something is supposed to have an immediate effect. But all these options have an immediate effect except (I think) the "Advanced panels" section, which requires a page reload to take effect.

[bph]

There have been quite a few popular expansion /replacements on the Block Manager using WPAdmin pages.

Early designs (in context of the Block Directory) on Figma

Fabrica Reusable Block instances

I leave it at those two examples and here is a screenshot of one of the panels, envisioned.

To manage block entities properly, especially Block Patterns, reusable block and blocks from plugins, the content creator needs to know how often a block has been used or not used.
I had hoped that those admin screens would be reconsidered when the Block Directory was implemented as per their early explorations.

Managing all the entities (Blocks, Block Patterns, Block Styles, Block plugins) should be possible but it needs much more data displayed for it to be useful.

[afercia]

Moving the "Options" title to the modal dialog title is appreciated, as it will be used for labelling the role=dialog by the means of aria-describedby. Also: a visible modal dialog title helps all users.

Regarding the panel headings, I wouldn't say ""Adapt how block work:" would be a good heading. It doesn't immediately explain what the panel content is about. Headings are not only visual things, they're used to get a sense of the content and also as navigational tools thue they need to be meaningful.

I wouldn't have strong objections to implement this as an ARIA Tabs design pattern but, based on experience, I do know tabs don't adapt well to smaller screens. As also pointed out in previous comments, on smaller screens these tabs would need to be rearranged and if we want to keep the ARIA Tabs pattern they would need to stay at the top of the panel. That means rearranging them in two or more lines which is, honestly, not nice to see.

At this point, on small screens there would be the need to transform the ARIA Tabs pattern into something else, for example: a dropdown menu that changes the active panel. Technically, this would be complex to implement because there would be the need to build two alternative UIs that switch at a certain viewport width.

Overall, an ARIA Tabs pattern adds value when there's the need to organize a big amount of content in a limited space but it also introduces a more complex keyboard interaction model compared to the current implementation. In the current modal dialog there are just sections and groups of checkboxes: it's way simpler to navigate. Are we really sure that an ARIA Tabs pattern is the best option here? To me, it also adds visual complexity, as most of the options are initially hidden and need to be "discovered".

Aside: I'd like to know more on the "drill-down navigation" pattern. If that's some sort of "sliding in-out" sidebars à la Customizer, then it's a huge barrier for accessibility as @ZebulanStanphill mentioned. Not a news, since the customizer sidebars pattern has been discussed for years for its accessibility and usability problems.

[ZebulanStanphill]

@bph Is there a dedicated issue for moving block management out of the editor UI? Because that seems like something we should do regardless of what direction the Options modal goes.

[bph]

@ZebulanStanphill Yes there is....
#15121

[mtias]

While we explore all the design improvements, there's a smaller task that we could do in time for 5.6 which is:

• Improve the copy of each setting, make them more concrete and cohesive (some are many words long, some just a few)
• Utilize longer descriptions when necessary (similar to "Top Toolbar") to provide more context.
• Reorganize the main sections.

[mariohamann]

First of all: I really like those new "Options" (or Preferences?)

@kellychoffman raised the following question in #3218 (comment)

Popovers/modals usually have the CTA button (Save) to the far right.

I'm asking myself, if this is common behaviour for "Preferences", too – and I thought it would be better to discuss the topic here.

Different questions arise from this:

• Should preferences directly show an effect? What's the users' expectation?
• If we have buttons to save – what happens if someone clicks in the area "behind" the modal – will you lose every setting or will there be another modal to ask "You have unsaved changes. Do you really want to revert them?"
• How important is it to "revert" the settings someone made? (Would be possible with a "cancel" as secondary button.)

I had a short look at different applications.

Google Drive uses "OK" and "Cancel" buttons for their preferences, being in a modal window, too.

iOS System Preferences, macOS System Preferences, macOS Application Preferences and VS Code Prefences don't use buttons either.

Twitter and Telegram use kind of "Contextual buttons" – I could find buttons in language settings, but nowhere else. Maybe the buttons are used because they completely change the content (not only the appearance) of the current view.

Currently I have the feeling that It's fine to omit buttons (as being shown in the designs above) and use them contextually.

Here is the Figma file with my collection. I will add examples, if I see something new.
https://www.figma.com/file/WwbLC4uG5BGW38ZlCRh9uz/Save-button-for-preferences?node-id=0%3A1

[karmatosed]

There has been a fair bit of work on this in the recent release across a few PRs, so looping it all back into the existing mockups. Then work can begin on picking up iterating this again.

Here are the copy and position changes in place:

[mariohamann]

Thoughts on the "Panels" area:

Classic Editor

With classic editor there are different display settings for different screens, e. g. in menus/navigation, page overview, edit page, edit post.

Connection between settings

• In Classic Editor, those settings are not connected, saying: If you disable Featured Images for Pages they still show up for Posts. In Gutenberg this behaviour is changed: Panel settings are applied to every post type, e. g. if I hide featured images for posts, they are hidden in pages as well.
• → I think it would be nice to inform the user, that those settings are applied everywhere, e. g. "The following settings are applied everywhere."
• Personally I question this behaviour, sometimes e. g. you need Custom Fields only for one single Post Type. But I think I should open another issue for this one.

Available options

• In Gutenberg, at the moment if you are in settings for edit post, the options for categories and tags show up, if you open settings for pages, they don't. How will this be handled in the new "Preferences" modal? It feels strange to me, that the options differ, as this settings feel so "global" and especially if the optiones are applied everywhere.
• Of course you could show every option in the panel, but with more custom post types and custom taxonomies (thinking of shops etc.) this could be quite a mess.

Scalability

Thinking of the currently available options with Classic Editor, I think it is important, to have scalability in mind. IF it will be possibe to set different settings for every screen (and if Gutenberg will take more and more screens), toggles could become handy.

To make it more usable, the current screen could always be shown at the top and open.

[bph]

Looking forward to using this new screen in the new future of Gutenberg plugin!

I appreciate also the projection in the future. I can see how the Site Editor will bring a heap of new options/preferences, as will Global Styles. A first version could also show a way how 3rd party plugins are displayed. I am fairly certain that there will be a need for developers to provide preferences for their features into this screen, too.

[karmatosed]

@mariohamann some great thoughts around the panels area, thanks. I really appreciate your consideration of what we have and where this could lead.

Thinking of the currently available options with Classic Editor, I think it is important, to have scalability in mind.

I am nodding my head as this feels key to what is being created here. We can't predict and shouldn't all the preferences to come, but we can set up patterns and interactions to use in future.

I really like the idea of showing current screen at the top. I am not sure you need to know the page name beyond it being current, but that's a good thing to dig into. When you have 'edit' beside is that editable? I'm trying to work out what that interaction does and would love to explore more.

@bph I absolutely agree that this could grow as an area, I think thought needs to go into that growth, but it's worth doing. It could easily become a drawer to hide things in, so exposing and finding ways for the content to make sense and be discoverable is key.

[mariohamann]

When you have 'edit' beside is that editable? I'm trying to work out what that interaction does and would love to explore more.

Oh. It was meant to be the "Edit"-Screen with the editor vs. the "Overview"-Screen, where all posts are listed. :)

Edit Screen for Pages:

Overview of pages:

[karmatosed]

Interesting @mariohamann. I think in that case I might have a found a point to be iterate as to what that means here. I think there's a problem with overwhelming in this section, so reviewing how distilled it can be for first experience and then how someone could go deeper to customize, feels like a good path to me. I know that's a little vague, but it might avoid having everything surfaced and therefore leading to potential confusion.

[mariohamann]

At the moment the "Overview" sections are not needed, as there is no Gutenberg. But the difference between pages, posts, CPTs, products etc. might be VERY important soon.

[karmatosed]

@mariohamann I agree in considering them. What I don't like currently is 'advanced' panels. I understand why they are advanced but sitting in preferences it seems to not fit so well. There's room to visually explore some variations here around combining, but also not having repeating headers like (edit) or anything else duplicate. It might be near future and not fully in scope of this issue, but I would love to see your exploring there if you are following a path.

[karmatosed]

I have an update on preferences, which hopefully will get towards next steps moving into development.

Full screen iteration

This flow considers all the current changes and brings in key points raised in conversation within this ticket. Specifically the things this implements are:

• Hierarchy: bringing in label, body and other styling.
• The change in modal size and addition of a border to define header.
• Sections: I have iterated these and will list them out after showing the prototype.

Smaller screen

On smaller screens I would recommend adjusting the menu experience to a full modal. Here is a prototype:

List of each section

As there are a few changes and options moved, I thought listing the suggestions out would help with feedback.

General

• Pre-publish checklist
• Reduce options and outlines (changed copy from reduced UI)
• Spotlight mode

Appearance

• Display button labels
• Use theme styles

Blocks

• Show most used blocks
• Contain text cursor inside block (this removes the singular keyboard category)

Block manager
Moving this entire manger here.

Panels
No changes beyond copy.

Extra options

We don't have these options currently, but as this issue outlined at the start, providing a range of settings is useful going forward.

Here is a mockup of some of those on a fictional page using potential features.

As you can see in this there is a visual to show potentially the light and dark interfaces. What could be shown in those images is something to iterate on. I chose toolbars as they don't repeat UI, but should still show the impact as important to know.

---

Feedback

I am interested in general feedback, but specifically around the sectioning and menu structure would be really helpful.

The extra options I would like to get feedback on any upcoming features I might be missing to add in areas that need interfaces not shown. I realise I went fictional on some to explore, so keeping it focused around incoming features probably is a great point moving to the next step and into development.

Next steps

Once feedback has happened, if required iterations can happen and then moving to development would be ideal for this issue.

[karmatosed]

As this has sat for a little while to get feedback, let's move the feedback labels to 'needs-dev' and see about progressing these iterations.

[mtias]

Nice to see this iteration :)

[hedgefield]

This looks fantastic, thanks for the designs @karmatosed! Would love to ship a first version in 5.7, what can we do to get this into dev?