Closed
Bug 888396
Opened 11 years ago
Closed 10 years ago
Dots that indicate number of tips must not appear when there is only one tip
Categories
(Firefox Health Report Graveyard :: Web: Health Report, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: abc, Unassigned)
Details
(Whiteboard: [android][qa+])
In about:healthreport for Android, right below the tips, you have dots that indicate the number of tips. When there is only tip to show, the dots should not be shown and the rest of the content should move up accordingly.
Updated•11 years ago
|
OS: Mac OS X → Android
QA Contact: twalker
Hardware: x86 → All
Updated•11 years ago
|
Whiteboard: [android]
Updated•11 years ago
|
Whiteboard: [android] → android
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: android → [android]
Comment 1•11 years ago
|
||
Hey All, So I have a couple of questions/concerns about these dots so, 1) I have come to understand that these are not touch targets for the user but, merely a way to indicate the number of tips available to the user. Personally, I would think that users would at least attempt to use these as a way to jump between various tips. In order to do so, they would definitely have to pinch and zoom to get to each individual dot and get frustrated as tapping on the dots does nothing. I agree that we need some way to indicate to the user that there are more than one tip but, this might not be the best way. 2) There was also talk that a user will be able to swipe between tips but, this is not intuitive at all at the moment. 3) One possible solution is to make the dots actual touch target, in which case we will need to increase their size a lot to make it viable and not for the user to pinch and zoom. 4) It is also my understanding, and this is what I will open an initial pull request for today, that the tips will cycle through without the need for user intervention. My thoughts thus are: I am going to open a PR today with the tips cycling through at a steady pace of around 5 seconds per tip and remove the dots (for now), we can then iterate on this and make decisions on how the user can interact with the tips going forward. I also suggest that, we close this specific bug once my PR mentioned above is merged, and open separate bug or bugs to improve on the initial implementation. That way, we have something better then we currently have and do not block further development. Let me know your thoughts, thanks!
Comment 2•11 years ago
|
||
Sent pull request: https://github.com/mozilla/fhr-jelly/pull/131
Comment 3•11 years ago
|
||
I'm cleaning up my mail, saw reference to this bug, and I have to say that I'm fine with your suggestion (including iterating if we're finding it requires work). Ian - do you agree or have a difference stance? Obviously wouldn't make it into 23 ;-)
Flags: needinfo?(ibarlow)
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Whiteboard: [android] → [android][qa+]
Updated•10 years ago
|
QA Contact: twalker
Comment 4•10 years ago
|
||
Bumping to QA verified on dev - currently this is only one tooltip .. dots have been removed .. cycling is not present because only one tip exists.
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
Flags: needinfo?(ibarlow)
Updated•6 years ago
|
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•