Rename Group blocks in the Editor via Modal #53735
Conversation
|
I would appreciate any ideas on if/how we can create a UI which allows users to revert the custom naming back to the original (e.g. |
|
Size Change: +585 B (0%) Total Size: 1.51 MB
ℹ️ View Unchanged
|
|
@alexstine In terms of a11y, I tested this with Voiceover and it seemed to work well. The only question I have is whether once you submit/cancel we should add a |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
Nice! I forgot that we shipped a #43986, so it to me a minute to realize why the List View could already display changed name 😄 |
|
Also resurfacing this comment by @mtias asking for this effort to be aligned with partially synced patterns. That comment thread lead to a dead-end so I'm pinging @kevin940726 who I believe is still working on this feature 😅 |
|
Flaky tests detected in 39fe73a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6048004840
|
There was a problem hiding this comment.
Nice work, I like the idea of just starting with the Group block, too 👍
Nice! I forgot that we shipped a #43986, so it to me a minute to realize why the List View could already display changed name 😄
Same here 😆. A good case of a feature being built iteratively! 🎉
I would appreciate any ideas on if/how we can create a UI which allows users to revert the custom naming back to the original (e.g. Group). Probably one for a followup...
Could we allow saving an empty block name field to perform a reset? I.e. if a user opens the modal with a custom name set, and then deletes the custom name, could we allow the Save button to work? I suppose that'd mean updating the check so that we only look for notEmptyString if there isn't already a custom name set. Here's how it's looking for me currently:
Other than that, this is testing very nicely for me.
One question re: how the code's organised — do we need the separate block-rename-ui.js file, or could we combine things in the metadata-name file, so that the UI related to the hook is contained within the one file? I don't feel strongly about it, but I see there's quite a few files in this directory, so wondered if it'd help consolidating things in one place. Just a thought, though!
I was thinking about something similar last night. Here's the logic I had in mind:
|
I like it! |
✅ This has been implemented |
@andrewserong I was following the example set by: Personally I don't think the registration of the metadata field However, if there is a precedent / convention established that it would be helpful to follow I'm happy to do so. |
|
Writing some e2e tests now. |
@richtabor Which bit specifically?
|
|
@millertchris Its also worth pointing out that OS-specific functionality is not generally impacted by web standards. Screen readers use available OS APIs to maintain compatibility outside of the web and these are generally a lot more stable vs. countless ARIA attributes. There is a difficult aspect in accessibility around education, that users are just supposed to know certain things. Its one thing to double click and rename, its another to know you need to press F2 or Shift+F10, Down Arrow to Rename, and then press Enter. My brain is always learning new keyboard shortcuts because even different Microsoft Office programs have different interaction models. Its a lot to ask of a user to constantly remember more shortcuts and interaction models. Plus the modal approach helps us with focus. That is a problem you generally don't worry about so much in the OS layer but it matters a lot in SPAs rendered by React. Feel free to connect with me on Slack, at alexstine, if you want to discuss this further. I am blind and I graduated with many blind people, so I can speak much further to why we should avoid the type of interactions you describe. I want Gutenberg to do things differently for the accessibility of it to all. Thanks for adding your opinion. Ideas are important for any projects success. |
|
@alexstine what's your opinion on maintaining the modal functionality alongside double-click? |
|
@richtabor Unusable for me but as long as the rename option exists in the block options menu, I'm fine with it. Thanks. |
|
@alexstine here are my responses:
@alexstine double-click is unusable to you but the enter key is not, right? That's how you interact with forms and countless other element when you have focus, correct?
Fair point — but I would also look to all other widely adopted UX patterns for renaming things on the web i.e. Chrome Bookmarks, Firefox Bookmarks, Figma, etc, etc.
I agree — and that's what tooltips, labels, landmarks, etc are used for. To announce to the user when an action can be taken and how to take that action. Also, remember that users are also all accustomed to renaming things in all of these other platforms i.e. Google Chrome Bookmarks — so my position on this matter is let's not force the user to learn how to do the same thing differently just because they are using WordPress.
I'm not sure I follow this point — CMD + C / CMD + V is the same shortcut across every piece of software. Could you imagine if a piece of software decided not to adopt this and how disruptive that would be?
I disagree — in order for the modal to be in focus, you have to write some additional JS to make it so. However, if the user has already tabbed to the layer or clicked on the layer, it's already in focus. No additional actions necessary. I'm not exactly sure what type of markup is used for the layer markup but if it where an input (but styled to look like regular text) and the input label visually hidden — that would follow existing accessibility best practices.
I appreciate the invite and I'll look you up! I myself am a low vision user and have been working with American Printing House for the Blind for many years. Our agency is also working on a beta release for an ALT text WordPress plugin that leverages AI to help ensure that all images on the web receive helpful alt text. I would love to chat with you about that some more when we connect. @getdave here are my responses:
I would argue that massive amounts of engineers, developers, designers, etc over the decades have put a tremoundous amount of thought and consideration into how this work. Again, think Chrome, Firefox, Mac, Windows, Linux, and the endless sea of software that we all use on a daily basis all adhere to the same design and UX pattern when it comes to renaming things. Accessibility included. It feels like we are trying to reinvent the spoon here.
Absolutely and I admire the amount of attention and effort that went into this. I still question how this is a more accessible or a better UX experience. If the WordPress community is attempting to "reimagine" this particular experience — then is the community taking a stand or wanting to influence how all other platforms operate? If so, then that's something I could personally get behind — but if not — then why? I'm totally down with helping in anyway possible — and subjectively — I would love to see a solution in core (eventually) that aligns with the same UX we see across all pieces of software. Same way WP adopted the CMD+P / CMD+K to bring up a command palette. 😉 |
|
Hi! @millertchris I am chiming in to tell you that your input is valuable, correct and to also try to clear up some of the items in @alexstine and @getdave 's comments and I think we're all on the same page here.
It is true that the standard rename process of items in trees in OS based software is like you describe it, the problem is inside the browser there are not many examples. And the examples that exist e.g. Figma probably miss the underlying issues we have. Many web based apps have an "accessibility mode" to mitigate this. WordPress doesn't and it aims for offering a similar experience for everyone. Nevertheless, like Dave said, nothing is set in stone.
You are right to question the UX. The accesibility improvement is covered in the process we went through, and should be documented instead of questioned. On the side of UX I don't think anyone sighted and used to the standard process that decades of tree UIs taught is going to say this is the best we can do. On the side of accessibility having the rename in the dot menu, with the modal, makes a lot of sense. I think the best path is what @richtabor suggested to have both paths. For the rename via double click and enter we need to make sure we are able to overcome the noise and announce what is going on properly, which may be challenging. Fot rename via the dot menu we need to fix the focus management. IF eventually the ways merge into one and the rename in the dot menu biggest issue is how to land focus back in the tree. It will be announced in a very confusing way. This does not currently have a solution.
That is not the case I believe. We're trying to make it as people expect it - but sometimes the road to there is longer. Also on:
... we all agree on this. What Dave explained is for this particular implementation (which is one step, not the end) there was a lot of effort to navigate through different needs of different people, and the history can be found above. We need to build on top of where we're at. I think we can and should revive the rename with double click/ enter and add that along with the modal behavior.
You can help with that! 🙇🏻 |
Single Enter press moves focus out of the list view and into the editor canvas to focus the block, can't use that here.
I realize these might not be so visible to visual users alone but if you fire up a screen reader, you will find that all these implementations in Google Chrome and Firefox are the exact same way we implemented it for the editor semantically even though it may not appear as a dialog/modal visually. For the modal, we use a custom React component that handles focus and roving tab index by default. APH, that's cool. I went to the Kentucky School for the Blind but live in Dallas now. I did have the chance a few years back for a little collaboration. Thanks. |
|
First off — I really appreciate the energy and time you all are putting into this thread alone @alexstine @draganescu @getdave @richtabor and anyone else that's involved! @alexstine here are my responses:
Right — but that would need to change if we were entertaining what we're discussing.
Totally fair and valid points — and their experiences have also changed from the last I remembered them so I'm completely wrong in providing those examples. OK — so now I see what's happening when really putting all of this to the test.
That said, here's a proposal:
This seems like a reasonable compromise which will give sighted users and low vision users what they want, while still providing low and no vision users with the modal option that they want. This could be a win / win for everyone. 😄 What are your thoughts @alexstine ? @draganescu here's my responses:
Totally agree — and I think we should absolutely steer clear of band-aids like "accessibility mode".
I agree and disagree — just as much as sighted users should not be the governing body over what low-vision / no-vision users want/need, the same can be said the sighted or low-vision users. From a screen reader and semantics standpoints, a modal can totally work, and visually, it doesn't have to "appear" as a modal but can work and appear like we are accustomed to when renaming layer. Here's my biggest issue with the workflow: Rather than:
We will have to:
Adding more steps, objectively, is not good UX for everyone. It's getting in the way of productivity and efficiency. Good UX should improve the quality of life, for everyone. ❤️🔥
I'm 100% with you!!! There's not a one-size fits all here — but we're moving in the right direction.
I have not tested the announcements yet, but in my proposed solution above where enter is replaced with tab — you could implement the shift+tab to tab back to the layer you came from, just like we do in forms.
I'm 100% down with that! P.S. I was also not able to find keyboard shortcuts anywhere in the "Keyboard shortcuts" modal that tells me how to interact or trigger the ellipses (three dots) within the "List view". @alexstine do you know what shortcut key is used for that? |
|
@millertchris Love your suggestions here. I think relying strictly on the tab key to focus a block's content (and shift tab to move back to the list view) to free up the enter key for rename is the way to go. 1st tab press -> focus the block (and move into editing/writing for paragraph/heading, etc.) I realize there would be additional tabs for blocks that have tabbable options as part of their content like the image block, a new group block, etc. but generally speaking, I imagine a 4th tab would take the user to the sidebar. Workflow for keyboard users would be:
This would add quick block renaming with the enter key for keyboard users as well - something that I think would be very intuitive. The right arrow would work as it does now in list view to move to the context menu for the selected block giving the option to rename a block using the context menu as well for users who prefer things to be more explicit. I would love to see this all done with inline renaming but it would work with a modal based system just as well. Adding double click to rename would be icing on the cake. As it is now, Enter feels a bit confusing and unintuitive, especially on a paragraph block. Just experimenting with it for a few minutes, I had to do a double take a few times to understand what was happening (after adding a number of unintended empty paragraph blocks). @alexstine @draganescu @getdave @richtabor what are your thoughts? |
|
Short answer, it isn't going to happen without refactoring the entire editor experience and I'm not sure any of us have the bandwidth for a task this huge any time soon. The list view itself is a floating sidebar of sorts so I don't like the idea that Tab/Shift+Tab moves focus to the currently selected block and back. The current system with writing flow where Shift+Tab moves to the block toolbar and Tab moves to the sidebar is super hacked together and its something we're looking to replace. Current items:
Essentially, the principal is Tab/Shift+Tab will be used to perform text actions in content editable blocks and those shortcuts will be used as navigational keys in non-editable blocks.
Yeah, its actually a better experience as a keyboard user and sorry I couldn't see passed my own objections to realize it sooner.
I can do this in no time flat as a keyboard power user but it does seem unfairly slow with the mouse. We are currently working on adjusting the I still want to point out though that this would not be super discoverable. Enter to rename is a Mac OS feature, not a Windows one. So I'm not sure how much time it would save certain people over others, it would likely be highly dependent on which OS they are from. On Windows, the keyboard shortcut is F2 to rename in Windows Explorer. A normal Enter press in Windows Explorer opens an item. Single click would select and double click would open. Even Mac vs. Windows things at OS level are so different. I value your ideas and not trying to shut them down but we've got bigger fish to fry right now. I know the flow for this feature could probably be improved but I am working really hard to give all users a great editing experience. I'm really busy at the moment trying to fix bigger bugs around how the editor behaves outside of this one sidebar. My eventual goal is to see the list view become the primary means of block navigation because currently there are 2 other ways. Its really been a development nightmare keeping it all working. My point, you are envisioning functionality super far out of the scope of any one PR and this probably needs to move to a discussion. That way everyone can have their ideas heard, we can all have an open architecture discussion, etc. I'd hate for all of this to eventually be forgotten in a PR that we all forget about later. Thanks. |
|
@alexstine Thank you for your response and expertise. Earlier, @richtabor asked if you would be fine with a double click and you replied that as long as the option remained in the context menu, you're fine with it. Can everyone agree that this is a path forward in satisfying the wants/needs of a large number of users? I'm in a number of advanced user groups and there was some recent scoffing about how many clicks the new rename features take compared to what they deem to be "professional" builders. I explained that a double click option was suggested and executed by @richtabor in 2021 but there's a lot more to getting something into Core. Anyway, I think it would satisfy a lot of power users who are used to a double click rename just being the way things work in other WP page builders, apps, etc. |
I'd like to clarify that this [Inline approach] was explored in detail recently (i.e. not in 2020) in #53852. Just wanted to avoid any confusion that this wasn't explored recently. |
|
@getdave I loved your approach in #53852. If there is support, I think it is the way to go. If there isn't support right now, or if people feel it's a possibility, but not in the immediate/near future, I think incorporating a double click to open the modal (so not exactly inline) and focus the name input field with this current PR would still enhance usability for mouse users who are looking for a quicker way to rename blocks. The complete process would be: While this UX doesn't exactly mirror what people are used to with other page builders/apps, it is functionally very close |
|
I like @briangrider 's idea to, for now, add double click as another way to open the rename modal. |
|
Adding Double Click |
|
Yes, if its a quick add, add. 👍 |
|
Great call outs @briangrider and thanks for all of your insights @alexstine ! I too am onboard with @briangrider here and based on what you mentioned @getdave — and with the support from @alexstine — it sounds like this can be a win/win for everyone! Thanks for everyone's hardwork on this, looking forward to seeing this in core! |
Agreed. |
|
Noting that as of #54590 the rename modal will now have focus placed automatically on the input. This should make the flow smoother. |
|
Hell yeah! |
What?
Adds the ability to give blocks (currently limited to Group block) a custom name via a
Renameitem in the block's options menu.This is then displayed in the List View (although that functionality was enabled in a previous PR).
Alternative to
Why?
Allowing users to distinguish between blocks in the List View is becoming increasingly important as the scope of the Site Editor grows. Given that all blocks are currently labelled by the block name (e.g.
Group) it can be difficult to distinguish between them. This is especially important if your Groups represent distinct "sections" of a given page/template.As you can see the feature is much requested.
Why not pursue the existing PR for renaming within List View?
#42605 has been around for a while and was my original attempt at this. Unfortunately it was beset by a number of a11y changes relating to editing/renaming inline with the list view.
In the PR several contributors suggested making the it a global feature where rename could be handled via a modal. Returning to the PR it makes sense to land this simpler and more intuitive approach first and then circle back to the "inline" block editing (within the list view) if that is possible/desirable.
Why is this limited to the Group block?
The aim is to limit the scope of the change. Once merged it will be possible to follow up to enable this feature for other "container" type blocks.
Where are you saving this custom name data?
It's saved to the block's
metadataattribute under thenameproperty. That's in WP Core and standard.{ "attributes": { "metadata": { "name": "My custom name" } } }How?
Adds a
Renamemenu item to the block's options menu (available in canvas or in list view). When clicked a modal appears which allows you to provide a custom name for the block.Once applied the block's metadata is set with a custom
nameattribute which is then reflected everywhere that consumesuseBlockInformation(that was added previously in another PR).This means that List View will show the custom name.
Testing Instructions
Rename.RenameUI again, but this time remove all of the text and click out of the input field (triggeringonBlur).Group). See theSavebutton is active again.metadata.nameattribute was reset (it should not beGroup).Testing Instructions for Keyboard
Testing instructionsabove but use the keyboard.Screenshots or screencast
Screen.Capture.on.2023-08-16.at.14-17-10.mp4