UX issues and bugs when trying to move to Gutenberg

[ElectricFeet]

tl;dr: The following is a list of a usability issues and inconsistencies in Gutenberg, analysing some of the confusion and frustrations that new users may have. It also documents page conversion errors (either from already-published HTML or from an old draft), where Gutenberg duplicates, modifies, and deletes(!) content. It needs attention in particular by Gutenberg UX specialists.

Notes:

• I'm a new Gutenberg user, giving it a test drive over the last few days, specifically trying to convert an old site to use Gutenberg blocks instead of Bootstrap.

• I don't know the names of the various "bits" of screen real estate, so have made up descriptors (but I've used them pretty consistently; I'm happy to run some find/replaces and re-post if this will help).

• This is in chronological order / organised by screen estate and describes the problems and confusion I had. It's not in order of importance.

• I have some (1980s & 1990s) professional experience of UX, so my thoughts are informed. But they may not be using the current lingo.

• Apologies that I've not written a github issue for each problem. This is a fairly thorough review of the whole interface, with interlinked problems/solutions and should probably be mulled over in full by usability specialists before being broken into component parts.

• I make lots of suggestions to move stuff around in the menus / screen areas. At first this may seem very disruptive. As you get towards the end of the section on user interface, you'll see it all come together again in a much more (I believe) logical/intuitive way. So suspend judgement until you see the the mock-up of how the menus / screen-areas would work together with all the suggestions in place.

• The conversion problems are more mechanical and simply need to be fixed.

• I'm very supportive of the Gutenberg project. Simplicity and ease of use will be key to ensuring WordPress's future and it's falling behind in that area right now. The following is intended to improve Gutenberg, not criticise it. Please don't consider this negative: it's quite the opposite.

User interface / editing problems

When I open my page/post with Gutenberg activated, it shows one block (apart from the title), pretty much as I might expect. It doesn't, of course, know what all the Bootstrap stuff means (but the Bootstrap markup is only <div>s with classes, so it shouldn't matter anyway).

Problem 1

I have no idea that I must hover over the (in my case single) block in order to do something with it; it's not easily discoverable. And for some users — even when hovering — knowing to click on the three dots may not be intuitive.

Suggestion: If there is only one block (so the user may be in a pre-conversion state), then show the three dots without having to hover. Alternatively, maybe better, there could be a big button / popup on a one-block page (shown only once), asking users if they wish to convert the single block to multiple blocks in the new editor. (Maybe I didn't get this because I pasted the content of another page into a new page?)

Problem 2

Next, when I hover over the main block, the "block-hover-three-dots" appear (my best attempt to describe this "thing" when hovering).

However, there are also three dots on the top-right part of the screen (what I will call the "top-right menu/area").

The block-hover-three-dots tooltip says "Open settings menu" whereas the three dots in the top-right menu/area have a tooltip that says "More" (as is the prevalent use of three dots on the web these days).So I'm confused. Do they do the same thing? The block-hover-three-dots cause cognitive conflict with the three dots in the top-right menu/area.

Suggestion: You could change the top-right menu/area to have 3 horizontal dots instead. However, my suggestions below allow you to eliminate it altogether (it's a by-product of other suggestions).

Problem 3

While the tooltip on the block-hover-three-dots says "Open settings menu", clicking on it does not open a settings menu. It gives a menu, one of whose items is "Settings". This is confusing — the tooltip is not descriptive of what it does.

Suggestion: It should probably say something more like "Block options", which is what it is.

Problem 4

When the "Settings" menu-item in the block-hover-three-dots menu is clicked, it opens the settings on the top-right menu/area, opened at the "Block" tab.

This menu-item should not say "Settings", because this is not entirely what happens when you click it.

Suggestion: Change the the block-hover-three-dots menu "settings" item to say "Open block settings". This will also remove the conflict of having two things on the screen that are described simply as "settings" (the menu-item in the block-hover-three-dots menu and the cog icon in the top-right menu/area). "Settings" will now only refer to one thing: the top-right menu/area settings (the "cog" pane).

Problem 5

The "Edit as HTML" item in the block-hover-three-dots menu and the "Visual editor"/"Code Editor" menu-items in the top-right menu/area seem to be in conflict/duplicates. However, one applies only to the block, while the other choice applies to the whole document.

Suggestion: "Edit as HTML" should say "Edit block as HTML".

Problem 6

When it is toggled, the menu-item says "Edit visually".

Suggestion: This should say "Edit block visually".

Problem 7

"Delete" is ambiguous.

Suggestion: It should say "Delete block".

Problem 8

The text/icon next to "Edit as HTML" (which problem 5 suggests should now be "Edit block as HTML") shows < > above HTML. This same text/icon is used when the menu item has been toggled.

Suggestion: When the menu item has been toggled to show "Edit block visually", the icon should probably be some sort of layout icon (e.g. something similar to dashicons f135).

Problem 9

To insert a block — specifically to activate the plus-sign icon between blocks — I have to hover between the blocks. (Or spot the icon on the top-right toolbar, which is not where my focus is — see next problem below.) This is not easily discoverable/intuitive.

Suggestion: The plus-sign icon with insert block functionality should be on the block options menu (available by clicking the block-hover-three-dots).

Problem 10

The plus-sign icon to insert blocks on the top-left-toolbar — next to undo, redo, and information — is not relevant there. Undo, redo, and page/post information are high-level editor items whereas block-level functions should stay with the blocks.

Suggestion: Eliminate the icon/link from that toolbar; it should be in the block options menu, as per previous suggestion. This will have the additional benefit of inserting the block where you really want it, rather than inserting arbitrarily above the block where the cursor currently is.

Problem 11

The insert-block plus-sign icon is shown at the bottom of the editing area. This is fine — and useful at the end when I'm writing new content. But when I hover, I see that there are also two icons to insert text and images. Should they be shown at all? Clicking the plus-sign icon gives so many more possibilities, whereas these two icons may lead me to believe there are only two possibilities.

Suggestion: If they are shown, they should be shown always and they should have tootlips etc.

Problem 12

Looking further at the top-right menu/area:

The "eye" icon is totally non-intuitive in this context. This icon is used most often on the web / in apps these days to mean "show", specifically when typing passwords (indeed, WordPress itself uses it in this sense, when the user changes a password in their profile). This icon is also used to mean "view". I haven't seen it used to mean "Preview". "View" is very different in a WordPress context to "Preview".

Icons are nice, but not where they cause confusion and reduce discoverability.

Suggestion: The eye icon should be replaced with a link that says "Preview" OR, if an icon is absolutely preferred despite its ambiguity, consider an eye superimposed on a page/post icon such as dashicons f498. Personally, I would prefer the "Preview" text link, as there will always be confusion over view/preview with an icon.

Problem 13

The "Document" tab is called "Document", which is not what we are editing in WordPress. It may be a page, a post, or a product etc.

Suggestion: Use "Page" or "Post" (or "Product" etc.), according to what's being edited.

Problem 14

The "x" to close the settings is misaligned.

Suggestion: Correct alignment.

Problem 15

The update button — with a dropdown — and the "Status and Visibility" section have been redesigned. And both are an improvement in terms of usability. However, they duplicate function and this is confusing. While the update button with a dropdown is cute and a lot of thought has clearly gone into it, I think it is too complex to all be done inside a button. Especially in a button that changes title as well. The ambiguity caused in the case of reverting to draft and the change of the button from "Publish" to "Update" are confusing. I genuinely couldn't understand what status my post was in. More of this confusion is apparent in the next three problems (16, 17, 18).

Suggestion: Expand the "Status and visibility" menu-item to deal with all the toggleable items (in particular: reverting to draft) and remove this from the dropdown button. (I realise that this will be painful for those who developed the cute button).

Problem 16

Gutenberg is too eager to save, when I haven't asked for this to happen. If my post/page is in an unpublishable state, this is not acceptable and will mean that I have to delve into the revisions and revert to a previous revision — time wasted and a major frustration. Especially at the beginning of Gutenberg roll-out, people will be experimenting to see what the buttons do. There will be major blow-back and lack of acceptance if Gutenberg makes unexpected changes to people's current pages/posts. Situations I've found so far where a save is triggered despite me not asking for it are:

• When switching to draft, a save is automatic despite me not necessarily wanting this.
• When adding a password to a page/post, a save is triggered after a couple of seconds.
• When switching from password-protected to public, a save is triggered after a few seconds.
• When changing the publish date, a save is triggered after a few seconds.
• Additionally, when switching to "Private", from Public or password-protected Gutenberg offers me a pop-up with "Would you like to privately publish this post now?", with no option to publish later

It should be noted that changing the status, visibility and publish date are things that the user often does in the middle of editing a post (and not necessarily at the end) so the post may not yet be ready to be saved. And yet Gutenberg is saving them. And perhaps even making them live without the user realising.

I understand the desire to reduce clicks and major progress has been made on this front. However, the number of clicks should always include one for "Save draft"/"Publish"/"Update" before the post is saved.

As an example: the old process to change to draft requires (a) click on Edit (next to status); (b) select draft; (c) click OK; (d) click the "Update" button to save the post. Far too many; I agree. The new process improves on this significantly, by reducing the number of steps right down to 1, but in doing so it goes way too far and may cause damage.

Suggestion: All the status/visibility options should be toggleable, with one (changing) "Save draft"/"Publish"/"Update" button to make them effective. It's not okay to save my post/page without my explicit say-so, (with the exception of an autosave).

Problem 17

In the document tab, the first menu item is called "Status and Visibility", yet the traditional WordPress "status" is not shown. In particular, I have no way to see that my post/page is in draft, apart from noticing that it says "Publish", rather than "Update". This is not clear enough.

Suggestion: The status should be shown, using the same interface as "Visibility" does — a drop-down with radio buttons for "Draft" and "Published". When the "Draft" radio button is clicked, the "Pending review" toggle should appear, as now.

Problem 18

Once in draft, there seems to be no way to make more changes and save them except by publishing. When I select draft mode, a "save draft" link appears to the left of the Preview icon for a few moments, but this then disappears as the post is saved automatically(!). This leads to dysfunctional situations where:

• A user may make some changes; switch to draft; toggle "Pending review"; then click "publish" to "save" these changes and inadvertently publicly publish the changes that are pending review. Again, this must not happen without user consent.
• A user switches to draft and then makes more changes afterwards. The changes cannot be saved without publishing.

If the recommendations in Problems 15, 16 and 17 are adopted, this problem should go away automatically, because:

• Saving won't be automatic
• Draft status will be toggleable without saving
• The "Save draft"/"Publish"/"Update" button will now be a normal button, not a dropdown button

Suggestion: Adopt solutions to 15, 16 and 17 and then change the single "saving" button to say "Save draft" for a draft post/page; "Publish" for a new post/page; and "Update" for a modified post/page.

Problem 19

"Status and Visibility" also contains other page/post properties, such as the date and draft review status. So the title "Status and Visibility" doesn't describe the contents.

Suggestion: Change this to "Page properties" (or "Post properties"/"Product properties" etc., depending on what you're editing).

Problem 20

The calendar dropdown is intuitive and functional. I note that the time input boxes are picking up user options for time. However, the time display isn't. For example, despite the 24hr clock (H:i) being set in the my Time Format (in Admin > Settings > General), the displayed date says (e.g.) "Publish: December 29, 2017 7:14 pm", which is wrong (whereas the first time input box says 19, which is correct).

Suggestion: The publish date and time displayed should be in the user's preferred format, as set in Settings > General.

Problem 21

If I change the time of publication, I have no way of getting back to "now". This is of particular relevance when you've saved a draft post a long time ago and navigating to today is a pain.

Suggestion: Provide a reset or "Now" button in the calendar.

Problem 22

The "Categories & Tags" section contains nothing for a new page that has no categories or tags. I presume that this functionality has yet to be written. If not, it needs adding, to allow the user to choose new categories or tags.

Problem 23

The "Page attributes" section gives space in which "order" could be described a little better, or at least a link provided.

Suggestion: Take this opportunity to describe what "order" means. The order in which pages are displayed where? It's never been very clear to the average user what this means, but Gutenberg could be an opportunity to explain this.

Problem 24

Where are "Parents" and default template? Maybe the latter is obviated in Gutenberg(?), but won't Parent still be needed?

Suggestion: Clarification or addition to pane needed.

Problem 25

At one point, in the Block tab in the settings pane, I saw the text "The classic editor, in block form.". It's not clear what this means.

Suggestion: Clarify or remove.

Problem 26

With the screen width around 540, I can to see either the editor or settings, toggleable with the settings (cog) icon. Fine.

If I further reduce to around 380, pressing the cog icon throws me into settings, with no way to get back to the editor. The "Extended settings" menu-item (which is normally at the bottom of the menu-items) is thrown up to the top and covers the admin bar and the settings cog-icon. (Firefox 57.0.3; MacOS 10.13.2)

Suggestion: Make sure that the "Extended settings" menu-item stays at the bottom.

Problem 27

The "Extended settings" menu text is not consistent with other menu texts above (font-weight CSS) and the arrow to open the sub-menu is not aligned with the others.

Suggestion: They need to be bold/aligned with the others above.

Problem 28

It's become clear by now that:

• The top left of the screen — with Undo, redo, and content information (with "Insert block" taken out; see problem 10) — is an area for high-level editor functions. Things that help you edit your post / page / product etc.
• The top right is for actions on the post/page/product that you're editing: preview, publish, or change its settings.
• The block menu is for things related to a specific block and to insert/delete blocks.
• The settings menu is for the nitty-gritty details of the post / page / product etc. and block.

The three-dots icon in the top-right menu/area are currently a bit of a "where do we put these?" add-on. In there we have (a) a "fix toolbar to block" item and (b) a choice of editor (which is a binary choice) — "Visual Editor" or "Code editor". Where should they more naturally be?

(a) The "fix toolbar to block item" is firmly related to block options, and is not a high-level action on the post / page / product etc.

Suggestion: This toggle should be on the block-hover-three-dots menu (e.g with a "pin" icon) and not on the top-right menu/area.

(b) The visual/code editor choice needs to be given a proper home. It too is not at home in the place where we have high-level actions on the post / page / product etc. Its real home should be with the editor functions in the top left. A binary choice should not normally be represented by a drop-down menu. Typically, it should be represented by a text/icon button that toggles a state-change (or, in the right context, a menu-item toggle, or even a radio button). Given the current design paradigms in use on the page, logic would dictate that it should be a toggle icon in the top left toolbar.

Suggestion: Change to an icon button with a code icon (< >) which could be shown as depressed or not. The tooltip should make it clear that it will affect the whole post/page/product — something like "Edit page visually" or "Edit page as HTML". This will ensure that it is distinguished from editing single blocks in HTML/Visual mode. The current icon/text used on the "Edit block as HTML" would also work, though it might benefit from being placed on top of a page icon, to indicate visually that it is for the whole page.

Note: If you implement the suggestions in (a) and (b) then you wouldn't need the three vertical dots icon in the top-right menu/area at all, which would resolve the confusion explained in Problem 2.

Taking all these suggestions together the 3 screen areas would look like this:

Problems converting a Bootstrap page

I have a lot of pages/posts that have a three-column grid layout using Bootstrap. For example: image with caption / image with caption / text. The markup in my pages/posts is only <div>s with classes. Everything is standard HTML, or standard WordPress media caption shortcodes. Something like this:

<div class="row">

<div class="col-xs-12 col-md-6 col-lg-4">
[caption id="attachment_915" align="aligncenter" width="400"]<a href="/another-page/"><img src="https://dummyimage.com/400x400/333333/09f09f.jpg&text=image+1" alt="“My alt” alt 1" width="400" height="400" /></a> “My caption” caption 1[/caption]
</div>

<div class="col-xs-12 col-md-6 col-lg-4">
[caption id="attachment_936" align="aligncenter" width="400"]<a href="/another-page/"><img src="https://dummyimage.com/400x400/000000/ffffff.jpg&text=image+2" alt="“My alt” alt 2" width="400" height="400" /></a> “My caption” caption 2[/caption]
</div>

<div class="col-xs-12 col-md-12 col-lg-4">
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p> 
<p style="text-align: right;"><a title="More" href="/another-page/">...More</a></p>
</div>

</div>

Which has this front-end result:

Problem 29

If I open the page and immediately save it (by switching to draft for example), simply having opened and saved it corrupts the links. See those &s in the image URLs? With with Gutenberg active, opening a page converts &s in hrefs to &s. So the link https://dummyimage.com/400x400/333333/09f09f.jpg&text=image+1 is changed to https://dummyimage.com/400x400/333333/09f09f.jpg&text=image+1

Suggestion: (a) The content should not be changed if the user has made no edits and (b) should hyperlinks ever be changed?

Problem 30

When I save the page, Gutenberg tells me "Post published! View post".

Suggestion: In the case of pages, it should be "page" in both instances (and products should be "product" etc.).

Problem 31

I reload another version of the page to do more experiments. This is my page before conversion:

I click the block-hover-three-dots menu and select "Convert to blocks". It's not pretty:

After conversion, a new first paragraph has been "invented" from the caption shortcode: `[caption id="attachment_915" align="aligncenter" width="400"]`.

Suggestion: This shouldn't happen.

Problem 32

The first image's caption is shown (without caption styling), but with the [/caption] tag at the end.

Suggestion: This shouldn't happen (this bug seems to be a duplicate of #4215).

Problem 33

The first image is shown a second time, after the second image (this time with its correct caption).

Suggestion: This shouldn't happen.

Problem 34

Text has been deleted(!) at the beginning of the first paragraph of the text column. Interestingly, the text deleted depends on the length/content of the alts in the images — if you change the alts, a different amount of text gets deleted.

Suggestion: Deletion of text shouldn't happen.

Problem 35

After saving, if I click the revisions button and select the previous version. This throws me back into the classic editor, with no way to get back to Gutenberg. I have to go back to the pages list and re-enter the editor to get back into Gutenberg.

Suggestion: This shouldn't happen. The user should be thrown back into Gutenberg.

Switching Gutenberg off, I can see that the HTML has been converted as follows:

<!-- wp:core/paragraph -->
<p>

    [caption id=&quot;attachment_915&quot; align=&quot;aligncenter&quot; width=&quot;400&quot;]</p>
<!-- /wp:core/paragraph -->

<!-- wp:core/image -->
<figure class="wp-block-image"><img src="https://dummyimage.com/400x400/333333/09f09f.jpg&amp;text=image+1" alt="“My alt” alt 1" /></figure>
<!-- /wp:core/image -->

<!-- wp:core/paragraph -->
<p> “My caption” caption 1[/caption]


</p>
<!-- /wp:core/paragraph -->

<!-- wp:core/image {"id":936,"align":"center"} -->
<figure class="wp-block-image aligncenter"><a href="/another-page/"><img src="https://dummyimage.com/400x400/000000/ffffff.jpg&amp;text=image+2" alt="“My alt” alt 2"/></a>
    <figcaption> “My caption” caption 2</figcaption>
</figure>
<!-- /wp:core/image -->

<!-- wp:core/image {"id":915,"align":"center"} -->
<figure class="wp-block-image aligncenter"><a href="/another-page/"><img src="https://dummyimage.com/400x400/333333/09f09f.jpg&amp;text=image+1" alt="“My alt” alt 1"/></a>
    <figcaption> “My caption” caption 1</figcaption>
</figure>
<!-- /wp:core/image -->

<!-- wp:core/paragraph -->
<p>etur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
<!-- /wp:core/paragraph -->

<!-- wp:core/paragraph -->
<p><a href="/another-page/">...More</a></p>
<!-- /wp:core/paragraph -->

Problem 36

This is all clearly not as it should be. While writing a new page may be easier than with the old editor (and I'm looking forward to using the column layouts, once my posts/pages can be reliably converted), there is currently no way for me to complete the conversion without starting from scratch. Fine for a new site, but not for an old one. The experience must be improved. The above shows that damage is done on trivial HTML (divs and standard WordPress shortcodes). The main problems are that images/captions/text are duplicated, modified, and deleted.

Suggestion: The conversion needs a lot of work.

Problem 37

The second image and the repeat of the first image have been given the size of thumbnail, whereas the first hasn't. I'm not sure where this has come from , as 4000x400 is not my theme's thumbnail size.

Suggestion: If the image size is to be set on conversion, then it should (a) be set for all images and (b) set according to the theme's image size settings where possible, or WordPress defaults (e.g. where the theme's image sizes do not correspond to the size in the HTML).

Problems converting a draft (standard HTML)

Problem 38

I have an old draft that was written in HTML (h2s, dd/dts etc; nothing special). When I open it in Gutenberg, I get the message

! This block appears to have been modified externally. Overwrite the external changes or Convert to Classic Text or Custom HTML to keep your changes.

I then get a choice to ""Overwrite" / "Convert to classic text" / "Edit as HTML block".

• The message is alarming when it needn't be. The language may even frighten the average user into imagining that the site has been hacked ("modified externally").
• It is not factually correct — the post was edited with WordPress, not "modified externally".
• The options are not understandable. "Overwrite" with what? What is "Classic" text? (Whereas "Edit as an HTML block" most people will understand.)

I was happily surprised to see that the mildly alarming "Overwrite" option simply showed the old HTML in WYSIWYG. So it means "convert for the new editor". Oddly, "convert to classic text" seemed to do the same thing. I assume that first two options are the same. (N.B. It's not easy to find out the difference, because there's no way to save a draft without publishing; see problem 18.)

Suggestion: Make the message less alarming, such as "This draft was probably written before the new WordPress Gutenberg editor was introduced. It needs converting. Convert? Or Edit as an HTML block?"

Problem 39

After I have converted the text, Gutenberg allows me to navigate away from the page without being warned that I will lose my changes. This is because it has actually saved the overwritten text without my permission. This shouldn't happen.

Suggestion: Do not save the overwritten post/page, but allow the user to choose to do this. If the user doesn't save, then add the standard leave page / stay on page message when they try to navigate away from a converted page.

Problem 40

When I choose to convert the draft with "Edit as HTML block", it gives me "HTML" and "Preview" tabs at the top (it looked like an editor inside another editor). This is inconsistent with the way regular editing of HTML blocks works. Additionally, it wasn't clear how to switch this off and make it into a "normal" HTML block, which is toggleable from the block-hover-three-dots menu. It takes me into a no-man's-land where there seems to be no return.

Suggestion: Make this "draft conversion" block HTML editor a "normal" single block in HTML-editing mode, which is then toggleable in the block-hover-three-dots menu.

Summary

Phew! That turned out to be a lot more work than I was expecting. I hope I've given enough information for all these bugs / usability issues to be resolved. Happy to clarify/test further if needed.

[ghost]

Hi @ElectricFeet ( good to read you again :) ) this is an impressive and useful analysis. Almost a detailed conception !
I have bookmarked it.
I think that it will need to be sliced into smaller issues ( like #4240 ) to be implemented / discussed.

[karmatosed]

Firstly thanks @ElectricFeet for the in-depth post. I am going to respond here and also if needed make a few issues pulled out from it as that's probably better than leaving things in this one. In future if you could make issues for each that would be great as we totally can deal with things easier that way.

I have no idea that I must hover over the (in my case single) block in order to do something with it; it's not easily discoverable. And for some users — even when hovering — knowing to click on the three dots may not be intuitive.

We have an issue for a NUX solution that would help here. #3670.

Next, when I hover over the main block, the "block-hover-three-dots" appear (my best attempt to describe this "thing" when hovering).

These are ellipsis and in testing we're not getting reported issues. I think we need to do more testing though on this exact point. There are a few issues to increase things like hit space on these. I do not think changing the direction will help, but we can come back to this in testing.

While the tooltip on the block-hover-three-dots says "Open settings menu", clicking on it does not open a settings menu. It gives a menu, one of whose items is "Settings". This is confusing — the tooltip is not descriptive of what it does.

I think we can change what this says and have opened an issue #4239.

When the "Settings" menu-item in the block-hover-three-dots menu is clicked, it opens the settings on the top-right menu/area, opened at the "Block" tab.

I opened another issue to discuss that naming #4240

The "Edit as HTML" item in the block-hover-three-dots menu and the "Visual editor"/"Code Editor" menu-items in the top-right menu/area seem to be in conflict/duplicates. However, one applies only to the block, while the other choice applies to the whole document.

I don't personally think that's needed right now. We do need to look at language being used but the longer the tooltip, the more issue for non-English languages.

When it is toggled, the menu-item says "Edit visually".

Again my point above applies to this.

"Delete" is ambiguous.

I think 'delete' is ok as this is common place interface wise. We can note and consider though in testing.

The text/icon next to "Edit as HTML" (which problem 5 suggests should now be "Edit block as HTML") shows < > above HTML. This same text/icon is used when the menu item has been toggled.

I do think changing an icon on interaction could cause a lot more issues than it would solve.

The plus-sign icon with insert block functionality should be on the block options menu (available by clicking the block-hover-three-dots).

We have several places you can add blocks and I think we both need to do more testing and see what the NUX experience uncovers here. I don't think it's solved by adding yet another '+' to the menu which has different grouped interactions.

Eliminate the icon/link from that toolbar; it should be in the block options menu, as per previous suggestion. This will have the additional benefit of inserting the block where you really want it, rather than inserting arbitrarily above the block where the cursor currently is.

This is already planned in an issue.

The insert-block plus-sign icon is shown at the bottom of the editing area. This is fine — and useful at the end when I'm writing new content. But when I hover, I see that there are also two icons to insert text and images. Should they be shown at all? Clicking the plus-sign icon gives so many more possibilities, whereas these two icons may lead me to believe there are only two possibilities.

In testing these 'recently used' blocks were super useful for people. They change depending on what you are using commonly.

Suggestion: The eye icon should be replaced with a link that says "Preview" OR, if an icon is absolutely preferred despite its ambiguity, consider an eye superimposed on a page/post icon such as dashicons f498. Personally, I would prefer the "Preview" text link, as there will always be confusion over view/preview with an icon.

Again in testing this hasn't been found to be a mystery to users. That isn't saying it can't be changed but let's note to test.

Suggestion: Use "Page" or "Post" (or "Product" etc.), according to what's being edited.

Document does say what it does and for now unless testing shows (it's not yet) this is an issue, we can leave it as that name.

The "x" to close the settings is misaligned.

I am not seeing this misaligned in various browsers: Safari, Firefox and Chrome. If you still see this please open an issue.

Suggestion: Expand the "Status and visibility" menu-item to deal with all the toggleable items (in particular: reverting to draft) and remove this from the dropdown button. (I realise that this will be painful for those who developed the cute button).

I think for now testing the changes we have in the pipeline is good on this.

Gutenberg is too eager to save, when I haven't asked for this to happen. If my post/page is in an unpublishable state, this is not acceptable and will mean that I have to delve into the revisions and revert to a previous revision — time wasted and a major frustration.

There is an expectation by a lot of users for auto saving. I think right now changing this without more testing feedback would be bad. Let's consider as we do that. It's worth noting we are doing a lot of testing right now so can loop back to this.

The status should be shown, using the same interface as "Visibility" does — a drop-down with radio buttons for "Draft" and "Published". When the "Draft" radio button is clicked, the "Pending review" toggle should appear, as now.

I made an issue #4241

Once in draft, there seems to be no way to make more changes and save them except by publishing. When I select draft mode, a "save draft" link appears to the left of the Preview icon for a few moments, but this then disappears as the post is saved automatically(!). This leads to dysfunctional situations where:

Let's work on getting #4241 in and then see if there are still issues from that in testing beyond a single user.

Suggestion: Change this to "Page properties" (or "Post properties"/"Product properties" etc., depending on what you're editing).

Made another issue here #4242.

Suggestion: The publish date and time displayed should be in the user's preferred format, as set in Settings > General.

Made another issue #4243.

Suggestion: Provide a reset or "Now" button in the calendar.

As you can pick any date, I do not think there is no need to add yet another button to the interface.

The "Categories & Tags" section contains nothing for a new page that has no categories or tags. I presume that this functionality has yet to be written. If not, it needs adding, to allow the user to choose new categories or tags.

Pages in the existing editor do not by default have tags or categories.

Suggestion: Take this opportunity to describe what "order" means. The order in which pages are displayed where? It's never been very clear to the average user what this means, but Gutenberg could be an opportunity to explain this

This section is going to be reviewed when page templating is added, so let's loop back to this then.

Where are "Parents" and default template? Maybe the latter is obviated in Gutenberg(?), but won't Parent still be needed?

Same as above.

At one point, in the Block tab in the settings pane, I saw the text "The classic editor, in block form.". It's not clear what this means.

This has a ticket for discussion on naming.

Suggestion: Make sure that the "Extended settings" menu-item stays at the bottom.

Mobile has a number of issues to fix a lot of display problems. I suggest we fix those and then do more testing over doing yet more changes.

https://github.com/WordPress/gutenberg/labels/%5BComponent%5D%20Mobile

The "Extended settings" menu text is not consistent with other menu texts above (font-weight CSS) and the arrow to open the sub-menu is not aligned with the others.

Again not seeing this in browsers I am testing in. Can you if you still see this open a new issue for just this problem?

Suggestion: This toggle should be on the block-hover-three-dots menu (e.g with a "pin" icon) and not on the top-right menu/area.

I don't think a pin icon means anything to any user. Right now adding it to the block settings also confuses similar groupings. I'm not saying we don't have to iterate, but I do not feel what you are suggesting here is a better option.

The top toolbar Ellipsis has future plans for example in Extensibility. It's important for that to have a global option like this. See this long issue for some context: #3330.

I don't agree with your suggestions in this case, but we can test more and see if the WordCamp US tests give us any counter evidence.

Suggestion: (a) The content should not be changed if the user has made no edits and (b) should hyperlinks ever be changed?

This depends on if saving happens through auto save. It's about balance, user expect auto saving. If you still feel strongly on this please open a new issue just for this and we can work through.

Suggestion: In the case of pages, it should be "page" in both instances (and products should be "product" etc.).

The publishing flow has some changes being implemented and contextual messages is part of that, see #3496.

The first image is shown a second time, after the second image (this time with its correct caption).

I am not able to recreate this, if you can please open up an issue just for this, stating the browser you are using.

Text has been deleted(!) at the beginning of the first paragraph of the text column. Interestingly, the text deleted depends on the length/content of the alts in the images — if you change the alts, a different amount of text gets deleted.

Also not seeing this, so if you are please open an issue just for this.

After saving, if I click the revisions button and select the previous version. This throws me back into the classic editor, with no way to get back to Gutenberg. I have to go back to the pages list and re-enter the editor to get back into Gutenberg.

After saving, if I click the revisions button and select the previous version. This throws me back into the classic editor, with no way to get back to Gutenberg. I have to go back to the pages list and re-enter the editor to get back into Gutenberg.

It takes me back to Gutenberg if I use that editor for that revision. If you still get this please open an issue.

The second image and the repeat of the first image have been given the size of thumbnail, whereas the first hasn't. I'm not sure where this has come from , as 4000x400 is not my theme's thumbnail size.

I again don't get this in testing. Maybe see if you can work out if this is the browser even and make a new issue reporting just this?

I have an old draft that was written in HTML (h2s, dd/dts etc; nothing special). When I open it in Gutenberg, I get the message

This message should only appear if you have a block. If that's not the case please open a new issue just for this.

As I have gone through and made issues, let's close this big issue up now and focus on iterations in each issue. If any issues you think I've not caught that should be, please open a new issue for each one.