820003 - Time picker: should be grabbable in space "beyond" list

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Gervase Markham [:gerv]]

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

Comment 2

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB-

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

It would be nice if we could get opinion from UX before investing time to work to work on it.

Comment 4

[Stephany Wilkes]

UX will tackle this, but it has to come after all leo+, tef+ and tracking work, which are our top priorities right now.

Comment 6

[Stephany Wilkes]

Reassigning to Casey. Blockers still take UX precedence.

Comment 7

[Casey Yee]

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?!)

Comment 8

[Dietrich Ayala (:dietrich)]

UX, last comment was >1yr ago, can you review for relevance?

Comment 9

[Stephany Wilkes]

I don't believe this is relevant based on UI changes in the past year.

Comment 10

[Gervase Markham [:gerv]]

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

Comment 11

[Dietrich Ayala (:dietrich)]

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?

Comment 12

[Stephany Wilkes]

Sorry, I cannot repro this on my end, on 2.2. Flagging Rob to see if he can assist here.

Comment 13

[Gervase Markham [:gerv]]

(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

Comment 14

[Stephany Wilkes]

I mean I don't think I can literally see what you're describing. But, scrolling is Rob's area anyway.

Comment 15

[Gervase Markham [:gerv]]

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

Comment 16

[Tiffanie Shakespeare [:tif]]

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.

Comment 17

[Gervase Markham [:gerv]]

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

Comment 18

[Tiffanie Shakespeare [:tif]]

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!

Comment 19

[Gervase Markham [:gerv]]

NI Przemek based on comment 18, as it seems Tiffanie forgot to CC him.

Gerv

Comment 20

[Przemek Abratowski [:przemek] UX]

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

Comment 21

[Gervase Markham [:gerv]]

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

Comment 22

[Przemek Abratowski [:przemek] UX]

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.

Comment 23

[[e-mail], [e-mail]]

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.