13 ms·

I think it is a mistake to view Gutenberg as something designed to solve problems for users. > Adding complex content in a visual way is a real problem in pre-

I think it is a mistake to view Gutenberg as something designed to solve problems for users. > Adding complex content in a visual way is a real problem in pre-Gutenberg WordPress It's not an actual problem though, is it? That cottage industry already fulfills the needs of those the subset of users that need more than what the tinymce implementation WordPress offers out of the box. It's better to understand Gutenberg not as a problem solving project but as a reaction to two things that the project leader has trained his focus on. First, there's this premise that everything is moving to javascript and php is legacy, so WordPress should evolve to run on javascript while casting aside PHP somehow. Fail that and the project could go under is an anxiety that exists. Second, there's the itch for WordPress.com to compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences. This is where wp.com wants to compete and win new users choosing between other hosted providers. Mullenweg wants to have WP be an even bigger monopoly. These are two anxieties driving Gutenberg. Gutenberg channels energy toward accomplishing a conversion from a PHP-centric project to a Javascript one, while making a play for new users who are choosing between the hosted version of WP and other hosted solutions. On a technical level, Gutenberg doesn't really convincingly solve technical problems. It makes it easier for developers to tack on GUI driven content elements, which was possible before, but something that many developers didn't get right or didn't know how to do. It doesn't provide a better WYSIWYG experience. The editor screen and the front-end are going to look and feel very different. The biggest new obstacle to arriving at a better WYSIWYG is the fact that in Gutenberg the interface markup is a first class citizen, with the content merely existing deeply nested inside its components in editing mode. While editing, every paragraph, every image, every element is surrounded by endless amounts of divs and scaffolding. When designing a document's CSS you style according to the markup that is shown to users, now with Gutenberg you have to take into account the fact that while editing elements are nested deep inside a convoluted set of divs. So we're still storing messy blobs, but now we're going to split up those blobs and add more mess while in editing mode.

modernerd 8y ago
> It's not an actual problem though, is it? Sure it is. If the first thing thousands of users do after installing WordPress is to pay for a page builder plugin to be able to work with their content in the way they want, that's a problem — it's a sign that the existing editor does not meet their expectations for how a modern CMS/blog platform should let them work, which makes it a good candidate to be solved in the platform itself. And if completely new users struggle to format content without frustration (I have watched many people trip with the “Classic” editor in new user orientations on simple things like adding and positioning an image or video), that is also a problem, because it affects their first impressions and gets in the way of whatever their personal or business goals are. Gutenberg is aimed at solving both of those real problems; I think on the whole it does it well, and it's enlightening to see how positively some people react to it: https://twitter.com/antpb/status/1052996833264455680 https://twitter.com/antpb/status/1052996833264455680 > The editor screen and the front-end are going to look and feel very different. You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass. This is how the upcoming new default WordPress theme (Twenty Nineteen) already works: https://github.com/WordPress/twentynineteen https://github.com/WordPress/twentynineteen > So we're still storing messy blobs, but now we're going to split up those blobs and add more mess while in editing mode. The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls. There are some big and entirely valid criticisms around Gutenberg (accessibility support, general PR issues, release delays), but “not being designed to address a real user problem” isn't one of them. It will take a lot of time to address all issues and turn the community around to it, and this is just the start.
- pknight 8y ago
  I think you've missed the point a bit. I'm trying to make a distinction between what is driving Gutenberg and what it's trying to solve and why. Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. It's primarily vehicle for accomplishing other goals, i.e. improving .com's competitive offering and managing the transition to a JS centric code base. Those things are more important. Understanding the priorities in play explains in part why Gutenberg is causing friction better than saying it exists because it is trying to solve technical problems for users. That would lead you to think that the technical problems were thought about really hard and that is some primary goal. It's not. It's just WordPress trying to modernise an interface. > You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass. The reason I bring up the editor and WYSIWYG is that it shows the disconnect between some lauded goal of providing a more seamless experience and the thought that went into the technical solution. My feeling is that we ended up where we are not because we were trying to solve a problem in the best way, but because we were just trying to cram in a new JS way of doing things. It explains better how we arrive at the following mess. Let me show you it through the lens of styling a post: https://imgur.com/a/AThzNns https://imgur.com/a/AThzNns > The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls. Look at the gallery I posted and tell me honestly, are you really saying this is the only way to provide 'intuitive editing'? Of course that is not true, it's simply how Gutenberg decided to implement it. Of course, you can compose your CSS workflow to fit around how Gutenberg's editor functions and you'll get fairly good results if you do. But this is a workaround, it's made the UI a first class citizen at the expense of the rest. So theme developers have to think in terms of the UI, not just what the markup looks like on the front-end. And content creators are forced to think in terms of blocks. It's an UI that is altering how people interact with it, for its own sake.
  - lmm 8y ago
    > Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. What's the difference between "compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences" and "solve problems for users". If there is something that is making people choose WIX/Weebly/Squarespace, isn't that something precisely: a problem that those things solve and default wordpress (currently) doesn't?

modernerd 8y ago

> It's not an actual problem though, is it? Sure it is. If the first thing thousands of users do after installing WordPress is to pay for a page builder plugin to be able to work with their content in the way they want, that's a problem — it's a sign that the existing editor does not meet their expectations for how a modern CMS/blog platform should let them work, which makes it a good candidate to be solved in the platform itself. And if completely new users struggle to format content without frustration (I have watched many people trip with the “Classic” editor in new user orientations on simple things like adding and positioning an image or video), that is also a problem, because it affects their first impressions and gets in the way of whatever their personal or business goals are. Gutenberg is aimed at solving both of those real problems; I think on the whole it does it well, and it's enlightening to see how positively some people react to it: https://twitter.com/antpb/status/1052996833264455680 https://twitter.com/antpb/status/1052996833264455680 > The editor screen and the front-end are going to look and feel very different. You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass. This is how the upcoming new default WordPress theme (Twenty Nineteen) already works: https://github.com/WordPress/twentynineteen https://github.com/WordPress/twentynineteen > So we're still storing messy blobs, but now we're going to split up those blobs and add more mess while in editing mode. The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls. There are some big and entirely valid criticisms around Gutenberg (accessibility support, general PR issues, release delays), but “not being designed to address a real user problem” isn't one of them. It will take a lot of time to address all issues and turn the community around to it, and this is just the start.

pknight 8y ago
I think you've missed the point a bit. I'm trying to make a distinction between what is driving Gutenberg and what it's trying to solve and why. Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. It's primarily vehicle for accomplishing other goals, i.e. improving .com's competitive offering and managing the transition to a JS centric code base. Those things are more important. Understanding the priorities in play explains in part why Gutenberg is causing friction better than saying it exists because it is trying to solve technical problems for users. That would lead you to think that the technical problems were thought about really hard and that is some primary goal. It's not. It's just WordPress trying to modernise an interface. > You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass. The reason I bring up the editor and WYSIWYG is that it shows the disconnect between some lauded goal of providing a more seamless experience and the thought that went into the technical solution. My feeling is that we ended up where we are not because we were trying to solve a problem in the best way, but because we were just trying to cram in a new JS way of doing things. It explains better how we arrive at the following mess. Let me show you it through the lens of styling a post: https://imgur.com/a/AThzNns https://imgur.com/a/AThzNns > The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls. Look at the gallery I posted and tell me honestly, are you really saying this is the only way to provide 'intuitive editing'? Of course that is not true, it's simply how Gutenberg decided to implement it. Of course, you can compose your CSS workflow to fit around how Gutenberg's editor functions and you'll get fairly good results if you do. But this is a workaround, it's made the UI a first class citizen at the expense of the rest. So theme developers have to think in terms of the UI, not just what the markup looks like on the front-end. And content creators are forced to think in terms of blocks. It's an UI that is altering how people interact with it, for its own sake.
- lmm 8y ago
  > Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. What's the difference between "compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences" and "solve problems for users". If there is something that is making people choose WIX/Weebly/Squarespace, isn't that something precisely: a problem that those things solve and default wordpress (currently) doesn't?