About the new Plone 5 "Related Items" widget

Plone 5 is doing a smart improvement unifying the widget used for referencing contents (thanks mockup :beers:).

Now we finally have the same widget in:

  • Contents relateditems-likes field
  • Internal link from TinyMCE
  • Portlets that reference stuff
  • Content rules
  • ...more?

Unluckily we had some negative feedback from customers who used this widget. I'm wondering if this has been developed from scratch in mockup or came from a 3rd-party work.

At first glance it seems to suffer of accessibility issues. It can be used with keyboard, but I find a lack of alternative text or WAI-ARIA attributes. I didn't gone deeply inside this but I fear that WCAG are not there.

Apart the accessibility issues I got some negative feedback about usability (both customers said that Plone 4 reference was a lot easier to use... and I agree).

Let me recap and show those [issues].

The widget is logically splitted in two sections: what I call the Explore Section™...

... and what I call the Search Section™:

[1] Icons that activates those two section are really small and unclear (not even sure they seems clickable).
The Search Section icon is more or less like an "home" icon, and in facts it became a root link for the breadcrumbs that appear later, but this became clear only when opened (and after some time spent on using it).
OK, not a big problem there.

[2] The explore section is confusing the user. Clicking on folders names will get an "empty" label if the folder not contains subfolder, or you will get the navigable subtree.

Clicking of the arrow on the right will shift the user in the Search Section™, restricting the search to the selected folder (Restricted Search Section™)

[3] If a user starts exploring the site from the Explore Section can't select a leaf and he's forced to bet on a folder and switch to the Restricted Search Section™. This is annoying.

[4] Let say that the user selected the wrong folder from the Explore Section. He can't easily move back from the Restricted Search Section... he must start the search from scratch.

The fact that the Explore Section can't be used for selecting any elements, IMO leads users to use only the Search Section. I think that on old Plone versions the most used feature of the reference engine was the ability to navigate the site (pure search became quickly useless on not-small sites).

[5] Seems that search use the full text search index so you will probably find a lot of unwanted contents. Old Archetypes reference field worked the same way? I don't remember (as I said, I didn't used the search often).

[6] The user can select any kind of document. Old widget simply display as selectable only allowed types. Now users can only wait for the save attempt and get an error in that case.

I found this really annoying. We have a site where we developed a clone of the Image content type (Figure) with some additional features. Figures and Images were loaded in the same folder, but we have also a tile that needs to reference only Figures.
The lack of information (at least a tooltip) about the portal type transformed this configuration in a "Where's Waldo" game (yeah, we didn't provided a new icon for the new type, but adding icons is not a 3 minutes operation now).

[7] On icons again. Folder icons are not displayed. It seems that this widget is the only place left in Plone where real HTML images are used, and not just CSS. So the "document_icon.png" image is still there in Plone but not the "folder_icon.png"? Not sure about how this work (for example: files specific icons are there).

...(Disclaimer: I'm a big fan of old-style-img tag for icons, I think we have lost something by turning on the dark side of CSS icons, but still I find some inconsistency with this behavior)...

So, before star opening issues I'd like to know your impression about this. Nobody else raised similar notes about the new widget? Can we do something better?
Let say I'd like to work on this: I'm not 100% familiar on the way this work right now, but I imagine that lot of this work should be done on the mockup size. Isn't it?

Note. I have also lot to say about this widget from a developer point of view but I don't want to go off-topic (maybe another post in few days :smile: )

1 Like

All of those should be UX bugs in the CMFPlone tracker. You don't have to have solutions to them to raise bugs. There are at least five bugs reports to be made in this post.

I think a very recent (2-3 weeks) PR changed the search to use just the title field

I'm still getting used to working with P5 (working with it on almost all my projects now). As I run into UI issues I do try to file them if they're simple changes, e.g. getting keyboard focused on the first text field. I am confident that we are improving things and are converging on a much better UI.

I very much like your analysis and your willingness to put so much thought into it - bravo! A really good start to the conversation.

I'll just say a few comments here:

  • it is based off the of the select2 widget
  • most admin UI is not super WAI-ARIA friendly, not just this
  • it was mostly developed by someone who is no longer working on plone and then a lot of the further dev on it was more or less forgotten
  • it's difficult to make a compact, uber select everything widget
  • at our company, I have a different explore widget that uses a modal and gives more of a finder window to select content but I am not making a PR for it because everyone in the community is allergic to there ever being the possibility of stacked modals.
  • we'd love PRs to make things better, the explore part sucks

Absolutely, but simply open issues help to trace problems but not a good place for a general discussion about how to fix them.
Unluckily I'm not talking (here) about development issues but usability/accessibility ones. What is missing is a concept direction about how this can be fixed.

@vangheem: can you provide at least some screenshot about your alternative widget? It sound interesting to me (can it be packaged as an alternative widget? Of course: if it can be opensourced)

Github is a great place to discuss how to fix it. Each ticket can cover a single issue rather than a hard follow conversation on many seperate issues at once. The issue description itself can act as a wiki to summarise all the possible ways to fix it and the pros and cons. And whatever the rationale for any ideas that are intentended to be implemented won't be lost.
I really don't like the idea of creating tickets for feature requests even if u have a good idea how you want to fix it.

@keul I agree in every single complaint. The problem is, nobody feels responsible for this widget, its kind of orphaned. If you would take over further development you would have a lot of new friends :wink: . Even small improvements are very welcome.