-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
If you want to make Gutenberg a success ... #6003
Comments
I don't agree with everything above... But there are some pretty valid points here. |
Disclaimer: I am just a fellow user. Not a WordPress or Gutenberg developer. What follows is my opinion alone. It should be noted that, like how TinyMCE Advanced adds more options to the Classic Editor toolbar, plugins can be used to extend the core Gutenberg blocks and add whatever formatting options (including inline ones) that you want. Additionally, it should be noted that you can already add all sorts of inline formatting to blocks by using the "Edit as HTML" option, and it will be considered as valid. So the idea of a plugin adding extra formatting options would actually work especially well as, like TinyMCE Advanced, it would not break the site when deactivated since the inline formatting would still be considered valid (the visual toggles/sliders/etc. would just be gone). Like how TinyMCE Advanced is a plugin, so should other advanced formatting toggles and sliders that are rarely used be a plugin. Most formatting options that people would want are either already in Gutenberg or should be handled by the theme. (Any case where you would want to change a particular formatting option for every instance of a block means that setting should be changed at the theme level, or at least in the Additional CSS box in the Customizer.) Gutenberg (and WordPress in general), in my opinion, is designed to provide a good core that can be extended, and not include every formatting option possible by default. The question that should be answered then, in my opinion, is what options should be included with the core blocks by default? You make a good point about changing the color and size of headings. If you can do it with paragraphs, then one would think you would be able to do it with headings as well. Of course, in most cases you want your headings to have a consistent look, and so it would be handled by the theme (which could style how they look in Gutenberg along with the front-end). Changing the size of one particular heading seems like a bad idea that probably should not be included as a visual option by default... because why would you change the size of a single heading when their size is supposed to be an indicator of the organization of the document? Of course, you could always change it with the "Edit as HTML" option, but including it as a visual control seems like it might just bloat the interface with an option that will not be used much. I can see how it could be useful, though. But I am not sure its usefulness is high enough to warrant adding it to core with a visual option. Advanced users who are making particularly unique layouts will most likely know enough HTML to modify headings themselves, and the average user would likely not need to use the option, since the h2/h3/etc. options (used properly or not) would likely provide all the sizing variation they need. And either could use a plugin that adds the setting (and a plugin to add the setting as well as many others would be relatively simple to make). And a plugin is where I would say that setting belongs, though I am not entirely sure of that. As for color, however, I think that option would be far more useful and far less likely to interfere with the purpose of a heading, so maybe they should have an option to change their color in the advanced options / block inspector. In fact, I decided to make an issue about it: #6012 It should also be noted that other issues have been made regarding other blocks and options that could be considered for inclusion in core. I recommend opening separate issues for each particular option you would like to see added to the core options for certain blocks, as well as commenting on the other issues with your thoughts on whether those particular settings should be included by default or not. Of course, the broader issue of the core blocks not having much of a standard set of settings is something that could be discussed and reconsidered, though I would recommend opening a separate issue for that. As it is, you have kind of jumbled several issues into one ticket, which makes focusing discussion on a particular subject difficult. As for releasing Gutenberg with 5.0 or not, I do think that the release of WordPress 5.0 should not happen until the APIs in Gutenberg have stabilized and plugins have had the time to get used to it. As for the user interface of Gutenberg, I do think it has gotten a lot better lately (drag and drop of blocks just got merged! 😄), though it could still use some improvements, like making the sibling inserter easier to discover. (See #6009.) I also think a first-usage tutorial needs to exist, and that seems to be in the works in #3670. I also think the columns block (which is currently experimental) should finish being polished and be included in 5.0. I would not like for it to be delayed into a future release. I also think the proposed section block in #4900 should be included in 5.0 as well. |
Thank you for the thoughts, @burnuser, and for the followups. We're certainly not planning on releasing WordPress 5.0 before its ready, there's still a lot of testing to do, and bugs to fix. 🙂 The best way to make Gutenberg the best it can be is to use it, test it, and build things with it. Making it work for the entire WordPress world means we need feedback from as many different people as possible. Because the initial comment in this issue is a fairly large collection of feedback, I'm going to close this issue, but I'd encourage you to comment on the issues that @SuperGeniusZeb linked to, or create individual issues for specific problems you run into. |
If you want to make Gutenberg a success ...
You should rethink your way to establish it as a new core feature.
Big changes take time to be accepted and implemented!
Plugin developers need motivation and time to implement necessary changes. Motivation is generated by a sufficient user base. Time starts with a stable Gutenberg interface with a stable technical interface in a production environment.
So, deliver and promote a production ready, stable Gutenberg editor as a standardized (but not activated in advance) plugin with WP 5.0 - and let it be a plugin for at least a year. Give users enough time to discover Gutenberg and its prospective advantages. Convict users and plugin developers, that Gutenberg is a good idea. And if you are right, they will accept it.
And that's the time to move Gutenberg into the core.
Conviction instead of force!
Force generates resistance, conviction wins supporters. Focus on giving people a tool that enables them to express their own creativity in as many ways as possible. Give them more (not less) options to decide for their own how they design webpages, instead of removing options, that they are used to.
Take for example TinyMCE Advanced plugin (https://wordpress.org/plugins/tinymce-advanced/): Anyone can configure it according to personal needs. Selection and arrangement of all TinyMCE formatting options is completely free. If you want only a few basic tools in your editor interface, you can remove all other. If you want all available tools in editor, you can have them!
And yes, not everything could be managed as a block: sometimes inline formatting for single words/characters (color, background color, font type, inserting special characters, ...) is necessary. Not only in paragraphs but even in headings, lists, quotes, and all other blocks with text.
A second example is the width of editor interface: take width from theme (like TinyMCE Classic) and make a fallback to a fixed width, if needed. And make selection of width a user choice in screen options (600/840/free to define/large as possible = screen width)
Stop even thinking on ruling the world!
You are not the masters of the universe! And you are not the senior teachers for webdesign!
If you want to give advise, write it in help files, tooltips and handbooks. But the userinterface is a tool for users and not a vehicle for your personal preferences! And just because you are programming the interface does not mean that your personal views are crucial.
Respect counted user needs. For example: More than 2 Million installations of "TinyMCE Advanced" declare a real need for inline formatting! A lot of reviewers are complaining about the too small editor interface!
And stop justifying your arbitrary decisions with misquoted WCAG guidelines, which apparently no developer has ever really read!
Example "link title": According to WCAG H33 (https://www.w3.org/TR/WCAG20-TECHS/H33.html) the title attribute is not forbidden. In fact it is stated as helpful but maybe not sufficient because not all screen readers support it. So, you can use it - and should use it. Because it's better than nothing for accessibility AND there are billions of people out there, which don't use screen readers and find tool tips like "link title" very helpful!
Example "open link in new tab": According to WCAG 200 (https://www.w3.org/TR/WCAG20-TECHS/G200.html) opening links in new tabs should be limited for some reasons, but is not forbidden and even recommended in special situations: "However there are some situations where it is preferable from an accessibility perspective to open a new window or tab."
By the way, tabbed browsing is a worldwide web standard for many years. Even if you don't like it, it's not on you to change that!
And even if using an option (like inline formatting for single words/characters or hyperlinks with "link title" or "open in new tab") may be not every time a good idea, it's not on you to decide that for all users in advance! If you don't want to use such options, don't use it. Nobody must use all existing options. And being WCAG conform can't be automated anyway. If someone wants to do that or - for whatever reason - has to do that, he must read and follow all guidelines with great care. But removing basic web options from WordPress because "sometimes it may be better not to use them" can never be the answer!
Do your job!
According to Matt Mullenwegs communicated vision of the future of WordPress, Gutenberg has one single task: establishing blocks as new, standardized, onetime to learn, use everytime in the same way, element of organization in WordPress. Starting with the editor, followed by menu and widgets until whole site design.
That's a really big task. And you should not mix it up with other changes.
Make Gutenberg blocks run without any problem. - And establish a standardized basic set of common formatting options for all blocks: Background (color, image, opacity), Font (type, size, color), Border (line, thickness, color), Alignment (left, centered, right), Distance/Space (above, below, left, right, to border), ...
But you do not have to reinvent the wheel. Learn from well established Page Builders like SiteOrigin, Elementor, Beaver Builder and others how to use and layout multiple sections, columns and elements/blocks. Best practice would be a good start for Gutenberg!
In the moment the options are different for each Block and the opposite of standardized and onetime to learn! (For example changing color and size of text in paragraphs, but not in heading or list or any other block makes no sense anyway.)
But beyond this standardized implementation of blocks, everything should look and work as people are used to with WP 4.9. Don't hide Classic block - use it as standard! Don't remove screen options and help at the top. Enable shortcodes inline. And, and, and ...
Do what you can, that WordPress users have all options and possibilities, in which way they are used to.
Of course you can add more options to demonstrate the power of Gutenberg - an convince users and plugin developers.
But never ever remove any options or possibilities of WordPress 4.9 in the course of the introduction of Gutenberg!
That would make Gutenberg - and the responsible developers - an terrible enemy for all users who use/need these options!
Don't destroy Gutenberg and WordPress as a whole (and losing the confidence built up over many years) with unnecessary complications like removing (much needed) design options.
Focus on blocks as standardized new design element, as powerful as possible. With not less but even more possibilities!
And then ... Gutenberg can become a real success!
The text was updated successfully, but these errors were encountered: