search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 40 forks source link

[UX] Form API: Do not render selects as dropdown menus if they contain only a single option. #1801

Open klonos opened 8 years ago

klonos commented 8 years ago

...one such "thingy" is the "Widget" options drop-down menu in the "manage fields" page of content types. Here's an example when the field type is "link":

backdrop-manage_fields-single-option_drop-down_menus-link_widget

I'm not sure if it is possible to do this on a global level, but it would be a big UX+ if we could.

Rationale: as a new user, whenever I see a drop-down, I expect various options/choices to be available when I click it. When I see only a single option instead, my first thought is "there goes a wasted click". Having to do this a number of times throughout the entire UI makes things worse.

bd0bd commented 8 years ago

You are very right.

ghost commented 5 years ago

Is this a duplicate of #1442 ?

klonos commented 5 years ago

Hmmm 🤔 ...it's been some time now, but I believe that #1442 was raised specifically for the widget dropdown menus in the Manage fields form for content types; whereas this one here is to implement it globally, in the Form API level.

ghost commented 5 years ago

In that case, I think if it's decided that Backdrop core UI wants to do this in #1442 then that's fine, but to do it in the Form API, that'll affect contrib modules and people's custom code/forms, and I don't think we should make that assumption for people...

klonos commented 5 years ago

I see the point in what you are saying @BWPanda, but there is no merit in having this be an option/select, when there is only a single option to select from - only the added click (multiple clicks if many such selects in a single page), and the added UX WTF.

Consider this similar to the situation where you have multiple radios instead. If certain options are not available, then there is no need to specifically render them (unless disabled/locked). If in the end you are left with a single radio option, what is the point of rendering it as a radio? (see #1837).

ghost commented 5 years ago

there is no merit in having this be an option/select, when there is only a single option to select from

I'd say 'consistency' - not changing the way a form element works/looks based on the number of available options...

I think we should respect developers choice. If they choose a select list for an element, that's what they should get. If they have a single option and want a markup element, they can choose that.

But I also see what you're saying when elements are dynamic and the number of options change. So maybe a better solution would be to provide a new form element that does what you propose. Or, at the very least, have a setting on select elements to allow changing it when there's only one option (but this should be disabled by default).

klonos commented 5 years ago

As a developer, instead of rendering single-option selects as plain text, would you find it acceptable to be rendering them as disabled/locked? That would keep them as the same element, and at the same time prevent the click-with-no-reason UX WTF for end users.

...or would you still find that behavior "disruptive" in some way?

ghost commented 5 years ago

As a developer, if I create a form element using the Form API, either:

  1. I want to use a select list, so that's what I choose (and if I choose to have just one element there, that's up to me/my client). Having it displayed or function any other way would be 'disruptive'.
  2. I want a select list when there's > 1 option, but want something else (plain text, disabled select, etc.) when there's only one option, so I choose a new, dynamic form element or I enable a setting on the select form element. Then it's my decision and not the CMS forcing it's preference on me.
klonos commented 5 years ago

Fair enough.