16 Comments

  1. mark k.

    New low in how core developers avoid community feedback. Apparently now it is not enough to subscribe to make email updates, follow discussions on slack and follow development on github, but you also need to follow all developers on twitter and friend them on facebook.

    Report

    • Gary

      That’s not really a fair assessment, Mark. 😕

      Matías wrote a post about the vision for Gutenberg, his personal blog is a great venue to publish it. The post has been widely shared on Twitter, and now has a Tavern article written about it, less than 24 hours after publishing. Even if it wasn’t published through an official channel, it’s pretty hard to miss.

      Feedback is always welcome, I’m sure Matías will be reading the comments here, if there’s anything in particular you wanted to bring up.

      Report

      • mark k.

        Very well @Gary, but there was never any discussion about this stuff, there should be a community discussion before such things even start development. I for example to not see any competition to wordpress that anyone in the community which is not in the hosting businesses should care about. Obviously, just because I am not in that businesses (gained some black hair since I stopped doing that) do not mean that automatic, wp-engin, godaddy etc do not deserve to be heard, but there should be a discussion even if it is obvious automattic controls the cards. It might also be useful for automattic, because it is not secret that there are some smart people around here that do not work for it, and maybe they can contribute something smart.

        And from the more realistic aspect, in wordpress core, whoever writes the code control the feature. From that perspective there just can not be a “private” post by Matias about gutenberg.

        Related sidenote: Last core meeting we were promised a discussion about the comments in the post content issue. Almost a week later, and a guy starts wonder if there was a discussion but it was “private”.

        Unrelated sidenote: I hope no wordpress user read that post because basically it says “wordpress users are technological idiots that can not learn anything, therefor we should aim to their limited technical IQ level”. I do not remember when was the last time that I worked for someone that technology challenged, including the guy that basically does tourism blog site.

        Report

    • InRussetShadows

      Perfectly said. This is being done in such a way to generate the illusion of discussion and the appearance of visibility, while in reality the users/developers are being ignored in favor of hosting companies and insiders.

      If I was running a company, a post on my personal blog as the authoritative post determining the direction of the company would be strange to say the least.

      To think that shares on Twitter mean having discussions is hilarious. “Widely shared”? Really?

      This is a train wreck and the apologies for it are even worse than the original problem.

      Report

  2. Leo

    Kudos on this strategy:

    With the abstraction blocks provide, we can also build several tools that take advantage of the fact the full document is broken down into smaller units with semantic value

    Given the explosion of different devices with different screen sizes and ways to interact with them (be it a laptop, smartphone, smart TV, Apple Watch, the new Google’s in-ear headphones, or who-knows-what-else will come in the future), a CMS needs to have true separation of content from form. Otherwise, when a new device comes out and we need our content accessible there too, we may discover that it’s not suitable, and will have to spend looong time and money to reformat it accordingly. (Source: presentation Content in a Zombie Apocalypse, by Karen McGrane.)

    Having documents split into smaller units will help capture the content in a cleaner, presentation-independent way. It makes WordPress more resilient, readier for the whatever the future may bring along.

    Report

    • Greg Schoppe

      That makes great sense until you realize that their “blocks” are primarily stored as opinionated HTML wrapped in comments. There is no actual separation here.

      Report

  3. Tammie Lister

    Firstly, thanks for featuring this article Sarah. It’s great to get more insights into the project out there.

    Mark k, you raise a good point about making sure all articles like this are known about. That said, in this case it certainly has been widely spread. As with anything I am sure we can all get better at surfacing the content.

    It’s worth considering that sometimes a lot of getting feedback isn’t visible. You may not see people reply to forums, reviews, reading all feedback and taking time to reply to comments on blog posts. It’s being done though.

    Report

  4. Bradley Kirby

    Really well written article. It’s the best explanation to date of the vision and purpose of Gutenberg – should be part of official documentation IMO.

    It sure is an ambitious plan though and seemingly a long way from the current plugin. Doing all that they plan to do while maintaining backward compatibility and not inciting a riot from folks scared of such a big change isn’t a task I would want to take on. So if nothing else kudos to the team for its courage.

    Report

  5. Chuck

    There is one thing I do not understand. If the goal is to make this a front end editor, then why isn’t it a front end editor?

    It’s one thing to say we will have an editor that “looks like front end”, versus an editor that actually activates in-place, while a logged-in user is on the front end.

    Also, the goal of collaborative editing on a page while locking/unlocking elements on the page seems to be a pretty narrow use case. Is this really a gaping hole that users are begging for?

    Report

  6. Steven Gliebe

    The thing about building your business on WordPress is that you have to get it in your head that, while perhaps not technically speaking, WordPress is Matt Mullenweg’s project.

    So, knowing that, and seeing that thus far he has lead WordPress down a path that has profited tens of thousands of us over a long period, it becomes easier to accept his vision for Gutenberg.

    Bring it on.

    Report

  7. Rick Gregory

    The problem with the Gutenberg project is less the technical vision than several other things. In no particular order:

    1) The market and enduser vision, i.e. the main rationale. Having a clear vision here should have led to a list of features that need to be done in order to get a credible v 1.0 out the door.

    2) The lack of consideration given to things like metaboxes which made people feel like the team wasn’t thinking things through.

    3) The lack of a roadmap with any detail. “5.0” is not detail. We have little to no insight into what features are being planned, what the timeline is, what the minimum features for a 1.0 Gutenberg are, etc.

    4) The lack of a strategy for dealing with compatibility. How is this being testing with Divi, Avada, Woocommerce, etc? What about Pods, ACF? What if a site doesn’t have a current version of those? What about custom post types?

    5) The assertion that this WILL ship live in 5.0 and not have a controlled rollout with life as a beta/RC level plugin (where features are frozen). Given that we’re on 4.9 that feels like it’s very soon. Speaking of soon…

    6) The utter lack of any date transparency. It’s one thing to say “5.0 will ship when Gutenberg is ready” but a) who decides what ‘ready’ means (see above) and b) what if Gutenberg really isn’t ready for 12 more months? Will the release really be held that long or will it be shoved out the door? This is exacerbated by statements saying things like the JS framework decision “will likely delay Gutenberg at least a few weeks, and may push the release into next year” when it’s utterly ridiculous to talk about a Gutenberg release in the next 3-4 months.

    Sorry, core, but this project hasn’t been well managed from any of these standpoints and the fact that we STILL lack transparency on the roadmap from both a time and features perspective and that we’re getting semi-official statements scattered around the web vs in a central, official place does not inspire confidence.

    Report

  8. Mike Schinkel

    I found his vision compelling, and look forward in hopes it can be realized.

    However, he made one statement that I find very worrisome, as someone who has literally spent the past month on two different MySQL data merging and cleanup projects with over a GB of content each:

    Blocks are also able to save attributes in meta fields, if needed, granting continuity to existing features. Overall, the concept of the block is not about where it stores data, but how the user interacts with it.

    The worrisome part is that his statement implies that meta fields will be the proverbial “red headed stepchild” when compared to structured data in $post->post_content. And from that I am concerned that most WordPress authors will end up storing independent data in post_content rather than in meta fields because they won’t know any better.

    Why does this matter? It is effectively impossible for create reliably WHERE clauses in SQL on the structured data that will be found into post_content. And it is effectively impossible to reliably update MySQL data using SQL UPDATE statements into a structure post_content.

    The project I just worked on for one (1) month would have taken three (3) months if not more had much of that data been in post_content!

    The same is true when some boneheaded plugin developer decides to store PHP serialized data in meta fields. (Carbon Fields did that in version 1.0, but thankfully fixed it in 2.0. The project I worked on included in-part moving or version 1.0 to 2.0 )

    I really hope to see that all fields have an option for storing in post meta and that really good inline wizard explains to
    walks the user through selecting the proper storage method.

    Report

    • Cristian

      I shared the same concerns. We are currently building a web app using WordPress as a CMS with the help of ACF. We have 10 different custom post types and each CPT uses 15 custom fields on average. All the custom post types are linked to each other via bidirectional relationships.
      We don’t use the tinymce editor at all for any of the CPTs.
      We certainly hope that post meta data will not be stored in post_content. How would we query the post data using GraphQL or the REST API!?

      Report

  9. Juanma Aranda

    Honestly, I think publishing an article trying to wash the face of the Gutenberg project and not open the readers’ comments, is not to be too brave …

    It was a good attempt for Matías to try to convince us that it is “obligatory” to make a drastic change to move forward.

    I agree that the improvements are really necessary, but the complete improvements, not the mid-improvements, with schedules made to counter, trying to finish in record time a project that has been stored for years in a drawer.

    As much as Ventura says, the project does not favor the daily work of an average user at all, it slows down and delays a lot of publication as I have explained several times.

    It does not compensate the time investment that requires writing a simple post with Gutenberg with the result you get.

    I still think that the best option is to leave it as a plugin and that user who really wants to use it.

    When on the part of Automattic have to be constantly justifying why Gutenberg is wonderful, let’s think about the reason … surely over the coming year we will have a plugin (freemium) that will adapt perfectly to Gutenberg and there we will know the real reasons for this drastic change.

    Report

  10. Ken Grondell

    I understand the worry of the community. Change is scary and let’s be honest a lot of people have a legitimate dog in this fight. That said I am taking a wait and see approach. As it currently stands it’s obviously not ready for prime time. I do feel that in when it finally goes live it will open a bunch of great possibilities. Block level control with attaching meta to a block as opposed to a post sounds interesting to me. It might even be interesting to see custom blocks although it sounds like you will be able to write custom code to control block output. Exciting stuff.

    Worst case there will be a mass exodus to Drupal and wordpress and joomla will chill in the corner. I’m still pulling for you WP!

    Report

  11. Greg Schoppe

    Storing structured content in raw HTML with comments is not an acceptable path forward. It means that any time the HTML standard evolves, or a design change requires a change to HTML syntax, that has to be made in every post. Then, by allowing users to enter “html mode”
    and manually modify the structure, they are guaranteeing that updating all the posts programmatically will fail for some posts.

    When you throw away everything that is good about structured content, in the name of smooth continuity, what you are looking at is a Ship of Feceus.

    Report

Comments are closed.

%d bloggers like this: