Replies: 3 comments 2 replies
-
|
Thank you for your thorough testing and descriptions! Several of the things you mentioned are known and some fixes have already been built, but needs to be merged into either Gutenberg or WordPress core. To reduce the confusion the first time you open the site editor, there will be a new Welcome Guide, During the transition period when features are being moved /ported over from Gutenberg to Core, there will be overlaps, and they should be solved before the release of WordPress 5.9. -- |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your reception and clarifications. As I am not currently on a team, I considered it appropriate and polite to surface my perception as a discussion rather than creating misaligned issues. |
Beta Was this translation helpful? Give feedback.
-
|
👋🏼 Just wanted to quickly address some of what you raised and connect some dots. Thanks for the thorough feedback! I hope the following helps encourage you to chime in in various places and helps show how these problems are being currently discussed/addressed.
You can see more context here but this is essentially to provide a place to delete and rename menu items (not yet possible to edit directly from there but will be in the future): #36126
For context from the Glossary: "Template parts are equivalent – in blocks – of theme template parts. They are generally defined by a theme first, carry some semantic meaning (could be swapped between themes such as a header), and can only be inserted in the site editor context (within “templates”)."
This is being discussed here: #30496
It might make sense as 5.9's release cycle continues to remove Styles and have it simply in place for the Editor (Beta) section since, in the future, I imagine a Styles tab like that would exist for something more like this: #32682 I do not think Customizer should be merged personally though as that's merging a bit too many concepts together.
I'm curious what your homepage was set to! When you enter the Editor that's what should show up (your homepage).
This would be a lot of information to take in, especially for blocks with more robust transforms. For example, here's an image block:
I worry this will get lost if moved so hopefully this helps gives more context as to why things are as they are :)
Interesting insights! It might help to share this feedback on this issue as your idea might impact the same problem described there for smaller screen sizes: #23968
This is strange to me as you should see up and down movers with the top toolbar. I'd be curious to see a larger video of this experience. You can also use list view to move items around with drag and drop: https://make.wordpress.org/core/2021/06/09/core-editor-improvement-improve-your-workflow-with-list-view/ Separately, if you're open to it, it would be great to have you be a part of the FSE Outreach program as we run through the flows in order to get more concentrated feedback to help influence the direction of these features. Here's the latest call for testing if you're curious: https://make.wordpress.org/test/2021/11/08/fse-program-testing-call-11-site-editing-safari/ |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your reception and clarifications. ❌ Invitation to help on the FSE Outreach program. My text was insufficiently clear: 1.1.2. Navigation Menus and Menus menu items. 2.1.1.1. Wording of template info.
❌ What was my homepage? 2.6.1. Top (block) toolbar. Good news regarding: ❌ The Post Title block "encountered an error". |
Beta Was this translation helpful? Give feedback.
-
@marceloaof I agree there's no need for 'Menus' and 'Navigation Menus' to co-exist as options for block-based themes. It might be a bug if you're seeing that. I think there is a chance for both classic menus and the new navigation menus to use the same or a similar editor (with lots of shared infrastructure). That's the next thing to explore in the Gutenberg plugin. |
Beta Was this translation helpful? Give feedback.
-
Hello. I read/watch a lot about Gutenberg development and I also sneak peek here on GitHub. Definitely a fan knowing all the details. However I use it rarely. Only today I tested the Site Editor, Global Styles and other improvements coming in WP 5.9. Although I knew very well what to expect and where to click in order to enable the new features, my first impression was not good.
In moments of serenity, I didn't know how to do some actions. I didn't understand some texts and icons. Result: I didn't know where to go. ='o As I said, I'm not a stranger to the project. Some parts of the block editor are confusing now. This did not happen due to the increase of features. Simply some little things are messing up the organization. I believe that my distance from the project is capable of revealing to developers immersed on the edge, what people are finding confusing about the editor. So I decided to create this discussion, in order to suggest what is not being properly addressed in every topic of confusion/issue I have found.
1. On WP-Admin:
✔️ I have read the discussion regarding Site Editor being exposed as an item inside Appearance menu, instead of a separate menu. I support the chosen decision, because my instinct was to search for the Site Editor inside the Appearance menu.
1.1. Apperance menu
❌ However, with the incoming new menu items, the general naming convention is confusing.
1.1.1. Templates and Template Parts menu items
❌ I thought "Templates" and "Template Parts" were the same.
✔️ Proposed solution: I understood in my practice that "Template Parts" is just a taxonomy registered for "Templates". If this is the case, it would be better, on WP-Admin, to follow the naming convention applied to Pages, Posts etc, and (A)rename Templates to "All Templates". (B)"Template Parts" could remain like that, or be renamed to "Template Categories".
1.1.2. Navigation Menus and Menus menu items
❌ I thought "Navigation Menus" and "Menus" were the same.
✔️ Proposed solution: I understand that the current plan considers both "Navigation Menus" and the experimental "Navigation screen" to co-exist in the future as a replacement for the current "Menus". Probably I miss something because this seems unnecessary. The current "Menus" could be hidden in block themes. The recent advent of "Navigation Menus" and wp_navigation is a viable replacement for current "Menus" in block themes, since a navigation block placed inside a Header is going to be the place where menus are in fact switched and we can also use Reusable/syncing blocks. Therefore, the experimental "Navigation screen" could not exist at all in block themes, since it is essentially mirroring the current/old scenario in which the navigation management was disconnected from the theme template and the navigation widget. "Navigation Menus" and the experimental "Navigation screen" could both become a replacement for the current "Menus", the first one being available only for Block themes, and the latter being available only for Classic themes. In any case, the menu item would inherit the old name, keeping the name "Menus". My focus is in reducing confusion.
1.1.3. Editor (beta) and Theme Editor menu items
❌ I thought "Editor (beta)" and "Theme Editor" were the same.
✔️ Proposed solution: I understand that "Site Editor" is going to supersede some of the features of "Theme Editor", more and more as time goes on. For example: immediately being able to edit Templates with Blocks (making use of Global styles, Dynamic pattern block + Webfont API) is fantastic because it reduces the need of many theme files. But "Theme Editor" is still going to be necessary: because (A) it has a tree view of theme folders and files. And (B) it is the only convenient way to edit just a little bit the code of a SVG or other file which is specific to the theme and applied in many block templates and posts. I could upload those SVG files to Media Library folder (https://site.com/wp-admin/upload.php), but they would be available everywhere, which is not needed. Result: considering there is a limit in which "Site Editor" can absorb "Theme Editor", "Media Library" which could be improved in order for "Theme Editor" menu item to become unnecessary. "Media Library" could receive tree view of (Uploads and Themes) folders, allowing the authorized users to not also add media, but also edit media. If I could edit SVGs and theme files through "Media Library", in the same way as I can in "Theme Editor", then "Theme Editor" menu item could be removed, reducing confusion. Meanwhile, "Theme Editor" could be renamed to "Theme Files", "Theme Folders", "Theme Library" or "Theme Manager", since "Theme Editor" is positioned to resemble a "File Manager".
1.1.4. Customize and Styles menu items
❌ Even "Customize" and "Styles" I thought were the same.
✔️ Proposed solution: I understand the developers' point of view: the scope of Site Editor is broader than what Customizer was able to achieve, and the technologies and APIs are different. Site Editor needed its unique name, in order for developers to maintain backwards compatibility to Customizer. But in essence, considering both features serve the same thing as before: Appearance, it was a constant thought: "why Customizer changed its name?" or "why would both co-exist?". In fact, Site Editor could have been named Customizer and vice-versa.
If "Customize" item menu still needs to be displayed in a block theme, because of plugins that may still register functions on Customizer, I suggest that you bring Customizer panels into Site Editor. For example: inside the Global Styles panel, there is "Typography", "Colors", "Layout" which mirrors existing features actually present on Customizer. Below them, it could exist: "Plugins" or "Old settings", with an alert of being deprecated. When clicking on that option, the Site Editor sidebar would show the options registered for the Customizer.
And then, on WP-Admin, "Editor (beta)", "Customize" and "Styles" could be converged to just 1 item menu. History, convenience, and long-term memory suggests me that "Customize" is the best name, but I have made 2 different suggestions:
2. On block editors:
2.1. Site Editor
✔️ Intro: when I clicked on "Editor (Beta)" for the first time, this is what I saw:
❌ It was confusing. The Main Reason For Confusion comes from the mixed uses in the upper right corner of the screen!
I am going to explain.
2.1.1. Template info
2.1.1.1. Wording of template info
❌ I thought I was editing a single page, because on the middle of the header it is written "Page" with a caret. Clicking on the caret doesn't help, because the immediate title inside the pop-up is "Page". Maybe "Page" could be renamed to "Pages", by the way. It was stressing me because I was not figuring out the name of this specific "page". And every time I was reading about "Templates", "Header" and "Footer" areas below the "Page" title, I was thinking: okay, these template areas are associated to this "Page" which I am editing. When in fact, it is the opposite: I was editing a template for pages which contains Template areas... "This is a template created for pages, not a template named Page", I had to understand. The "for" made all the difference. "Oh, so the template named" "404" is one among many templates created for 404. It is not the one and only "404" template.
✔️ Proposed solution 1: "Template" (or "Template for") could be written above "Page". Initially, I understood that "Template used to display individual pages." was the "Page description", instead of the "Template description".
✔️ Proposed solution 2: just writing the word "Areas" doesn't help me to understand this is a "Template Area." By the way, why are "Template Parts" (Header and Footer) being called as "Template Areas" here? Even if I'm getting something wrong and both nomenclatures exist, my insecurity in understanding these terms reinforces the solution proposed in 1.2.2.1: Template Parts or Template Areas could be renamed to Template Categories.
✔️ Proposed solution 3: "Browse all templates" could be renamed to "All templates". Because this is the naming convention in WordPress: "All posts", "All pages", "All Users". It clarifies the understanding of what is about to happen. When clicking on this "Browse all templates" button, I am going to see a WP-Admin table containing all templates. Only then I can browse for specific templates in the search bar. Also, I would like to say that the dark background is commonly used in WordPress to suggest a pressed state. It also reminds me of a "Send action" or "Login/Logout action", which commonly are colored on the internet.
2.1.1.2. Inverted template info
❌ When I clicked on "Header" blocks while editing the "Page" template, the title on Gutenberg's header changed from "Page + caret" to "Page + Header + caret". Please understand that the position of these words is beneficial to our understanding in English language, since "Page header" and "Page footer" also exist and are written in that order. However, in many languages, this order is difficult to understand (being preferable to switch the words). In English is not desirable for you to read "Header + Page" + caret", but in other languages, this is the position that makes sense. The current horizontal word order can also mean something else than intended!
✔️ Proposed solution: vertical orientation instead of horizontal orientation.
2.1.1.3. Duplicated template info
❌ When I understood I was editing a template regarding "Pages", I still did not understand why the same informations were appearing twice: both in the pop-up and in the right sidebar. Personally I preferred the pop-up, it was easier to understand because a document title commonly is indeed in the primary header of an application. Regarding the right sidebar, my impression was the following: here, the icon is specifically a gear, a symbol which invokes the notion of General Settings in applications, where I adjust options regarding the entire application. Naturally I would have disregarded the gear when searching for initial informations and settings regarding this Template file. In the specific scenario here, a pop-up positioned where I may have expected, in the upper header, also shows the name of the Template, which suggests me: (A) the pop-up may be the definitive place for adjusting the template file details; (B) and the pop-up is much more accessible than a gear icon which also has tabs for different purposes.
✔️ Proposed solution: please remove the "Template" tab from the right sidebar.
OBS: regarding pages and posts editor, maybe it is going to persist the necessity of showing some Post/Page info inside the right sidebar, instead of a pop-up. In this scenario, I would still separate the 2 tabs, allowing them to become their own right sidebar.
2.2.1. Block description
❌ Some block descriptions are long and occupy half of the right sidebar. Therefore, I need to scroll in order to adjust simple options as text color and font family. This is exhausting after dozens of times.
When we want to discover blocks, adding them through the block inserter, there it is a visual preview followed by the block description. This is already good enough for discovering blocks.
It may still be useful to show the block description somewhere, once it is added. OK. But could the block description not remain inside the block editing sidebar? Because it interferes with this activity.
✔️ Proposed solution: (A) to remove the block description from the block editing sidebar. (B) I believe where it makes the most sense to show the block description is by hovering the block icon. Currently, a pop-up is already there, subverting the icons, because it only allows for transforming the block. I have already asked myself in the past: what am I trying to transform to? Only showing the block icon do not tell me immediately the block name. So, it sounded good to merge the block name and/or description with the transform pop-up, just below the block icon.
2.3.1. Post Title block name
❌ One of the first blocks available in the default template was the "Post Title". I am familiar to this block, because I commonly add "Post Title" blocks inside Query Loop blocks, in order to retrieve the Title of: Posts or CPTs. When editing the "Page template", however, I did not immediately made the connection between "Post Title" and "Template Title", because indeed these expressions are different. I understand the scenario when a "Post Title" block is used to retrieve a "CPT Title" inside the Query Loop, but it was strange how the "Post Title" block was being used to retrieve the "Page Title" in this template. I thought: "okay, maybe there is a Query Loop in this Page template, which is trying to retrieve Post Titles". --> Suddenly, template, post and page were almost meaning the same (post title, template title = same block, different editor; page template, page title = different block, same editor).
✔️ Proposed solution: the "Post Title" block could have a different name according to the content type it is being edited. When:
2.4.1. Settings
2.4.1.1. Block settings
❌ The Post Title block "encountered an error". I happened to know that I would find settings for this block by clicking on the gear icon. But what would an occasional person have done? Probably it would taken a while for a person to click on the "three vertical icon" of the block, and subsequently click on "Show more settings". (A) I would not imagine to find a local setting for a block in the gear, which is a macro icon, and also happens to be on the upper header, the header of the application, instead of being positioned inside the Block Toolbar or in the Top Toolbar, where it makes sense for Block settings at least. Example: when I want to change the text color of my e-mail, I do not go to the gear/settings icon of the email provider app. (B) The Top Toolbar description is not correct. It describes explicitly "Access all block and document tools in a single place.". (C) There is another problem regarding Block settings: in computer screens with 1367px wide, when the browser is in one window, side by side with another window, although Gutenberg receives generous 779px wide, the Gear/Settings icon become hidden on the upper header. The scenario is difficult to adjust simple block settings. It would be better to reduce the gear icon size and apply set text-overflow: ellipsis on texts, instead of hiding the gear icon. (D) Specifically for the Post Title block, for some reason there were no settings available for that block, which worsened the scenario, because I indeed clicked to "open more settings". The right sidebar opened with two tabs available: "Template" and "Block". I thought: "okay, maybe in Site Editor the settings for the Post Title block are arranged inside the "Template" tab, and not on the "Block" tab. After all, I have already seen how Template and Block have such similar concepts in this Site Editor".
✔️ Proposed solution: it would make Gutenberg tremendously easier to use, if the right sidebar containing Block settings were to be triggered not by the pressed Gear icon positioned on the application header; instead triggered by an icon positioned inside the Block Toolbar or inside the Top (Block) Toolbar. I remember applications which solved this problem by placing a "sidebar icon" at the end of the pertinent toolbar, in order to indicate that a sidebar is going to be opened.
2.4.1.2. Editor settings
❌ On my odyssey to find "more block settings" and understand the duplicated "template settings", I also searched for settings clicking on the "three vertical dots" at the end of the upper header. On Site Editor, there is a "Settings" option there, which is confusing, because it does seem to be another category of Settings. And on Post and Page editor, there is a "Preferences" option, which is confusing for the same reason: there is already a "settings" icon.
✔️ Proposed solution: this entire drop-down contains options, settings and adjustments regarding the application-level. It makes more sense to move this drop-down, on the upper header, from the "three vertical dots" icon to the "Gear/Settings". Also, please remove the "Settings" option inside the drop-down, on Site Editor.
2.5.1. Styles icon
❌ I thought (Global) Styles icon meant "Dark mode".
✔️ Proposed solution: in order to retain user memory from Appearance/Customizer, different suggestions were made on #20873 and considered at least a brush or palette. Indeed, the current icon is used by applications in regards to dark mode.
2.6.1. Top (block) toolbar
❌ I can't move a block when the top (block) toolbar is enabled.
✔️ Proposed solution: when the top toolbar is enabled, keep the moving block toolbar available. The top toolbar is responsible for changing the current state of the block: adjustments and block settings. And the moving block toolbar is responsible for moving, removing, copying, transforming, duplicating the block: in its current state.
I tried my best to understand my confusion and explain it. I enjoy the editor as it currently is, nice work! But please take into consideration feedbacks like mine within the planning and revise what is needed, because there is room for improvement.
Beta Was this translation helpful? Give feedback.
All reactions