Closed
Bug 825125
Opened 12 years ago
Closed 11 years ago
"Seek" buttons don't reflect seeking state
Categories
(Firefox OS Graveyard :: Gaia::FMRadio, defect)
Tracking
(blocking-basecamp:-, b2g18+ fixed)
VERIFIED
FIXED
blocking-basecamp | - |
People
(Reporter: cjones, Assigned: mihai)
References
Details
(Whiteboard: UX-P?)
Attachments
(1 file)
184 bytes,
text/html
|
timdream
:
review+
akeybl
:
approval-gaia-v1+
|
Details |
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.
Comment 1•12 years ago
|
||
Triage: BB-, tracking-b2g18+
blocking-basecamp: ? → -
tracking-b2g18:
--- → +
Updated•11 years ago
|
QA Contact: jshih → fyen
Assignee | ||
Comment 2•11 years ago
|
||
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)
Comment 3•11 years ago
|
||
Thanks Mihai, I'll discuss with the UX team today in London and we'll follow up.
Flags: needinfo?(jcarpenter)
Comment 4•11 years ago
|
||
We may be able to reuse the visual design being implemented in bug #853742 for this as well.
Comment 5•11 years ago
|
||
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)
Comment 7•11 years ago
|
||
The solution in bug #853742 (spinner) should be used here.
Depends on: 853742
Flags: needinfo?(padamczyk)
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → mihai
Assignee | ||
Comment 8•11 years ago
|
||
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.
Assignee | ||
Comment 9•11 years ago
|
||
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)
Assignee | ||
Comment 10•11 years ago
|
||
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)
Comment 11•11 years ago
|
||
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)
Assignee | ||
Comment 12•11 years ago
|
||
(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 13•11 years ago
|
||
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)
Assignee | ||
Comment 14•11 years ago
|
||
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 15•11 years ago
|
||
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+
Comment 16•11 years ago
|
||
https://github.com/mozilla-b2g/gaia/commit/b25371c8d65bb8199cd59901d79df75771762b27
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 17•11 years ago
|
||
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•11 years ago
|
Attachment #740435 -
Flags: approval-gaia-v1? → approval-gaia-v1+
Comment 18•11 years ago
|
||
Uplifted b25371c8d65bb8199cd59901d79df75771762b27 to: v1-train: 7c3d9954c998a566564d9e83d0c3441a83924f40
status-b2g18:
--- → fixed
Comment 19•11 years ago
|
||
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.
Description
•