[wp-trac] [WordPress Trac] #52831: Workflow of Reusable Blocks for the future

WordPress Trac noreply at wordpress.org
Wed Mar 17 06:30:26 UTC 2021


#52831: Workflow of Reusable Blocks for the future
-------------------------+-----------------------------
 Reporter:  davelo       |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:  5.7
 Severity:  normal       |   Keywords:
  Focuses:  ui           |
-------------------------+-----------------------------
 Since the new auto-save feature in 5.7, the reusable blocks became very
 unpleasant to use.
 I have recorded the pain points in this screencast:
 https://share.woofers.be/mXu1eo8o


 First:
 It starts with the naming of a newly made reusable block; which is totally
 out of the viewport of the user. This can result in having tens of
 resuable blocks with the same name. The 'Gutenberg' rule has to be: when a
 notification is expected, show it in the viewport of the user, within
 500px to max. 600px. Certainly not in the right bar, which is to be proven
 as the grave-yard part of a page. Yes, that's a study of Nielsen group in
 the nineties.


 Second:
 it's now not obvious for the user when he/she starts editing a reusable
 block. This is also a general UI-concern of Gutenberg.  We assume that
 users know the blocks by hand and are aware that there is a toplevel. I
 can tell to be honest: very very few of my clients look at the breadcrumbs
 below (cause what i said: out of viewport) and hardly anyone uses the
 arrow keys in the dashboard.
 It must be more clear when editing a 'child' block. Maybe an extra button
 can be integrated in the floating editor toolbar, like the block
 navigation block. I rather see the breadcrumb just above the toolbar,
 saves a click and creates direct awereness.
 As for a resuable block, it must be certainly visible when a user starts
 to edit, cause these edits affect the whole site. Yes, even before the
 user "can" edit something. Like before 5.7. Click to edit; and then the
 auto-save function is okay as the user is brought aware of the edits in
 the reusable block.


 Third:
 as it is not clear when editing a reusable block. When the user saves a
 page, the right bar shows "some" options. Alhought i'm +15 years into
 webdesign, i too don't know what those options really mean. Okay, it's
 obvious when i check the boxes that the blocks and pages are saved. But
 what happens when i deselect the option...
 What happens with the page, what happens with the blocks, and oh yes, i
 didn't even know there was a reusable block, so when i deselect it, is
 then a new block being made ...
 My suggested workflow is: drop the checkbox for the resuable block, create
 the awereness BEFORE the user starts the editing process, not in the END
 of the process cause to be honest: is there a way back in that phase... a
 method that a regular user can understand? ... Right.
 So in that start phase, a proper notification has to be given like:
 You're starting to edit an existing reusable block which is being used in
 "2" other places. Would you like the changes also over there, then keep
 editing. If not, create a new reusable block or convert to regular blocks.


 Fourth:
 The resuable blocks don't have revisions. Never understood why, as it is
 created like a 'custom post type". So, in some cases, the user can lose or
 overwrite the existing reusable blocks. And grabbing a backup for such a
 thing can't be the solution. Revisions is the solution; this system is
 already installed in WordPress. And the reusable blocks must be quicker to
 access, not only via the tree dots.


 There a lately a few tickets around reusable blocks, concerning blocks
 disapperead, multiple blocks with the same name.
 In my opinion that is a result of this chosen workflow in 5.7.


 I would not advice to upgrade to 5.7 when a site relies heavily on
 reusable blocks.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52831>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list