Change Details

Throughout a conversation with @RHo and @Pginer-WMF we were trying to identify possible hurdles in current widgets' user interfaces. At buttoned NumberInputWidget Rho pointed out, that it seems problematic to have the minus and plus buttons on opposite sides. Use case: A mouse/pointer-only user has gone one step too far up and needs to move all the way to the other side to correct the value. Browsers' native implementation features a (not very user-friendly because minuscule, button size against sev human-computer-interaction guidelines) top plus, bottom minus buttons on one side. The original design layout featured a smaller “stepper control” (less wide), something that you can also find in the wild. We should not forget about mobile design of the widget, where big(ger) touch action areas are needed. Also, the button position should be the same in any theme.

Throughout a conversation with @RHo and @Pginer-WMF we were identifying possible sources of user dissatisfaction/hurdles in current widgets' user interfaces. At buttoned NumberInputWidget (as of v0.17.9) Rho pointed out, that having minus and plus buttons on opposite sides seems problematic. {F4466960 size=full} Use case: A mouse/pointer-only user has gone one step too far up and needs to move all the way to the other side to correct the value. Browsers' [[ https://codepen.io/Volker_E/pen/RGAOPx | native implementation ]] features a rudimentary (& not very user-friendly because minuscule, button size against sev human-computer-interaction guidelines) top incremental, bottom decremental buttons on one side. Chrome shows the buttons just on `:hover`/`:focus` | Firefox | Chrome | |{F4466422 size=full} | {F4466424 size=full} | The original design M44 featured a smaller “stepper control” (limited width), something that you can also find in the wild. Original: {M44} [[ https://www.biber.de/artikel/1/410413/leseleuchte-stahl-messing/ | Example in the wild ]]: {F4466074 size=full} We have to considerate mobile design of the widget as well, where big(ger) touch action areas are needed. Also, the button position should be the same in any theme.

Throughout a conversation with @RHo and @Pginer-WMF we were tridentifying to identify possible possible sources of user dissatisfaction/hurdles in current widgets' user interfaces. At buttoned NumberInputWidget (as of v0.17.9) Rho pointed out, that it seems problematic to have thehaving minus and plus buttons on opposite sides. seems problematic. {F4466960 size=full} Use case: A mouse/pointer-only user has gone one step too far up and needs to move all the way to the other side to correct the value. Browsers' native implementation features a (not very user-friendly because minuscule[[ https://codepen.io/Volker_E/pen/RGAOPx | native implementation ]] features a rudimentary (& not very user-friendly because minuscule, button size against sev human-computer-interaction guidelines) top incremental, button size against sev human-computer-interaction guidelines) top plus,bottom decremental buttons on one side. bottom minusChrome shows the buttons on one side.s just on `:hover`/`:focus` | Firefox | Chrome | |{F4466422 size=full} | {F4466424 size=full} | The original design layoutM44 featured a smaller “stepper control” (lesslimited wideth), something that you can also find in the wild. Original: {M44} [[ https://www.biber.de/artikel/1/410413/leseleuchte-stahl-messing/ | Example in the wild ]]: {F4466074 size=full} We should not forget aboutWe have to considerate mobile design of the widget as well, where big(ger) touch action areas are needed. Also, the button position should be the same in any theme.