Problem/Motivation

The Token browser dialog modal has worked well, but can also be a bit slow to use, since you almost always need to move and resize it, before finding the right token. For some users an inline expandable form by each field may be preferred.

Steps to reproduce

Use the Token browser dialog modal, and need to resize and move the modal continually.

Proposed resolution

We could make the tokens available via an expanding form, directly on the page under each Token supported field, to allow immediately scrolling down through the available tokens. This will lead to several improvements in the UI:

  1. There is no need for resizing and dragging the dialog modal
  2. A lot of tokens can be immediately visible
  3. There is no longer a width problem, where token lines break

Token browser GUI

See Token.browser-each-field-expandable.mp4, and images below for a mock-up.

1. A field with the Token browser link
Token browser 1

1.1 Alternate position, after the field
To not interfere with help text ... or maybe inside the field?
Token browser 1.1, after field

2. The Token browser expanded
It's not very wide in this mock up, but it should expand to the full width of the screen.
Token browser 2

3. The field is populated after clicking a Token
Token browser 3

Two modes, Inline or Dialog (Token browser settings)

A new Token browser settings page should support different display modes, allowing a user to choose between "Inline" (via each field) or "Dialog" (current dialog modal). The "Dialog" mode should support a setting for size (ie; small, medium, large) with predefined width/height (25%, 50%, 100%).

The new Inline expandable form should be set as default going forward, while allowing those who still want the modal to switch to that, so the modal might stay as an option under Token settings.

Token browser settings
Token browser settings closed

Token browser settings, options
Token browser settings open

Remaining tasks

Decide if it's a good idea, and if yes, create the feature.

User interface changes

Token browser now offers an Inline expanding form, under each field, and keeps dialog modal as an option.

A Token settings page is added under /admin/config/system/token.

API changes

Data model changes

Issue fork token-3489325

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

ressa created an issue. See original summary.

ressa’s picture

rkoller’s picture

Interesting idea. There is only one problem, with the token browser being in a modal you have the problem that the field the token is pasted into is the last clicked field, with the token browser going into a fieldset it is a similar problem. so if you are keyboard and or screenreader user that might still problematic but i imagine it also tricky for regular sighted users using the mouse. you are in the context of the same page all the time and you dont switch between the dialog and the "main" page so how to know where to paste the token? i've linked an issue as a related issue we've summarized the problem space and provided a few potential solutions: #3478554: Don't base the token insertion process solely on the last clicked field.... but all that discussion in this issue here as well as the discussion in the other issue about the idea of having a drop button boils down to the more fundamental question in which direction the ui of the token module should be heading which is covered in #1229568: Token UI 2.0. and the suggestion in this issue is one of the potential directions imho. but still that might need a bigger discussion. as a start i could put the token ui 2.0 issue on the agenda of one of the next ux meetings as well as bring it to the a11y office hours to get a few more perspectives.

ressa’s picture

[...] one problem, with the token browser being in a modal you have the problem that the field the token is pasted into is the last clicked field

That's true, I forgot about that.

What if all Token-supported fields had their own innocuous, right-aligned "Token browser" link? That way, it will be available, non-obtrusive, and the system will always know where to insert the token.

When a user clicks the "Token browser" link, the Token tree is shown, and the user can expand and collapse it. When a token item is clicked, it is entered into the corresponding field. (I had to hit Tab in my crude prototype screencast, to focus in the field)

1. A field with the Token browser link
Token browser 1

2. The Token browser expanded
Token browser 2

3. The field is populated after clicking a Token
Token browser 3

MP4 file: Token.browser-each-field-expandable.mp4

I am attaching the crude HTML and CSS, in case anyone else want to experiment with it as well, see "4-Token.browser-each-field-expandable-HTML-CSS.txt". Simply copy paste it into the browser.

PS. Another thought: An autocomplete option would be nice, so that the user can type "date", and then [node:date-created], [node:date-updated], etc. are presented as options, but maybe that's not possible, or discussed elsewhere?

apmsooner’s picture

I think this may be a nice option however I would have a few concerns:

  1. The modal can be expanded to the size of the screen if desired. This option would be limited to the width of the container the field is in. Consider if you had paragraphs for example where theres alot of fieldset wrappers narrowing the width. It could lead to a potential undesirable experience. That being said, if its a choice that can be made on the field then perhaps a non issue.
  2. The position of the token browser link could interfere with help text. Maybe if it was something more like a contextual link thats unobtrusive could be an alternative?
  3. Personally I'm fine with the modal option. I just think we need better ajax support to handle recursion or subform like i did as a custom element in my module to not lock user into global restricted depth limits: https://git.drupalcode.org/project/custom_field/-/blob/3.0.x/src/Element...
ressa’s picture

Issue summary: View changes
StatusFileSize
new5.77 KB

Thanks for the feedback @apmsooner, I really appreciate it.

  1. About width, I envision it to automatically expand to the width of the screen. I'll add that in the Issue Summary. You're correct that edge cases could appear, where the structure of the fields might limit the max. width, like with paragraphs ...
  2. The position could interfere with help text, and using something like a contextual link might be the solution. Or perhaps simply position the link right after the field? I'll add that as alternate position.
  3. I think the modal feels dated, and I always need to expand and resize it, hope I clicked the right field first, check if the token got entered, etc. Also, for new users, it may take some time to understand how it works.
apmsooner’s picture

I concur with your thoughts and I like the idea of having options. I still think a form element that allows more options is the best solution so someone can set like 'dialog' or 'inline' as a setting and for dialog, it would be trivial to support a setting for size (ie; small, medium, large) with predefined width/height as I pointed out in https://www.drupal.org/project/token/issues/3478595#comment-15869783. For me, at least having the option to expose settings is critically needed. Having a default recursion limit of 3 is fine for some cases but deep nested entity reference properties can't be seen usually. Some sites may have a ton of fields so anything above 3 would be memory overload but for a smaller site or carefully modeled, setting it to 5 is no problem.

ressa’s picture

Title: Token browser as expandable form, replacing modal » Inline access via each field to Token browser
Issue summary: View changes
StatusFileSize
new24.33 KB
new29.23 KB

Thanks again for great feedback, I have added your mode proposal to the Issue Summary.

About recursion, I think maybe that's better addressed in another issue? Maybe you could create a Token issue dedicated to idea, if it doesn't already exist?