bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

"Seek" buttons don't reflect seeking state

VERIFIED FIXED

Status

Firefox OS
Gaia::FMRadio
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: cjones, Assigned: mihai)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:-, b2g18+ fixed)

Details

(Whiteboard: UX-P?)

Attachments

(1 attachment)

If you press a seek button in the radio app, there's a pretty subtle dancing-dots indicator under the station name that's easy to miss.  At least, I missed it for a while.

Seeking the radio can take a while, so only a few pixels in the UI will change in that time.  If the user misses the indicator, they might think that the radio is wedged and go into USER-SMASH-BUTTONS mode.  At least, I did.

So it might be a good idea to make the seek indicator less subtle, or disable the seek buttons while the operation completes in the radio hw.

bb? to get on radar.
Triage: BB-, tracking-b2g18+
blocking-basecamp: ? → -
tracking-b2g18: --- → +

Updated

6 years ago
QA Contact: jshih → fyen
Is someone working on this bug?

I am looking to take it, but first, can I get more details on the intended behavior: should the seek buttons be disabled while seeking? or should the "dancing-dots" be enlarged to make them less subtle?
Flags: needinfo?(jcarpenter)
Flags: needinfo?(cjones.bugs)
Thanks Mihai, I'll discuss with the UX team today in London and we'll follow up.
Flags: needinfo?(jcarpenter)
We may be able to reuse the visual design being implemented in bug #853742 for this as well.
Casey, I seem to recall that you worked on this with the dev team?
Flags: needinfo?(cjones.bugs) → needinfo?(kyee)

Comment 6

5 years ago
I agree that there needs to be a more obvious way to show that the radio is seeking a station.

Using something a little more obvious than the ". . ." would make sense.    As suggested in Comment 4, we could re-use the spinner in bug #853742.

Patryk, and thoughts?
Flags: needinfo?(kyee) → needinfo?(padamczyk)
The solution in bug #853742 (spinner) should be used here.
Depends on: 853742
Flags: needinfo?(padamczyk)
(Assignee)

Updated

5 years ago
Assignee: nobody → mihai
Thanks Patryk, I will wait for the patch for Bug 853742 (which hopefully adds the spinner, as detailed in the posted mockups) before working on this bug.
Created attachment 740435 [details]
Pull Request #9346 - Change seeking state UI to use spinners

Use the spinner introduced in Bug 853742 to reflect the seeking state:
* seek-up: rotates the spinner in clockwise direction
* seek-down: rotates the spinner in counter-clockwise direction
Attachment #740435 - Flags: review?(timdream)
Patryk, is the behavior highlighted in comment 9 (i.e. spinner rotation determined by seeking direction) the desired one for reflecting the seeking state?
Flags: needinfo?(padamczyk)
The direction should be clockwise only. 

Its a shame we have delay, ideally with better hardware this will go away, I really hope the user doesn't need to wait so long that he has to ponder whether he pressed the right "seek" direction.
Flags: needinfo?(padamczyk)
(In reply to Patryk Adamczyk [:patryk] UX from comment #11)
> The direction should be clockwise only. 
> 
> Its a shame we have delay, ideally with better hardware this will go away, I
> really hope the user doesn't need to wait so long that he has to ponder
> whether he pressed the right "seek" direction.

Thanks for the feedback, Patryk, I updated the patch accordingly. Now, regardless of which seek direction button is pressed, the spinner rotates only clockwise.

Tim, feel free to look over the patch whenever you have the time, thanks!
Comment on attachment 740435 [details]
Pull Request #9346 - Change seeking state UI to use spinners

There are two CSS questions that I don't know why you write it this way.

Overall it looks good though.
Attachment #740435 - Flags: review?(timdream)
Comment on attachment 740435 [details]
Pull Request #9346 - Change seeking state UI to use spinners

Thanks for the comments, Tim! I replied on GitHub and updated the pull request. Feel free to merge it if it looks good now.
Attachment #740435 - Flags: review?(timdream)
Comment on attachment 740435 [details]
Pull Request #9346 - Change seeking state UI to use spinners

https://github.com/mozilla-b2g/gaia/pull/9346#r3954901

Fix that and you are good to go :) Thanks!
Attachment #740435 - Flags: review?(timdream) → review+
https://github.com/mozilla-b2g/gaia/commit/b25371c8d65bb8199cd59901d79df75771762b27
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Comment on attachment 740435 [details]
Pull Request #9346 - Change seeking state UI to use spinners

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): FM Radio > seeking
User impact if declined: Low (seeking state might not be noticeable to the user)
Testing completed: Yes
Risk to taking this patch (and alternatives if risky): Low/None (depending patch for bug 853742 is already uplifted to v1-train)
String or UUID changes made by this patch: No
Attachment #740435 - Flags: approval-gaia-v1?

Updated

5 years ago
Attachment #740435 - Flags: approval-gaia-v1? → approval-gaia-v1+
Uplifted b25371c8d65bb8199cd59901d79df75771762b27 to:
v1-train: 7c3d9954c998a566564d9e83d0c3441a83924f40
status-b2g18: --- → fixed
Unagi
Gaia:     186d31782d8cadb296661a7d104bc28846d1dfb9
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18/rev/66334a3bddcb
BuildID   20130508070204
Version   18.0

Verified base on comment 11.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.