All your editors are belong to us

  • I am not Gutenberg’s target market. I don’t use the current editor to create posts, and I won’t use Gutenberg, either. I use an external MD editor, paste the HTML into the editor, proof, and publish. That means my use of the editor is minimal, but at the same time critical: it’s where I’m making last-second changes, adding images, etc.

    I had just created a post, so I went through the normal process with Gutenberg on my local test site.

    The Good
    It did not get in the way. I’ve only tried one post, but no crashes, no hiccups, etc.

    The Bad
    Everything requires more clicks than it should. Today I can change between visual and text view with one click; Gutenberg requires two (click on the 90-degree inverted ellipsis, click on which view I want). Today I can choose the Category directly; Gutenberg requires me to open the Category list, then choose. Same for Tags. And Excerpt. That’s a lot of extra taps for every single post. (I do not care about keyboard shortcuts. I don’t have to use/remember them now, I don’t want to have to use them in the future.) Everyone of those should be directly accessible as they are now. And, since it’s a common refrain amongst the WP people, this is not “fear of change.” This is “extreme dislike of change that makes me less productive.”

    Image re-size handles go on the corners of an image, not the sides. That is universal across all platforms, apps, etc. I looked for quite a while for how to resize the image before I tried the sides out of desperation.

    Image captions can be bolded and italicized, but can’t be justified left/right/centered. Why is that? Oh, it’s probably defaulting to the CSS for an image caption.

    But then why do paragraphs have justification buttons? Are they overriding the CSS I have for a paragraph? Why, yes they are, apparently. How are they doing that? Text mode shows both ornamentation and a couple of classes added to my <p> attribute, but where are those classes? What does their CSS look like? They’re not in my styles.css.

    This does not appear to be limited to paragraph blocks. It appears that any block can override the theme’s CSS. WHAT? And where is this invisible CSS? What control do we have over it? From all appearances, none. So authors can format their posts however they want to, with no regard to how I’ve set up the site’s theme? And someone (multiple someone’s) thought this was a good idea? Here’s a hint: it’s a T-E-R-R-I-B-L-E idea. This is, by itself, a deal-killer.

    I changed to text view, added an unornamented <p> block to the post, and then went back to visual mode. That paragraph was marked as “Classic”. What does that mean? How does it impact formatting, if at all?

    Lots of questions. Where are the answers?

    The Ugly
    Nowhere. There’s no user documentation (a sample post is not documentation). Why the Powers That Be at WP think it’s a good idea to foist a new foreign editor on 27% of the web with no documentation is a mystery worthy of Agatha Christie.

    To summarize:
    The Design Mistakes
    Too many clicks. All of the above-listed things should be one-click away.

    Independent CSS. This is a giant, colossal, Death-star sized screw-up. If you want to allow extra formatting in the editor, great. But it should be dependent on CSS that exists in the theme’s CSS. If you want to say to us and theme editors, “To allow background text colors in a paragraph block, add these classes and Gutenberg will use them; if they don’t exist, then background colors won’t be allowed in the editor.” then great. If you want to provide a gutenberg.css in core and give us a way to revoke it and incorporate our own classes in our theme’s CSS to replace it (including with a subset), also fine. But what Gutenberg’s doing now is openly hostile to your entire user-base.

    Image handles—on the corners, not sides. Rule #1: Don’t stray from a universal standard. Rule #2: if you think you have a good reason to do so, you don’t.

    The Bugs
    I put the cursor in the middle of the text in a paragraph block and hit Enter. It created a new block following with the text after the cursor. So far so good. I then hit Ctrl-Z to undo it. It copied (not moved) the text in the new block back to the first block, but the second block remained with text intact. A second Ctrl-Z removed the second block. I can repeat this at will, in multiple posts.

    To clarify: imagine I put the cursor in the above paragraph in front of the “I” in “I then hit Ctrl-Z” and hit Enter. I then had two paragraph blocks.

    I put the cursor in the middle of the text in a paragraph block and hit Enter. It created a new block following with the text after the cursor. So far so good.

    I then hit Ctrl-Z to undo it. It "moved" the text in the new block back to the first block, but the second block remained with the text intact. A second Ctrl-Z removed the second block. I can repeat this at will, in multiple posts.

    The first Ctrl-Z then resulted in this.
    I put the cursor in the middle of the text in a paragraph block and hit Enter. It created a new block following with the text after the cursor. So far so good. I then hit Ctrl-Z to undo it. It "moved" the text in the new block back to the first block, but the second block remained with the text intact. A second Ctrl-Z removed the second block. I can repeat this at will, in multiple posts.

    I then hit Ctrl-Z to undo it. It "moved" the text in the new block back to the first block, but the second block remained. A second Ctrl-Z removed the second block. I can repeat this at will, in multiple posts.

    The second Ctrl-Z then resulted in this.
    I put the cursor in the middle of the text in a paragraph block and hit Enter. It created a new block following with the text after the cursor. So far so good. I then hit Ctrl-Z to undo it. It "moved" the text in the new block back to the first block, but the second block remained. A second Ctrl-Z removed the second block. I can repeat this at will, in multiple posts.

    I only did one action — I hit “Enter”. A single ctrl-Z should undo all of the effects of that Enter.

Viewing 10 replies - 1 through 10 (of 10 total)
  • Moderator Samuel Wood (Otto)

    (@otto42)

    www.ads-software.com Admin

    Just some notes I jotted down while I read your review.

    • Changing between the visual view and the code view is not something that it is generally desirable for most people to do, even with the current editor. The idea is that things should be available in the editor, not having to know HTML is the goal.
    • The various openable sidebars on the right hand side, like Categories, seem to remember where you last left them and remain open or closed depending on your usage.
    • Image handles on the corners of an image imply that the image can be reshaped. Since the image stays proportionally the same in both height and width, the sides make more sense for the handles.
    • I agree that the image captions should have more controls on them, including alignment.
    • I don’t see any “justification” options on paragraphs, but if you are speaking of the left/center/right alignment buttons, it adds style=”text-align:right” (or similar) to the paragraph element itself.
    • Yes, styles are put into the text. This is no different than using the same tools in the current editor though, styles are added there too. Users already have the ability to put in the HTML they prefer to use, overriding the theme. It’s their site, it’s their text.
    • Gutenberg actually has the ability to use pre-defined templates for the editor for specific custom post types. This means that you can define a specific template as a series of block types, and assign those blocks attributes which are fixed and cannot be changed by the editing user. For example, if you have, say, a “testimonial” then you can define it as an image block, force aligned left, then a paragraph block with whatever fixed attributes you want on it. When that template is used, new blocks cannot be added, and your settings cannot be changed. So, it is possible for things like plugins or custom code to define things in a way such that they fit into a specific mold intended for them.
    • Classic blocks are literally everything that is not inside a defined Gutenberg block. This uses the classic TinyMCE editor, where you can add what arbitrary HTML you like to it.
    • Themes can of course override the default CSS. However, there has to be some base set of defaults in the editor, since expecting thousands of themes to add new classes and support immediately is too big of an ask. But yes, themes can of course define their own CSS and add to or override the default base CSS. If they do so, then that will show up in the editor, not just on the front end of the site. Themes actually have had the ability to style the editor itself since WordPress 3.0.

    BTW, Gutenberg understands markdown pretty well. Try pasting in your MD document directly. See what happens. I bet it’s not perfect, but it does a pretty neat job.

    I was also able to reproduce the return-then-control-z behavior. I had tried it earlier to see how a background color worked and would have sworn it “control z’ed” correctly. When I tried it again after reading your review, the block followed the behavior you described.

    Thread Starter vr8ce

    (@vr8ce)

    1. That’s not really your call. Whether you think it’s desirable or not is immaterial — *I* think it’s desirable, and I’m the user.

    2. For Categories/Tags, that’s good. (I only did one post, so I didn’t see that it stuck.)

    For excerpt, however, it’s still bad. Where excerpt is currently placed in the standard editor, at the bottom of the post and having a full-width entry box, is vastly preferable to the tiny box on the sidebar. That box only holds twenty 5-character words, which means scrolling, which means hard-to-read. It needs to be moved back to the main window, or re-thought entirely. The sidebar is not a good place for it.

    3. No, they don’t. They imply they can be *resized*, which is why they are (again) *universally* used. Every image editor/manipulator defaults to keeping proportions when re-sizing. And therefore, no, the sides do not make more sense, because they are completely non-standard.

    6a. The current editor puts *tags* (blockquote, code, etc.). The worst thing it does is put an align style in the p tag, and I’m not a big fan of that, either, but it’s self-contained and obvious.

    Gutenberg isn’t doing that (on the example I gave, the background color). It’s inserting (or using) invisible styles and/or CSS. Those aren’t close to the same thing. I repeat; it’s a deal-killer.

    6b. And, no, it is not necessarily “their” site. Large numbers of sites have multiple authors, and those authors don’t get to freelance their formatting. The site CSS exists for a reason.

    7. I don’t care what it can do with custom post types. I don’t use custom post types. Nor does it address anything I was talking about.

    8. You missed the point. The point was no documentation. (Plus your answer doesn’t really address all of my questions, anyway.)

    9. You missed this point, too. I don’t want to change the behavior of the *editor*. I want to prevent the editor from changing the look of my *posts*. To stick with the same example I’ve been using, I don’t want colored backgrounds in posts on my sites. I don’t want any author to be able to create them. Again, the site’s CSS exists for a reason, because that’s the way the site should be formatted. I want the editor to respect that. (And I mentioned a way to get around your “big ask”. That was off the top of my head. I’m sure the WP team could come up with another half-dozen better ways to do it. The point is it should be done by *respecting the site’s CSS*.)

    And thanks, but no, I’ll stick with my own MD editor. What type of Markdown is Gutenberg using? (Standard, Multi, Github, Common, etc.) What revision of whichever one of those is it using? How does it handle footnotes? Superscripts? Feature X? (Again, no documentation.) Why would I jack around with what Gutenberg may or may not be doing instead of going with I *know* my editor is doing? No reason whatsoever.

    On point 2, regarding Tags, Excerpts and Featured Image. These now have a fixed position in the interface and can’t be moved or arranged anywhere you want, like you can with the current WP editor backend.

    Yes you can, to a degree, move third party metaboxes but they are limited. There is also a bug tha,t if you don’t have any metabox below the content editor area, you can’t move any metabox from the siebar to that location.

    So, you start with a basic install, install Yoast, create a post. The Yoast metabox is in the left side bar. There are no metaboxes under content. The interface won’t allow you to place Yoast under content. As for returning a metabox to the sidebar…good luck with that. Suffers from the same “no metaboxes over here, I’m not taking any in syndrome”. To rectify the metabox arrangement, you need to, ironically, pay a visit to the classic editor, where you can arrange to your hearts content.

    In fairness, this moving of third party metaboxes bug is noted and they are trying to fix it but there are other issues.

    In addition you can’t collapse the content area, as you can in the current editor or, move a metabox to the top, under the title.

    You may well ask why one would want to do all this furniture re-arrangement. Simple answer. It allows you to set up the interface for any given workflow. I have a site of artist’s prints. The very first thing, after the title, that I want to enter is an image of the print (Featured Image), then details such as dimensions and medium, which are in a custom field group metabox and, them the description. This best suits the data entry use case I have set up. On another day I decide I need to do some work on keywords, so I drag Yoast to the top of the pile. I can do all this with the current editor.

    And, as a side note, the aesthetics. The overall whiteness of the Gutenberg editor is a killer, with very slight definition between all these control areas and metaboxes. We need the bit of grey between the metaboxes so they can be targeted and easily found on the screen. Yoast has a mock up of this on their blog and basically it suggests the Gutenberg interface should only have been a drop in replacement for TinyMCE.

    Bottom line. While the Gutenberg interface has a lot of merit, has potential to address some issues where WordPress is lacking, potential to add some really intuitive and new functionality to WP, the single minded zeal of focusing on this one central content creation experience, to the determent of a lot of other use cases, ignoring them in fact, is its weakness.

    • This reply was modified 6 years, 3 months ago by irishetcher.
    • This reply was modified 6 years, 3 months ago by irishetcher.
    • This reply was modified 6 years, 3 months ago by irishetcher.
    • This reply was modified 6 years, 3 months ago by irishetcher.
    Moderator Samuel Wood (Otto)

    (@otto42)

    www.ads-software.com Admin

    @vr8ce I was not “answering” you in any way, I was just making notes. Then I shared my notes. You’re free to ignore them if you like.

    Thread Starter vr8ce

    (@vr8ce)

    You use “you” throughout your notes (if “you” were speaking of…). “You” is a *personal* pronoun, and in this case the person was me. And then you replied to my post with those notes. That’s the definition of “answering” someone. I’m not sure why you would try to indicate otherwise, but whatever makes you feel better.

    I shared some “notes” correcting some of your erroneous conclusions in your “notes.”

    • This reply was modified 6 years, 3 months ago by vr8ce.
    Moderator Samuel Wood (Otto)

    (@otto42)

    www.ads-software.com Admin

    I just didn’t want you to feel like I was criticizing you in any way. Sorry if that was the case.

    Thread Starter vr8ce

    (@vr8ce)

    I did not take it as such. I disagree with several of your “notes,” and gave reasons why, but that’s not personal, either.

    Bottom line. While the Gutenberg interface has a lot of merit, has potential to address some issues where WordPress is lacking, potential to add some really intuitive and new functionality to WP, the single minded zeal of focusing on this one central content creation experience, to the determent of a lot of other use cases, ignoring them in fact, is its weakness.

    This is the absolute truth of this situation and why Gutenburg should not be included in core. WordPress is many things to many people, and many developers/managers have shaped and adapted it to create the CMS and web people use. WordPress is, by a long way, not only for independent bloggers writing blog posts, even if it once was. None of my clients should be formatting the content except for applying tags like h1 and blockquote. Any other styling is what I wrote style.css for.

    The sites myself and many others have built using WordPress are not nice little ‘my holiday’ blogs by someone who should have complete control and stylistic freedom. They are bespoke sites shaped around what WordPress has always been, and facilitate the inclusion of varied content types on the frontend, according to my, the web developer’s specifications. Make it optional.

    • This reply was modified 6 years, 3 months ago by 21stcn.
    • This reply was modified 6 years, 3 months ago by 21stcn.
    Andrew Nevins

    (@anevins)

    WCLDN 2018 Contributor | Volunteer support

    @21stcn, Thanks for taking the time to give feedback. Would you have time to create a review here: ? Hopefully some of your concerns can be answered: https://www.ads-software.com/support/plugin/gutenberg/reviews/?view=all#new-post

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘All your editors are belong to us’ is closed to new replies.