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)

All
Android
defect
Not set
normal

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.
OS: Mac OS X → Android
QA Contact: twalker
Hardware: x86 → All
Blocks: 888408
Blocks: 888410
Blocks: 888417
Blocks: 888421
Blocks: 888422
Blocks: 888431
Blocks: 888434
Blocks: 888438
Blocks: 888440
Blocks: 892072
Whiteboard: [android]
Whiteboard: [android] → android
Blocks: 897526
Blocks: 897529
No longer blocks: 897529
No longer blocks: 888440
No longer blocks: 888434
No longer blocks: 897526
No longer blocks: 892072
No longer blocks: 888421
No longer blocks: 888410, 888408, 888417, 888422, 888431, 888438
No longer depends on: 888382
Whiteboard: android → [android]
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!
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)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [android] → [android][qa+]
QA Contact: twalker
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
Flags: needinfo?(ibarlow)
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.