Page MenuHomePhabricator

NumberInputWidget: Challenge current user interface of buttoned widget
Open, LowPublic

Description

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.


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 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

FirefoxChrome

The original design M44 featured a smaller “stepper control” (limited width), something that you can also find in the wild.
Original:


  • Example in the wild:

    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.

    Event Timeline

    Volker_E created this task.Sep 14 2016, 1:15 AM
    Restricted Application added a project: UI-Standardization. · View Herald TranscriptSep 14 2016, 1:15 AM
    Restricted Application added a subscriber: Aklapper. · View Herald Transcript
    Volker_E updated the task description. (Show Details)Sep 14 2016, 8:03 AM
    Volker_E triaged this task as Low priority.Sep 19 2016, 5:37 PM
    Volker_E moved this task from Unsorted to OOUI on the UI-Standardization board.Sep 20 2016, 9:35 PM
    Isarra added a subscriber: Isarra.Jan 10 2017, 9:20 PM

    How would you even use the native style on mobile? The opposite sides approach seems pretty good for that, at least.

    Yeah, I don't really understand how they (browser makers) came up with the native interface. It is dumping several human-computer-interaction guideline recommendations (size, focusability…).
    One possibility were, should we even present the + & - buttons on limited space, when the native keyboard is already there on focus?
    Currently by touch-pressing the buttons the input field looses the focus and also the keyboard. Which is presumably not serving the user.

    I have never used the increment/decrement buttons to change the inputs value, especially on mobile. The number only keyboard that shows up is easy enough to use.

    I have never used the increment/decrement buttons to change the inputs value, especially on mobile. The number only keyboard that shows up is easy enough to use.

    We may not need the increment options to be available for all number inputs, but there are cases where small adjustments to the default are common and those are convenient.

    An example from a completely different domain: in the Airbnb search panel only increment and decrement actions are provided for guests. If the most common options for people to travel are 1 or 2 guests, selecting them in one step seems more convenient than editing the default to remove the 1, type 2, and exit editing mode. Having the increment controls next to each other with big enough target sizes works well in both mobile and desktop.

    I'd not consider the pattern useless per se, and I think it can be supported on mobile. I also think we want to identify relevant usecases in our context (I'm not sure when this particular component is being used currently) and define guidelines on where/when such controls are appropriate.

    I'm not sure when this particular component is being used currently

    A quick search showed that it is primarily being used in the APISandbox. It is also used in the ProofreadPage extension, but I couldn't find where the element was in the interface.

    The year selection input on some special pages (such as log) uses this type of input, too, though these have yet to be converted to use ooui. That usage never made much sense to me, though.

    Aklapper removed Volker_E as the assignee of this task.Jun 19 2020, 4:28 PM

    This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

    For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
    (For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)

    Another option were to keep increment/decrement button together, to reduce mouse or hand movement to interact with both buttons:


    Note, that button width is also reduced to 32px here, breaking our standard width. Positively is, that input text would be always on same horizontal starting line with other types of text input widgets above and below, making scanning of forms simpler. Alternatively with same-size buttons:

    Aklapper removed a subscriber: Anomie.Oct 16 2020, 5:02 PM