Closed Bug 1080827 Opened 10 years ago Closed 6 years ago

[FTU] 'Yes! Send data.' checkbox is practically impossible to check

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(tracking-b2g:backlog, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED WONTFIX
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: aus, Unassigned)

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

It's painfully frustrating trying to check the 'Yes! Send data' checkbox during the FTU process (it's on the second to last screen).

Latest Aurora (10-09-14) on Flame (v180 firmware).

This might affect all checkboxes but it's hard not to notice that one.
[Blocking Requested - why for this release]: We should make it as easy as possible for people that wish to help us by sending usage data to do so!
blocking-b2g: --- → 2.1?
Attached image yes-send-data.png
I didnt find toggling 'Send Data' that hard, I wonder if something else was going on? On this screenshot I've highlighted the <label> which is the hit area for this checkbox. It could be improved by vertically centering it - I wonder if that's what you saw?
Lets see if this is a regression and what UX thinks about it.
Flags: needinfo?(firefoxos-ux-bugzilla)
Keywords: qawanted
It does look like the hit target should be sufficient but if I try and hit the checkbox itself with my right thumb it's problematic as I often end up just a little outside of the hit area. 

I do think that centering would help as I would be stretching my finger out as much and be able to be more accurate with my pressing.
Checked the issue on Flame 2.1 and I personally feel the checkbox is NOT hard to hit.

However as comment 2 indicated, the hit area could be improved a little by moving the hit area a little to the left and perhaps raise it a little. If the user attempts to tap the checkbox a little to the left of the box then the tap will be missed.

Also checked on Flame 2.0 and Flame 2.2; I feel the hit areas are the same as in 2.1.

Device: Flame 2.1 (shallow flash)
BuildID: 20141010094605
Gaia: 656d27947b9be57f3ed29bcbb508abd64395c338
Gecko: b5d6d96fd435
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (shallow flash)
BuildID: 20141010074705
Gaia: 6effca669c5baaf6cd7a63c91b71a02c6bd953b3
Gecko: 54ec9cb26b59
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 2.2 Master (shallow flash)
BuildID: 20141010060203
Gaia: cc5da7b055e2b06fdeb46fa94970550392ee571d
Gecko: 097821fd89ed
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
I don't believe this is a regression. We can narrow down the problem (if indeed there is one, given varying experiences with this) and work on this later.
Flags: needinfo?(firefoxos-ux-bugzilla)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Thanks everyone! Lets put it in our backlog and maybe uplift if we have a patch.
blocking-b2g: 2.1? → backlog
Priority: -- → P2
Whiteboard: [systemsfe]
blocking-b2g: backlog → ---
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: