20 Comments

  1. Mary from London
    · Reply

    Well, I am not able to reach the benefits of this argument about how we should promote ease of use by exposing less features to users in the editor.

    In the same paragraph, I read two contrasting sentences:
    “For example, most users should have no need to adjust the line-height for their text.”
    (…)
    “At a certain point, it is better to learn CSS.”

    How can the proposal of learning a code language, even if its basics, through CSS, be better as an solution for the casual users, rather than allowing them to simply choose a value in a checkbox?! By redirecting their actions to a specific field, requiring them to translate their thoughts into code, instead, at this age of even quantum technology, this argument is just an arbitrary decision for how to deal with their wishes. It is really not the only way for us to better serve the community.
    Decades in programming have already taught developers how to organize complex code, and UX designers study decades to serve us very well to simplify these scenarios – where our arbitrary opinions clashes, there are methods out there with solutions for both of us.

    Page builders come to my mind: most choose to not be complex, still have found a way to structure options. The most used page builder, at the time of this writing, Elementor, for example: its public are mostly casual users, because of its ease of use, compared to other page builders. And all of the CSS options are there through countless options. Yet its interface is simpler than ours in Gutenberg.

    There is a reason to why Microsoft word, these plugins and such have become famous. And all of them are way more filled with options than the most bold idea for Gutenberg.

    What you envision is a better solution for some of us, for sure. Those that are able -and prefer- to achieve their content and design goals faster and freely from CSS code. But not casual users.

    Casual users are not users unable to deal with options. They are People, therefore they have diferent wishes, which one day Will require the option we may choose to hide, because we thought they wouldn’t ever need. CSS are the basic options (For us in code. Why not for them in design?). People are going to avoid what they do not need at the time. And what for them or for you is unnecessary, for another casual user is as necessary as a drug. These little options are what people rely for content creation.

    Gutenberg has a complex goal – many holes in the foundation is a rule or should be an exception?. What you propose is exceptions in the Foundation.

    Imagine if tax payers needed to learn code in order to answer urgent requests instead of on their mother lamguages? It could be better for those managing the requests? Okay, but better for everyone? No… out of scope.

    “We certainly cannot expose every possibility via an option.”
    It is true that we cannot expose every possibility via an option.
    But it is false that we …Certainly… need that.

    Report

    • Justin Tadlock
      · Reply

      Well, I am not able to reach the benefits of this argument about how we should promote ease of use by exposing less features to users in the editor.

      The article is asking where we draw the line in terms of the number of global styles options, not whether exposing fewer features promotes ease of use (although, that is a worthy topic to explore, which has been written about extensively based on user testing). There will be a line. You can count on it. Someone will decide what it is. It is best we begin exploring the topic before that decision is made. I imagine that line will see some adjustment over time, but it will be there, at least initially.

      In the same paragraph, I read two contrasting sentences:
      “For example, most users should have no need to adjust the line-height for their text.”
      (…)
      “At a certain point, it is better to learn CSS.”

      Those two sentences were meant to be complimentary, but we’re missing the context of the entire paragraph by picking them out. Nevertheless, once you get to a certain point with options that the majority of users do not use, the user experience degrades. Going back to “the line” I mentioned above. Someone will make a decision along the way that says, “Here are the options we’ll offer; the rest of the stuff will be left to custom CSS.” And, there is always that user who will need to do something more than what the editor provides, regardless of where the line is. When a user gets to that point, the only option left is CSS (or another editor, as the case may be).

      I used line-height as an example because I do not think that is a good v1.0 option. Provide some font family and font size choices. See how that works out. Test a solution that automatically calculates line-height (based on work I’ve done in the past, this has done well). Test a solution that provides the choice to the user. Get feedback. Determine the best course of action that mixes user choice with good design principles.

      How can the proposal of learning a code language, even if its basics, through CSS, be better as an solution for the casual users, rather than allowing them to simply choose a value in a checkbox?!…

      The article does not argue that users should learn to code CSS over selecting options. I would be happy to clarify anything I wrote. There seems to be a misunderstanding here that forms the basis for the remainder of your reply, so I’ll just leave things here. I’d be happy to discuss. I just think we’re on different wavelengths here.

      Report

  2. wzy
    · Reply

    Yep! So we are adding more buttons to Gutenberg, while more pressing matters such as the 8+ years outdated SimplePie library and its PHP errors wither in trac-limbo

    Report

  3. Benjamin Ehinger
    · Reply

    It seems every single time WordPress issues a major update I like about half of what they do and the other half makes my life harder. Of course, this is coming from someone that still uses the classic editor (old dogs, new tricks, lol).

    It just seems like they are always making changes just as I am really getting used to specific features. I don’t mind the minor adjustments here and there, but how many times does someone have to create a new plugin to help us revert back to the old way of doing something because they new way just isn’t as clean or as easy?

    Report

    • Justin Tadlock
      · Reply

      The biggest user-facing change is really going to be the full-site editing feature. I am certain there will be a long transition period where this will basically stay the same for many people. Before it becomes useful, it will need to have buy-in from theme authors. And, right now, it’s not anywhere near feature-complete enough for theme authors to really build on top of it. I’m not sure how this transitional period is going to work, but I’m guessing full-site editing is not going to be a reality for the majority of users for a while.

      Much of this is a guessing-game at this point though. We’ll see how it unfolds in the coming months.

      As for the rest of the features, they shouldn’t put much burden on user experience. They will mostly be a few extra optional features for those who want to explore them. The UI work that’s happening right now, at least in my opinion, is making things easier.

      Report

  4. Simon
    · Reply

    The fact is that Gutenberg is complicated for customers, and I say this as a developer. I like idea of Gutenberg and this is easy for me, but some clients cannot deal with Gutenberg at all, and studying Gutenberg takes a lot of time with their content managers. Gutenberg’s user interface improves with each update, but after each update, I also need to inform my clients what and where they are after the next update, because the customers simply do not understand what happened.

    Report

    • Justin Tadlock
      · Reply

      I haven’t done any client work in the past few months (aside from setting up friends and family). But, it’s been my experience that the block editor has made things much easier for novices.

      I think it mostly comes down to individual experiences. We need to continue sharing specific pain points with the development team to help them improve the software.

      I’ve been very critical of backward-incompatible code changes, which forces theme authors to either support only the latest version or write CSS for multiple versions. To me, that has hurt updates more than anything. If a theme author isn’t on top of this, it creates a poor user experience.

      Report

      • Jay
        · Reply

        None of our customers will use it. Only a couple people on our staff use it on a couple sites for landing pages. I personally don’t mind it, but I’m a developer and seldom post things. But the overall experience from our customers is that’s it’s confusing and all the options are hidden, they tend to prefer the old editor because they’re just adding text content and maybe a couple photos, they’re not trying to create magazine layouts. Content is king after all.

        Report

  5. Tom Greer
    · Reply

    I think we’ve lost sight of one of Gutenberg’s primary objectives. Per Matt M, “The overall goal is to simplify the first-time user experience of WordPress…” https://ma.tt/2018/11/a-gutenberg-faq/

    As a website designer who works with clients all day, every day, I can tell you that the Block Editor is already over-featured, confusing and frustrating for the average user. All they want is to be able to add content quickly and easily.

    Expanding the Block Editor to being a full-site editor is downright scary. We will need to restrict access to blocks based on user role — with authors and editors only able to use a subset of block types to prevent them from breaking the website.

    Perhaps it is more logical to restrict access to blocks based on post type. Pages are typically built by designers or power users who will need the full set of block types. Posts are created by less-expert authors and expected to conform to a standard template where they share the same look-and-feel. For these, there will be many blocks that should not be used. And for custom post types (for example, events, jobs, documents…), similar block-type restrictions would be desirable in the real world.

    I’m praying that that we don’t do what Mary from London is proposing. Adding an option for every CSS option (line-height in her example) will create an unwieldy user-interface, further complicating the post creation and editing process. That would transform the Block Editor into the likes of Elementor, Divi or any of the other mega-themes, which are beyond the skill set of the average user. Every option we add makes the block editor more complicated and potentially makes authors and editors less productive.

    Let’s not lose sight of the original objective to make the block editor simple to use.

    Report

  6. Gary Taylor
    · Reply

    Egad, I’ve just almost completed reformulating my theme to take advantage of block-related css calls and structures (which are consistent only in their inconsistency). Dequeued the block editor css and replaced it with just the calls I needed. And I’ll have to do it all again at the end of the year if the underlying template structure changes… so time to read up on full-site editing, I guess. Hurrah for the block library though, that’s a useful addition

    Report

  7. Tunde Sanusi (Tuham)
    · Reply

    As a Web Designer who most especially works on blogs for clients, majority of my client haven’t even brought themselves in an agreement to Gutenberg because it seems confusing to them..

    I hope the WP team doesn’t make it more confusing

    Report

  8. Maureen Tesoro
    · Reply

    I concur with comment above … “It seems every single time WordPress issues a major update I like about half of what they do and the other half makes my life harder.”

    Why make drastic changes when most are working off site and don’t have the benefit of in-office help?

    Report

  9. Jon Brown
    · Reply

    WP has long claimed “decisions not options” best served the 80%. I don’t always agree with that, but FSE isn’t a decision. FSE isn’t even giving needed options. It’s abdicating making any decisions and giving users a very abstract and very complex tool (very cool tool, but still crazy complicated for an end user). I’m not sure how, but menus in FSE are even worse than in the customizer.

    The users I work with are still 50/50 frustrated using Gutenberg. They do like it better than the Visual Editor, but not better than BB/E. Mostly because they can’t control the things they want to control, like font sizes at various break points, make columns, or make sense of the bazillion blocks available .

    What they really want is a true WYSIWIG content editing experience, not one with weird extra padding, or empty caption fields, nor where they can’t tell how something will look on mobile while editing on desktop, etc… that all still confuses the heck out of them daily.

    Finally, the above comment is really right, there are 1000 4+ year old tickets that ought to get more attention than FSE IMHO. I long ago gave up even bothering with trac when tickets I cared about, with patches, with testing, with clear and narrow scope, left unmerged for years.

    Maybe FSE won’t get merged for 4 years. That’s be OK with me. I get the vision, I think it could be useful to come users, but not as it’s currently built.

    On a positive note, I do agree that block based sidebars would make a nice stepping stone.

    Report

  10. Kevin
    · Reply

    Thank you for this article. I am looking forward to all the features coming in WordPress 5.5. I like the search and install blocks feature mainly, hopefully wordpress 5.5 will be released on time as the current situation is looking good around the world.

    Report

  11. Per Herngren
    · Reply

    I am really looking forward to an easy way to adjust the line-height! Exciting for me who are not used to coding!

    Report

Leave a Reply to Jon Brown Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: