It's not possible to scroll the lists by putting your finger into the space 'beyond' the list - e.g. beyond 12, or before 1. So you can't "pull it back" from there. This is frustrating, particularly for the AM/PM picker. Gerv
It would be nice if we could get opinion from UX before investing time to work to work on it.
UX will tackle this, but it has to come after all leo+, tef+ and tracking work, which are our top priorities right now.
Reassigning to Casey. Blockers still take UX precedence.
I agree that this is frustrating and should be fixed. The whole vertical section of the value selectors should be draggable (I know it's not a word?!)
UX, last comment was >1yr ago, can you review for relevance?
I don't believe this is relevant based on UI changes in the past year.
This is definitely still relevant. STR: * Firefox OS | Settings | Date & Time | click a time. * See three "windowed strips", one for hour, one for minute, and one for AM/PM * Say AM is selected. * Place finger into blank space above AM and drag up, to try and switch to PM Expect: strip moves Actual: strip does not move You need to have your finger on top of the actual data. This is counter-intuitive from a real-world physics perspective. Also, it should be possible to drag onto the "window" from outside and still have the strip move. At the moment, drags have to start on top of the window itself, although they continue if you drag outside it. Gerv
UX input request again. Stephany, if there's a specific change or bug that you're thinking has resolved this issue, can you drop the link here?
Sorry, I cannot repro this on my end, on 2.2. Flagging Rob to see if he can assist here.
(In reply to Stephany Wilkes from comment #12) > Sorry, I cannot repro this on my end, on 2.2. When you say you can't repro, you mean that dragging both outside the box and in the no-text space in the box leads to movement of the strip? Gerv
I mean I don't think I can literally see what you're describing. But, scrolling is Rob's area anyway.
Created attachment 8565502 [details] timepicker.jpg Please see the attached "screenshot". Steps to reproduce first problem: * Open time picker * Place finger at point A * drag upwards Expect: "PM" to become selected rather than AM Actual: Nothing I expect this because the user mental model is of a "strip" which is moved by the finger. The whole strip is one colour, so I expect to be able to move any part of it. And by instinct, I don't put my finger on top of the values because it would obscure them. Steps to reproduce second problem: * Open time picker * Place finger at point B * Drag upwards Expect: strip to move so that "4" comes into view approximately under finger Actual: Nothing I expect this because it makes it much easier to "flick" the thing upwards if one doesn't have to be very precise about where one's finger starts. Gerv
Helping out Rob with his NI's... In reference to the screenshot - placing finger at point A, i.e. within the control, should move the selector (it does not and is the bug that needs fixing). However, placing finger at point B, i.e. outside of the control, should do nothing (as it currently behaves). We don't need to extend the tappable area beyond the control's borders as the control is large enough for the touch target to be the same size. Touch targets are only bigger than the visible borders of a control when the control is too small to be comfortably tapped (usually about 8-10mm) An example of this case would be the homescreen group expand/collapse arrow - here the visible control of the chevron is very small so we need to increase the touch target to improve usability. Let me know if you have further questions.
Tiffanie: thanks for explaining the rationale re: point B. I just think that people expect to "flick" stuff, and it's a pain if your finger comes down fractionally outside the area (because, perhaps, you subconsciously don't want to cover up the information) and nothing happens. Could we instead make the control span the full height of the window? There's no other UI there. Gerv
Adding Przemek who is the viz for our building blocks. Przemek - can you answer Gerv's question "Could we instead make the control span the full height of the window? There's no other UI there." Thanks!
NI Przemek based on comment 18, as it seems Tiffanie forgot to CC him. Gerv
I agree, this makes a lot of sense. This type of swipe behavior is already implemented in the new web components version of this control :)
Przemek: So does that mean this bug is a WONTFIX because this control is going to be replaced with the new one? Or does it mean we still need to fix it? Gerv
I don't think the control is broken as is and we've fixed this specific issue in the upcoming web components, so I don't feel this is something we need to fix right now.
Per Przemek comment, I set the status to be resolved with WONFIX. If any other require in this issue, feel free to reopen it. Thanks.