New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blockers for launching "Try Gutenberg" callout in core #7147

Closed
danielbachhuber opened this Issue Jun 5, 2018 · 11 comments

Comments

Projects
None yet
6 participants
@danielbachhuber
Member

danielbachhuber commented Jun 5, 2018

Following up on my original assessment eight weeks ago, I did another review of the entire issue and PR backlog yesterday. There are still some, but not too many, issues I think we need to resolve before launching the "Try Gutenberg" callout in core.

Notably, this list is subject to interpretation and open to debate. My qualifier for "Try Gutenberg blocker" is that the issue causes some amount of data transformation that would be non-trivial to recover from at scale (particularly if revisions are disabled). There's no sense in users experiencing this pain if we're already aware of it.

To recap the issues:

Two other sets of issues that seem like they could impact a large number of users, but aren't necessarily blockers, are:

@ZebulanStanphill

This comment has been minimized.

Contributor

ZebulanStanphill commented Jun 5, 2018

Is the Columns block planned for WordPress 5.0? I think the Columns block is currently too limited to be useful, and it should be either improved to have responsive functionality and non-equal-width columns, replaced with something better, or removed before the "Try Gutenberg" callout goes out. See also:

Additionally, the Text Columns block is also still a thing even though it is even more useless than the current Columns block and made obsolete by it. See #6506.

For optimal content conversion from the Classic Editor, I think #6520 needs to be merged before the callout, so that blockquotes with more complicated content will be preserved better.

#5941 and #5970 should also be resolved before the callout. There needs to be a decision made: is the Classic block supposed to exist purely as a legacy fallback? Or should its use be encouraged for those who want an editing experience with mixed content and various inline formatting options? I think the recommended way to have a lot of this stuff would be to use plugins that do things like add text color buttons to all the core blocks or add a "Freeform text" block that acts similar to the Classic block while being more adapted to Gutenberg design. Recommending use of the Classic block for anything other than legacy content seems like a bad idea to me.

The callout will likely increase the amount of plugins developed for Gutenberg, so the Gutenberg API should be mostly stable by then. I think #2751 needs to be resolved before a callout, as that is the last big API change (that I am aware of) that has not happened yet. See also: #6733.

@brianhogg

This comment has been minimized.

brianhogg commented Jun 5, 2018

Are we okay with the masses trying this out with all the accessibility issues remaining (ie. #179)? This affects a large number of users.

@danielbachhuber

This comment has been minimized.

Member

danielbachhuber commented Jun 5, 2018

Hi @SuperGeniusZeb / @brianhogg,

Thanks for the feedback. There's certainly a ton of work to be done before WordPress 5.0 ships. I think the issues you've mentioned are good candidates for 5.0. For "Try Gutenberg", I'd like us to focus on blockers exclusively first, where "blocker" is defined as "causes some amount of data transformation that would be non-trivial to recover from at scale". Time-permitting, we can also work to address high priority issues that aren't necessarily blockers.

@GlennMartin1

This comment has been minimized.

GlennMartin1 commented Jun 6, 2018

I agree with @supergeniuszeb - the Columns are a necessary thing to get perfected. I don't think that can be overstated.

The folks that get introduced to Gutenberg because of the callout are not the adventuresome folks like many who are following the beta project now. Hence, I suggest a fairly polished version prior to introducing it to novices.

Of the 680 open issues in Git, over 200 are tagged as "[Type]Bug". Perhaps those should be focused on at some point prior to the callout. No one wants tons of duplicate issues being raised.

Most importantly, first-impressions are critical, and a poor first-impression could deter 1000s of folks from upgrading when WP 5.0 is released. Gutenberg has a great start, but please wait long enough for the callout to give the new audience a stellar first-impression.

@ZebulanStanphill

This comment has been minimized.

Contributor

ZebulanStanphill commented Jul 12, 2018

Since my previous comment, several Gutenberg releases have happened and a bunch of stuff has been resolved. In addition to what is mentioned in the main post, here is what I think still needs to be resolved:

  • The lack of non-equal width and responsive columns in the Columns block. (#6048)
  • Updating the Quote block to use nested blocks for optimum content conversion from the Classic Editor. (#6520)
  • Adding a Container block. This feels like such a basic thing, and it has a lot of potential uses, yet for some reason there is not even an initial implementation. (#4900)
  • Resolving the whole issue with how attributes should be defined on the server/client and other server/client-side issues that require API changes. The API should be almost entirely stable when the callout happens. (#2751)
  • Inspector controls should be easy to extend/modify/remove, and should have a whole lot more documentation. (#6023)
  • The Text Columns block should be removed. (#6506)

Elaborating on that last one, I think it would be a good idea to remove it before the callout for the following reasons:

  • It does nothing that cannot be accomplished by the Columns block better
  • Its name may imply to some that it wraps text into columns like a newspaper, which is actually something you can do with CSS, but is not at all what the block does. This could cause unneeded confusion.
  • It existing alongside the Columns block may also cause confusion.
@lkraav

This comment has been minimized.

lkraav commented Jul 12, 2018

Elaborating on that last one, I think it would be a good idea to remove it before the callout for the following reasons:

On top of that, merging "Container" block idea into "Columns, where single-column === container" might be a good optimization, too.

@ZebulanStanphill

This comment has been minimized.

Contributor

ZebulanStanphill commented Jul 12, 2018

@lkraav Just to be clear, right now each column in a Columns block is actually a separate block: a Column block.

Given that a Column is usually expected to have different settings from a Container (like its width compared to other Column blocks in the same Columns block), I am not sure that is a good idea. Column blocks do not have any settings right now, though, so this depends somewhat on how the Columns block develops.

Some questions that should be answered first:

  • Will column-specific settings be put on each individual Column block? They might be put there and exposed through the inspector for each Column, or they could be exposed through the settings being moved up to the parent Columns block.
  • Does it make sense for a Column to control its own relative width, or is that something the parent Columns block should manage?

Maybe you are right. Having Container blocks nested directly in Columns blocks would certainly be a a good optimization in having fewer <div>s (and blocks) being used for content structure. But I would wait and see how the Columns block develops before merging the Column block into the Container block. Starting with two separate blocks and then possibly merging later seems like the right approach to me. I think converting existing Column blocks into Container blocks would be much easier to do in code than converting only Container blocks which are directly nested in Columns blocks into Column blocks if it is discovered that the two concepts should be separate.

On a related note, I have been looking into Oxygen lately, and I am really impressed by its flexbox-based layout system. I think perhaps a flexbox-based layout block could be a good addition to Gutenberg in the future. It could act as a nice alternative to the Columns block, or maybe even a full replacement depending on how powerful it becomes.

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

@ZebulanStanphill

This comment has been minimized.

Contributor

ZebulanStanphill commented Jul 15, 2018

I think #6102 is something that may be desirable to get fixed before the callout, simply because it may be a common source of frustration and duplicate issues. I know I certainly do not like my <abbr> and <code> tags being stripped out upon conversion even though the Paragraph block supports those tags.

@danielbachhuber

This comment has been minimized.

Member

danielbachhuber commented Jul 27, 2018

My qualifier for "Try Gutenberg blocker" is that the issue causes some amount of data transformation that would be non-trivial to recover from at scale (particularly if revisions are disabled).

I'm pretty happy with where things are at now... 🚢 🚢 🚢

@ZebulanStanphill

This comment has been minimized.

Contributor

ZebulanStanphill commented Jul 27, 2018

@danielbachhuber Are you sure about that? There are still some issues with conversions from the Classic block. See the latest comment in #6102.

@danielbachhuber

This comment has been minimized.

Member

danielbachhuber commented Jul 27, 2018

Are you sure about that?

Yes.

There are still some issues with conversions from the Classic block.

I agree this is important to address in some way, but I don't think it needs to or can happen in the next few days. I'll comment on that issue directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment