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:
Example from iOS on a good use of description text to contextualize settings:
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.
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.
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.
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:
I would love feedback on anything that should be added or removed from this list.
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:
I am looking for feedback on a few specific areas:
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?
Nice mockup, @karmatosed. I like the idea of making more use of the horizontal space. I just have two questions:
How does keyboard navigation through it work?
@ZebulanStanphill I think we should follow the Tab panel
design pattern from the WAI-ARIA Authoring Practices.
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.
@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?
Design feedback:
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.
Thanks, everyone for such great feedback. I took a bit some time to iterate using the following as my guide:
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.
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.
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.
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.
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.
@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.
@ZebulanStanphill Yes there is....
https://github.com/WordPress/gutenberg/issues/15121
While we explore all the design improvements, there's a smaller task that we could do in time for 5.6 which is:
Thanks for everyone's feedback. Currently, there are a few issues around options potentially to be worked on for the next release and then future work. Let's focus first on what is being worked on for the next few releases as a summary.
Looking at the feedback I wanted to take some time to respond to the point around block manager. I have been exploring some of the management. This doesn't mean it can't be explored more, however, I would, for now, caution looking at managing all the entities including styles, patterns, plugins through this interface. I am not saying it shouldn't be explored, but there is work going on by @MichaelArestad with the block directory I think can guide. Definitely, there is always more room for experimenting so not closing the door as much as trying to note this issue can grow rapidly.
It's important to focus in a little and as shown in #25837, look at ways to iterate with releases to improve options along the way heading to the ultimate solution. Perhaps one way to see this is iterating the options to be able to take other things, not add everything at once. This was noted right in the original issue specification and personally is something I keep coming back to, thanks @mtias for that note as I think it should be how we focus here. How can the foundation be set going forward for an options section that can grow?
My next step now the PRs are simmering for the release is to focus back on getting iterations to the designs, along with iterate those PRs, whilst we aren't going to get into this release, we can certainly look at being early for next here. However, I think focusing on what we do manage here (or not is key). Thank you again for all your awesome feedback and I look forward to more.
Other really great initiatives are going to connect such as the work @enriquesanchez is going with keyboard shortcuts, I'll be making sure to include that in the menu going forward, so following #3218 if you are interested in this area would be encouraged.
First of all: I really like those new "Options" (or Preferences?)
@kellychoffman raised the following question in https://github.com/WordPress/gutenberg/issues/3218#issuecomment-705930896
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:
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
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:
With classic editor there are different display settings for different screens, e. g. in menus/navigation
, page overview
, edit page
, edit post
.
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.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.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.
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.
@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.
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:
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.
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.
@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.
I have an update on preferences, which hopefully will get towards next steps moving into development.
This flow considers all the current changes and brings in key points raised in conversation within this ticket. Specifically the things this implements are:
On smaller screens I would recommend adjusting the menu experience to a full modal. Here is a prototype:
As there are a few changes and options moved, I thought listing the suggestions out would help with feedback.
General
Appearance
Blocks
Block manager
Moving this entire manger here.
Panels
No changes beyond copy.
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.
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.
Once feedback has happened, if required iterations can happen and then moving to development would be ideal for this issue.
Most helpful comment
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.