Adds most used tags feature to gutenberg similiar to the functionalit…

[olivervw]

…y known in old editor.

Description

I added the possibility to select from the 10 most used tags in the flat-term-selector GUI. Similiar as desgined in the ticket #8867 .

How has this been tested?

Unit-Tests as defined in the gutenberg repository were run. E2e-Tests not runnable out of the box. So no testing of e2e possible. Tested by clicking and debugged mobile view in Chrome.

Screenshots

Types of changes

New feature

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[paaljoachim]

Thank you very much for creating this PR @olivervw

I checked the following PR at gutenberg.run

The Classic Editor tags system:

By clicking "Choose from the most used tags" a tag cloud shows up.
We see 19 tags.

---

Suggested approach for Gutenberg made through this PR:

By clicking "Choose from the most used tags" a tag list shows up showing top 10 tags.

The approach in this PR is very similar to the Classic Editor approach. Instead of the cloud we see a list. A version 2 iteration (next version) could be having "tag name (5)" as in the tag name and then the number of posts using the specific tag.

@mapk @enriquesanchez @youknowriad

[enriquesanchez]

Hi @olivervw, thank you so much for working on this!

I have some design feedback:

Can we place the "choose from the most used tag list" link in-line with the field's description? I think this should help save space and keep the layout tidier.

---

I did some stress testing by adding a very long tag name:

I'm not sure how I feel about this. Do y'all think we should truncate with an ellipsis long tag names? Should we display them as long as they are?

---

As for accessibility, this is a button with expanded and collapsed states, so it's important we properly communicate the button's state with aria-expanded: https://www.w3.org/WAI/GL/wiki/Using_aria-expanded_to_indicate_the_state_of_a_collapsible_element. Do you think we can add it?

[paaljoachim]

I'm not sure how I feel about this. Do y'all think we should truncate with an ellipsis long tag names? Should we display them as long as they are?

I think we can go ahead and truncate the long tag names. (Perhaps to 15 characters/spaces.)
Btw here is what it would look like when truncating the very long tag name.

[olivervw]

Thanks for the fast feedback. I will do the modification for displaying the text. I also agree with the truncating and the aria expanded.

[olivervw]

@enriquesanchez Actually I like the layout like it is. It seems more structured to me. Nevertheless will I include your design request into the next commit without replacing the "." within the FormTokenField's help text.

[paaljoachim]

Taking another look at the PR through gutenberg.run
Having the "Choose from the most used tags." in-line would help. I wonder if it would fit inline beside the word key. As it might spill over to the line below it.

This is starting to look really good!
Great job Oliver!

Thinking out loud....
Would it be too much to have 8 tags in each row......? With a total of 16 tags vs 10 tags.....
The reason why I say this is of course the more tags that are quickly available and seen the better.

[mapk]

I honestly think we show the tags similar to the Classic cloud view, but without the size differences. The two columns cause an awkwardness with longer tags and I don't think truncating them makes sense here. We're adding this list because we want the user to know which tag is being added. If we truncate it, it still may not be obvious.

How's something like this?

[paaljoachim]

Mark that is a good idea! It could remove truncation and give an opportunity to show more than 10 tags as it would be much tighter than a list. The only thing I have against it is that it is not as clear to read.

The "Separate with commas or the Enter key; or choose from the most used tags." text is also tighter.

[afercia]

Couple things missing for parity with Classic Editor:

1
On Classic Editor, each item in the list of the most used tags uses an aria-label attribute to add the usage count of each specific term. For example:

<a ... aria-label="alignment (3 items)">alignment</a>

This info is then announced by screen readers:

2
On Classic Editor, when a term is added to a post, an audible speak() message informs screen reader users the term has been added successfully:

[olivervw]

@afercia Thanks for the review ! I will correct the code when i find the time for it.

[paaljoachim]

Hi @olivervw

Thank you for working on this important (well all are important in their own ways) PR!
As you notice things do show up along the way that can make seemingly straight forward PRs not as straight forward as one first might have thought.

Let us know if there is anything we can do to help the PR along.
Thanks!

[olivervw]

Couple things missing for parity with Classic Editor:

1
On Classic Editor, each item in the list of the most used tags uses an aria-label attribute to add the usage count of each specific term. For example:

<a ... aria-label="alignment (3 items)">alignment</a>

This info is then announced by screen readers:

2
On Classic Editor, when a term is added to a post, an audible speak() message informs screen reader users the term has been added successfully:

The 2nd part is tough... Not sure how to implement the speak() function after adding the term. Is that the right way: https://a11y-guidelines.orange.com/web_EN/exemples/speak/index.html ?
Any help would be appreciated.. Thanks

[olivervw]

@afercia 2nd problem i got is with your role="list" suggestion:

[afercia]

@olivervw

1. For core, you can have a look at what wp.a11y.speak() does. In Gutenberg you can use import { speak } from '@wordpress/a11y';. There's also a dedicated higher order component withSpokenMessages. Not sure when it's best to use the former or the latter. /Cc @aduth

2. There are already usages of /* eslint-disable jsx-a11y/no-redundant-roles */ in Gutenberg to disable that lint rule for unordered lists with role="list".

[olivervw]

@afercia Lint error fixed, the term added screen reader feature i still dont see as part of this pull request, since the flat-term-selector component relies on an external function when its content got updated and term added message isnt spoken when a tag is added the conservative way by typing..

PR in my point of view done. Correct me if iam wrong...

[paaljoachim]

Hey Oliver. Thank you for continuing with the PR!

Here is a test using gutenberg.run

This is looking really good! Thank you Oliver!

The only question I sit with is... should we example go from showing 10 most used tags list to 20? As one is extending the "Choose from the most used Tags" the higher number of visible tags seen the better. It does not matter if it takes additional space in the sidebar, as one can easily click to close the most used tags list.

@mapk @enriquesanchez

[olivervw]

@paaljoachim ok changes done, now accepting 20 as suggestion.
As you mentioned above it would also be possible to have a comma seperated list with available tags. In my point of view the point of this gui element is to limit the choices to the author and to make the appearance of the individual suggestions as easy to spot as possible, so personally I think the layout with two columns sticks to this needs.

[paaljoachim]

Hey @olivervw

I tried testing this again with gutenberg.run but it is showing the 10 tag list PR and not the 20.
EDIT: I have tested some more using gutenberg.run and the PR seems to not be working correctly.

I also tried testing locally using terminal.
Following this: #25202 (comment)
Using git checkout update/flat-term-selector but it did not match any file known to git.

I can test it again later on.

Perhaps you could add a screenshot of what the list looks like when there are 20 as one could compare it to the 10 tag gif I shared?

To me this PR looks about finished..:)

[paaljoachim]

I got it working by using a new kind of test/running of PR's. I'll get back to that later.

The Classic Editor had a totally different way of showing tags and could show a lot of them at the same time. Showing 20 tags works well in Gutenberg.

@enriquesanchez @mapk
Let's get this PR merged..:)
Should we adjust the sentence to become "Choose from the 20 most used Tags" ?

[afercia]

the term added screen reader feature i still dont see as part of this pull request, since the flat-term-selector component relies on an external function when its content got updated and term added message isnt spoken when a tag is added the conservative way by typing..

@olivervw thanks for working on this. I'm not fully sure I understand what the "conservative way" is. Regardless, a spoken message is used when users add a term from the suggestion list:

Technically, this is in another file but I' not sure that's a point. In the Classic Editor there's a message when terms are added from the most used ones. There's a reason for that: without a message, screen reader users won't have a feedback on what happened. For feature parity, there's the need of a spoken message also in the Gutenberg implementation.

Aside:
the text Choose from the most used %s shouldn't be italic. see https://core.trac.wordpress.org/ticket/47327

Let's get this PR merged.

@paaljoachim I do appreciate your enthusiasm 🙂 However, can we please refrain from suggesting to merge features that aren't finished and are not accessible? Thanks 🙂

[olivervw]

@afercia What I try to say is the current Gutenberg 'Tags' GUI-Element is not supporting this accesibility feature, so that is why my argumentation is: That feature is not part of the pull request and should be handled in another ticket. If the current Gutenberg-Tags-Element isn't 100% pariety-conform with the classic editor then this matter shall be analyzed and thought deeper than just adding this single pariety feature...

[mapk]

I'm still partial to this layout if possible #21859 (comment)

[paaljoachim]

Hey Oliver.
@olivervw

If you can backup what you have done and hopefully create a version showing #21859 (comment)
that would be great. As we would be able to also look at the other method.
Thank you!

I apologize for all the extra work. We are slowly getting there! The goal is there in front of us even though the road is a little bumpy along the way. Thank you again for working on improving tags feature in Gutenberg! It is something we really need!