Summary of fago's comments:
I think we need to visually improve how the drill-down-options are listed. Let's add a "dynamic" help text in a small black arrow on the right side:

"The @plugin requires the argument to be of type @foo, so only matching data is shown."
"If some properties are missing, make sure Rules knows about them by using conditions to check for the entity-type (Entity is of type), the bundle (e.g. Content is of type) or a specific field (Entity has field) beforehand."

Initial report (modified):
Before I figured out Some Rules tricks I wish I knew, I struggled with the "node type" screen because it only shows a few entities / fields, and I thought that's all that would ever be available. None of the entries in the screenshot below are node types. If you try to add conditions, you get an integrity error.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

Component: User Interface » User interface
FileSize
29.57 KB

Let's try a somewhat smaller image. Still not small but that's the best I can do now.

chx’s picture

To further clarify, the moment I switched to the "Entity type" condition screen a userpoints-transaction:entity appeared. Also, given that site:current-user: appears this is not a userpoints issue. This screen should error out "you have no nodes, wtf you want". Even better the first add condition selector should probably not be a select but some other UX element where you can show disabled elements to not lead the poor user down a road which doesnt lead anywhere. It'd make Rules a lot lot easier to use.

Itangalo’s picture

Status: Active » Closed (works as designed)

There might be nodes available in other parts of the data that the Data Selector can reach – so it wouldn't make sense to hide the option just because there are no node entities available at the "first level" of available data.

Itangalo’s picture

Title: The node type Data Selector is nonsensical » Provide better help text for the data selector
Assigned: Unassigned » Itangalo
Category: bug » feature
Priority: Major » Normal
Status: Closed (works as designed) » Active

I'm taking this one on. There should be better descriptions of how the data selector works, and what it does.

chx’s picture

Title: Provide better help text for the data selector » Use Hiearchical Select for the data selector
Category: feature » task
Priority: Normal » Critical

If you want people to be able to use the module then use HS with good help text so that people know things are dynamic (right now the ability to drill down is hidden) and in a nice help text you tell the user what they provide. You can, if you are really good color green the things that would provide things that fit that data selector. Ie. if you are after an entity then a field_tag:0 or a field_tag:0:field_nodereference can be colored green to indicate "hey! these look like entities!".

Itangalo’s picture

Assigned: Itangalo » Unassigned
FileSize
1.36 KB

Ok, it is no hierarchical select, but it is some help text for the data selector:

***
The data selector helps you drill down into the data available to Rules.
Note 1: If selecting an item ending with ':' you can access data inside that object, creating chains of related data.
Note 2: If you are expected to provide data of a certain type, only matching data end points will be listed.
Note 3: Entity fields will only be available if you have used the condition 'entity has field' (or 'content is of type').
Note 4: You can use all chains of data found with the data selector as tokens in direct input mode. For example, you can use [node:field_reference:nid] as a token representing the node ID of a referenced node.
***

I know it is quite long, but I feel that all of these cases are important, and easily overlooked by inexperienced Rules users. Adding a rediculously long help text could, hopefully, help more then hinder.

BTW: I really like the idea with hierarchical selects. The interface itself would tell the user that it is possible to drill down into the data structures, and it would be possible to have help texts for each part of the chain of data. (The data selector could of course still be present – if I'm not mistaking, HS could be implemented as another data input plugin.) Writing a HS data input plugin is beyond my skills, though, so I'm unassigning myself from this issue.

fago’s picture

Title: Use Hiearchical Select for the data selector » Improve data selection UX

I don't think going with hierarchical select is an option at this point. It's not fully ported yet and I don't like introducing a dependency on it.

However, yep we need to improve data selection. So let's get the best out of it.

So what about adding a rather big "dynamic" help sentences like that:

"The @plugin requires the argument to be of type @foo, so only matching data is shown."
"If some properties are missing, make sure Rules knows about them by using conditions to check for the entity-type (Entity is of type), the bundle (e.g. Content is of type) or a specific field (Entity has field) beforehand."

You can use all chains of data found with the data selector as tokens in direct input mode.

That should be mentioned at the token help. (or even better provide its own selection tool)

Then, yep I think we need to visually improve how the drill-down-options are listed. We already have a css class for them, so maybe just a small black arrow on the right side would be a good option? I think users are used to that from regular menus which indicate it that way. Maybe we could also open the drill down options on hover?

Itangalo’s picture

+1 for small black arrow!

Also: Is there any chance that the data selector can tell if there is no matching data in the selected part of the data tree? I think those cases are confusing to new users.

chx’s picture

If the help would be clickable and the arrow would indeed add more lines to the help, well that works for me aswell.

mitchell’s picture

Title: Improve data selection UX » Improve data selector help text
Priority: Critical » Major
Status: Active » Needs work
Issue tags: +ux
mitchell’s picture

Issue summary: View changes

removed inline image.

mitchell’s picture

Title: Improve data selector help text » Add dynamic help text to data selector
Category: task » feature
Priority: Major » Critical
Status: Needs work » Active

updated issue summary above.

mitchell’s picture

Issue summary: View changes

a

Joel MMCC’s picture

Component: User interface » Rules Core
Issue summary: View changes

@fago #9:

I don't think going with hierarchical select is an option at this point. It's not fully ported yet and I don't like introducing a dependency on it.

Not fully ported? Even now, nearly ½ a dozen years after your comment, there isn’t even an alpha version for D8! Not even a .yml file!

That said, in the immortal words of Yoda, there is another: Simple Hierarchical Select does have an alpha version for D8, but is Minimally Maintained and No Further Development. Also, it’s for taxonomy only.

That said, perhaps someone here could snag its UI code, adapt it to the structures of the data items and types trees, and incorporate it directly into Rules UI for this very purpose?

(It’d also be useful for someone to become a co-maintainer of or outright take over or fork that module and make a 2.x branch for D7 through D9 that works for all entities that can be hierarchical, not just taxonomies, but that’s getting off-topic.)

(There’s also Client-Side Hierarchical Select but it wouldn’t perform well in this situation, as it tries to load the entire tree into client-side memory and filter it there rather than using AJAX-type functionality. Fine for small taxonomies, not fine for huge trees of data items and types like this would be. Page loads would take a long time.)

Joel MMCC’s picture

I’ve found some other modules that may be even better in their UX whose UX code could maybe be adapted for this purpose.

  1. Taxonomy Tree Select was never even ported to Drupal 7, let alone Drupal 8. That said, just look at its UX!
  2. Term Reference Tree is stable in D7 and has a D8 alpha. At present it loads the entire tree at once, which may not be good for this purpose — but then again, you’d be using the UX code, not the data-loading code (which, like the other modules, is specific to taxonomies, not general to any hierarchical entities or other tree-type data structures).
  3. Select with Style lives up to its name! No D8 version, though stable in D7. But just look at what it can do, and this is just one example (it also does really cool stylized sliders):