Good start, still a long way to go

First, let me say that I’m glad a team is exploring new options. We’ve relied on ACF for over a year, so that we could create more complex layouts, and this feels like a step in the right direction. Allowing everyone to have blocks (funny, we call ours blocks too, but they’re ACF blocks) makes things somewhat easier. But, it really seems like there’s no way to make it as backward-compatible as WP has historically been. It almost seems as though in WP options, the admin role should be able to determine whether Gutenberg or the Legacy Editor will be the one in use. And I would go so far as to say we need a way to specify an editor type, per post type. When you register a CPT, having another argument for editor would be very helpful – we only use these fancy block layouts on a couple of post types, most others just use a basic theme template and no ACF.

First question, how will things like columns work? Will Bootstrap or Foundation or something similar be baked into WP Core? If so, how will that interact with themes? Coupled with ACF, we use Foundation to make rows and columns easier, and use shortcodes for them when they’re not fully templated. I have a hard time envisioning where WP Core CSS (and even JS) would need to end, and a theme’s specific CSS and JS would begin. It’s just a paradigm shift that’s not necessarily bad, just hard to grasp at this point.

Like many others we also rely on a lot of postmeta. Yoast SEO is a big one for sure – I was excited to see Yoast dedicated an accessibility-minded dev to the Gutenberg project and hope that things will be completely and utterly WCAG 2.0 AA accessible. I manage higher education websites and it’s already been an uphill struggle making sure every little thing is perfectly accessible. If Gutenberg is baked into Core, it needs to set a very high bar for everything being completely accessible out of the box.

First observations:
– I already miss the screen options view. On most of our sites we don’t allow comments or trackbacks anywhere. If that’s turned off sitewide, can the “Discussion” panel just not exist? We also don’t allow Tags on Posts and I was pleased to see that the “Categories & Tags” panel only listed our Categories, not any way to create Tags.

– The “Settings” toggle button wasn’t intuitive to me. I expected it to be the “screen options” checkboxes but instead found it toggles the sidebar. I would brainstorm a different label and icon.

– I would love to see a way for theme developers to turn off certain features. For example, changing an author is something we never need to do, and “stick to the front page” is also something we don’t ever use. If a theme dev had filters, per post type (we might change an author on a CPT but not a Post), that allowed them to hide all the clutter that their particular install didn’t need, that would be a big step toward decluttering and simplifying the UX.

– How does one save a draft? Creating a new Post, I only see a Publish button – not a way to save a draft if I’m not ready to publish yet.

– Along the same lines… how the heck do you set a permalink? We are notorious for having super-long Post titles, then manually shortening the permalink and the Yoast SEO title tag as well. I don’t see anyplace to adjust here.

– A “paragraph block” is odd to me. When I add a paragraph there’s a 90% chance there will be multiple paragraphs. Maybe it’s more psychological than a real thing, but adding a separate block feels like there will be extra divs added for no reason. I would just call it a text block which naturally in my mind could contain multiple paragraphs, as well as headings and lists.

– I’m confused about the gear icon that has the “Show inspector” tooltip. It doesn’t seem to do anything, and it seems like a magnifying glass might be a more fitting icon for inspection.

– Instead of adding more Dashicons, has anyone considered embedding Font Awesome or something similar? That would enable plugin and theme developers to extend the blocks with fitting icons and just require 1 CSS embed, rather than plugin and theme authors adding their own icons into the mix. Again maybe more a psychological cleanliness than actual worry, but I like my code lean both on the front end and on the back end. The less there is, the less there is that can break, and the faster things load on days when I don’t have a fast, reliable internet connection. ??

– Need better handling of empty blocks. I added a Vimeo block without actually inputting an URL, and once published, the front-end view shows simply “undefined.” Better to have a conditional check – if there’s valid content there, display it; else just skip that block.

– Will it eventually be possible to add a Menu block?

– How does one create a widget that will work in Gutenberg? Right now I have custom widgets from various plugins, and they do not appear in the available blocks, even though I can add them from Appearance > Widgets. Is there some form of sidebar I have to add to the Gutenberg layout before I can access non-Core widgets?

All in all a solid start, and I appreciate that the team is doing small iterations and soliciting feedback throughout the process – this will give Gutenberg the best chance of success, versus developing everything without outsiders, then having to scrap the whole thing.