Please report any other irregularities here.
184 bytes, text/html
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: --- → +
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?
Thanks Mihai, I'll discuss with the UX team today in London and we'll follow up.
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)
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
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
Patryk, is the behavior highlighted in comment 9 (i.e. spinner rotation determined by seeking direction) the desired one for reflecting the seeking state?
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.
(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.
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.
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+
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?
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.