If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED WONTFIX

Status

Firefox OS
Gaia::System::Window Mgmt
RESOLVED WONTFIX
5 years ago
2 years ago

People

(Reporter: gerv, Assigned: iliu@mozilla.com, ianliu.moz@gmail.com)

Tracking

({b2g-testdriver, polish, unagi})

unspecified
b2g-testdriver, polish, unagi

Firefox Tracking Flags

(blocking-basecamp:-)

Details

(Whiteboard: interaction desgin)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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
(Reporter)

Updated

5 years ago
Duplicate of this bug: 819989

Updated

5 years ago
Component: Gaia → Gaia::System
Triage: BB-
blocking-basecamp: ? → -
Keywords: polish
Whiteboard: interaction desgin
(Assignee)

Updated

4 years ago
Assignee: nobody → iliu
It would be nice if we could get opinion from UX before investing time to work to work on it.
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 4

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

Updated

4 years ago
Duplicate of this bug: 808642

Comment 6

4 years ago
Reassigning to Casey. Blockers still take UX precedence.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(kyee)

Comment 7

4 years ago
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?!)
Flags: needinfo?(kyee)

Updated

4 years ago
Component: Gaia::System → Gaia::System::Window Mgmt
UX, last comment was >1yr ago, can you review for relevance?
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 9

3 years ago
I don't believe this is relevant based on UI changes in the past year.
Flags: needinfo?(firefoxos-ux-bugzilla)
(Reporter)

Comment 10

3 years ago
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
Flags: needinfo?(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?
Flags: needinfo?(dietrich) → needinfo?(firefoxos-ux-bugzilla)

Comment 12

3 years ago
Sorry, I cannot repro this on my end, on 2.2. Flagging Rob to see if he can assist here.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(rmacdonald)
(Reporter)

Comment 13

3 years ago
(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
(Reporter)

Updated

3 years ago
Flags: needinfo?(swilkes)

Comment 14

3 years ago
I mean I don't think I can literally see what you're describing. But, scrolling is Rob's area anyway.
Flags: needinfo?(swilkes)
(Reporter)

Comment 15

3 years ago
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.
Flags: needinfo?(rmacdonald)
(Reporter)

Comment 17

3 years ago
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!
(Reporter)

Comment 19

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

Gerv
Flags: needinfo?(pabratowski)
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 :)
Flags: needinfo?(pabratowski)
(Reporter)

Comment 21

2 years ago
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
Flags: needinfo?(pabratowski)
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.
Flags: needinfo?(pabratowski)
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.