When I recently reviewed the patch in #2037677: User Interface: available tokens per metatag group in admin, it was also the first time I got exposed to the modal version of the listing of available tokens. At first I thought that was a neat UX improvement, but after playing around with it for a bit I actually found it more difficult to work with that the old inline version. Particularly on configuration screens with many input fields, such as those the Metatag module provides.

As seen in the below screenshot (1024x768p window size) the modal is actually taking up a large chunk of the visible page:
token_list_modal.png
Note: I've highlighted the modal for illustration purpose only.

The main UX issues I have with this is:

  • Often opens up above the fields for which the tokens will be used - forces me to have to move and scroll.
  • For long forms, such as in the Metatag, it is highly likely that the modal will scroll outside the visible part of the screen.

What I found was that this lead to an exercise where I had to scroll up and down while moving the modal around as I was working myself through the fields. Yes, there is scrolling involved with the inline too, but much less as it is in a static location and wont cover any fields and as a result be more efficient to work with.

Suggested UX improvement

From my experience testing this on a 1920x1200 monitor, I don't believe it is possible to get a much improved UX as long as the modal is stuck in the same browser window on-top the forms.

However, if it instead would open in a separate browser window it would for most users both greatly improve the UX and also make it much more efficient to work with. Particularly for users with high resolution, or multimonitor setup.

The separate window needs to include info about what form it was opened from, since the available tokens may differ. It can also be reused whenever I click on a new token list for another form.

Combine and let the user chose

Another UX problem, as highlighted by @DamienMcKenna in, #10 of the above issue, is that it seems to be up to the individual module developers to chose to use the inline or modal version.

My proposal here is to simply let the user chose by offering both version at the same time. Something like:

  • [ Browse available tokens: [link: Show inline] [link: Separate window]]

Then the UX will be the same everywhere and the user will be able to select the preferred list on the go.

This would also not take up any more space on the screen as it will fit nicely in the old inline fieldset.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna’s picture

DamienMcKenna’s picture

FYI this is in relation to the new dialog option in recent versions of Token.

tsvenson’s picture

Issue tags: +Usability, +D7UX usability

Ahh, thanks for pointing me to that issue Damien. Totally missed it when I was searching for any existing discussions.

Adding a couple of tags while at it...

tsvenson’s picture

Here is another screenshot illustrating how the node tokens and specifically how to locate the [node:url]:
token_list_node_modal.png
As seen here the token dialog takes up the full visible space in the browser (again 1024x768p). The node url token is last in the list as highlighted in red.

Since the dialog is dynamically changing size as I expand/collapse the list of available tokens it will quickly cover the form behind like this.

I think it is also quite safe to guess that the below situation will happen:
token_list_node_modal_no_field.png
Now this will become an exercise of moving and scrolling to locate the correct field for the token, then back to the list again. Alternatively I can highlight the token, use the copy function and then paste it into the field, but that is actually not much better UX.

I am a big fan of and advocates about that we need much more modals (dialogs) like this in Drupal as it is a great way to improve UX. However, in this case having it integrated in the same browser window is not optimal and in many cases will result in a worse UX as I have illustrated here.

While I suspect that changing the integrated dialog to a detached one most likely requires a lot of work, I do believe it is well worth the effort. It will allow users to focus on getting the tokens in place with and at the same time eliminate these UX issues.

Dave Reid’s picture

Patches welcome!

tsvenson’s picture

Wish I could help with patches here, but then they will probably not be ready until Drupal 10 or something. Here's hoping someone will hear the call...

In general, what's your stance on these ideas?

If you like it, I believe we can break this up into two separate issues:

  • Opening the list in a separate window
  • Create a combo and allow the user to select which one to use in the UI

I guestimate that the combo is a fairly easy patch compared to opening in separate window so splitting them is probably a good idea.

Let me know what you think and I take it from there.

tsvenson’s picture

Issue summary: View changes

Updated issue summary.