Closed Bug 868549 Opened 7 years ago Closed 4 years ago
[Music] Add right to left marquee for song title in title bar
As discussed in the comments of bug 823815 (starting from comment 5), the Music App should display the title bar song titles using a slow right to left marquee that starts aligned left, with a couple of seconds delay (cf. specs, page 3: https://www.dropbox.com/s/bffq8vbh3eo5iaf/B2g-music-v4.pdf). This way, song titles that overflow the title bar width will not be truncated anymore.
Comment on attachment 745305 [details] Pull Request #9460 - Right to left marquee Updated the patch to have the marquee animation start aligned left with a couple of seconds delay, as suggested. Rob, can you have a look at this patch and let me know what changes would still be required? A couple of things would need your attention: 1. animation timings: how long the marquee animation should take, including how long the start delay should be? (NOTE it has two parts: marquee-start -- the aligned left: translateX from 0% to -100%; and marquee -- aligned right: translateX from titleBarWidth to -100%) 2. displayed title at start of marquee: the delayed animation start means that a truncated title would be displayed; for now, there is no ellipsis displayed (i.e. '...' at the end of the visible title) since the marquee CSS updates overwrite the 'text-overflow: ellipsis' rule. Should I find a way to display the ellipsis, or is the truncated text fine? 3. animation performance: although I made sure to use efficient CSS animations (cf. details in bug 823815 comment 12), because of low-end hardware on unagi, I sometimes observe non-smooth marquee scrolling when the song is playing. Let me know what you think about this? Unfortunately, there isn't much to be done here since it is highly hardware dependent.
Please find below a link to a video clip showing the marquee in action on an unagi device: http://youtu.be/sUg-MLD3RhU Throughout the video you will notice my observations from comment 2 point 3. about the performance of the animation, as well as how the song title looks truncated at the start of the marquee (point 2. from earlier comment).
Comment on attachment 745305 [details] Pull Request #9460 - Right to left marquee Hi Mihai... Thanks for going above and beyond and for keeping us in the loop on this one. I shared the video with a few of my colleagues and unfortunately the performance of the animation on the current hardware is too choppy to be shipped in our view. The speed of animation and the timing are great, though, so hopefully we can use this in future releases. - Rob
Attachment #745305 - Flags: feedback?(rmacdonald) → feedback-
I forgot to add, the backup plan is the one I described in bug 823815 (comment 13). Please don't hesitate to flag me if you have additional questions or concerns. - Rob
Thanks for all the feedback, Rob, I will leave this bug open for consideration in future releases. If anyone else has suggestions on how to improve the implementation for better performance, feel free to post in this discussion.
Perhaps use the marquee tag?
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #7) > Perhaps use the marquee tag? Hi Martijn, thanks for pointing this out, I did consider using the marquee tag initially, however it is a non-standard HTML tag (proprietary to Internet Explorer) that W3C advises against (cf. http://www.w3.org/wiki/HTML/Elements/marquee). However, there is effort to include a 'marquee' property in CSS3 'overflow-style': http://www.w3.org/TR/css3-marquee/ which I believe is not implemented yet. This would for sure simplify things.
The marquee element is implemented as an xbl binding. It's using a script to change the scrollLeft property of and inside element. I guess you could make something similar if you don't want to use the marquee element itself.
The audio element listens to timeupdate event for updating the position on seek bar. And the timeupdate event will fire about every 250ms, it means when Music app is playing, the seek area will be constantly updating, includes: 1. the text(MM:SS) of elapsed/remaining times - <span>, using textContent 2. the seek position - <progress>, using value 3. the indicator(the round white ball) of seek bar - <div>, using translateX These four elements update at the same time so I think this is already a heavy work for UI, that might be why we can't get a smooth marquee when music is playing. And now if we want to add text marquee in Music app, the UI will be always busy because marquee is a looping animation and there is no chance for UI to stop repainting. We need to also consider the power consumption on our device, there are bugs talking about it, please see bug 836214, I don't know how much power the marquee animation will cost but I am sure not only the power when the screen is turned off we need to care, but also the screen is turned on. If we do want to display the song title without truncating, I really hope we can have an alternative design instead of the marquee animation, according to the reasons I mentioned above, thanks.
using FxOS as default music player is painful with this bug. i'd rather move forward with some fix, than leave it as is. bug 836214 turned out to be because app didn't turn off it's visibility when screen was off (afaict). and if we can't do things like scrolling text without killing the device, then we need to file a platform bug. we can't say "use the web platform because it's powerful... except please don't scroll text".
(In reply to Mihai Cirlanaru [:mihai][:mcirlanaru] from comment #8) > However, there is effort to include a 'marquee' property in CSS3 > 'overflow-style': http://www.w3.org/TR/css3-marquee/ which I believe is not > implemented yet. This would for sure simplify things. Using CSS's marquee and, in particular, marquee-direction would have the benefit of ensuring the correct direction of the animation for RTL languages. Do you know how far are we from implementing it in the platform?
Whiteboard: visual design UX-P? hanzo → visual design UX-P? hanzo [rtl-platform]
Flagging Jacqueline to see if this is still relevant given the changes to music in the past six+ months. If not we can resolve invalid.
With the new design I believe we are not including the title of the song in the header, so there will be more room for the song title. However, this may still be necessary for very long titles. We are still currently concepting the visuals for the Now Playing screen, I will follow up after the final design is complete to see if this is still necessary.
Resolving invalid to be superseded by 2.2 work that will have RTL specs.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Please don't close the bug until that work exists, or you at least have a new bug to dupe it against. Even then, "invalid" isn't the right way to treat this. Also, just to clarify: usually "RTL" is about something different - are you talking specifically about a music marquee feature in 2.2?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
There is no more marquee in the UI, so there is no marquee to file RTL support against. There will be other RTL work for Music for 2.2, but there will be no marquee involved.
Whiteboard: visual design UX-P? hanzo [rtl-platform] → visual design [rtl-platform]
Still seeing truncation of the song title in the titlebar in 2.2 - see attached screenshot. Also see it in mix page, etc. Mihai, this bug is pretty specific to the scrolling marquee approach to solving the problem. It also has been associated with RTL bugs, which is causing confusion. I was going to change the title of this bug to be about the problem instead of the solution, but this bug is pretty far along to do that. Instead, I'm going to file a separate bug to be about the inability to see a whole song title, regardless of language direction and with no prescribed solution. See bug 1071962.
Whiteboard: visual design [rtl-platform] → visual design [rtl-platform] polish
Whiteboard: visual design [rtl-platform] polish → visual design [rtl-platform]
> Instead, I'm going to file a separate bug to be about the inability to see a > whole song title, regardless of language direction and with no prescribed > solution. See bug 1071962. Was duped to bug 908222.
Marking duplicate. This is still a valid bug, but the patch is badly bitrotted, and it's not 100% clear that this is the direction we'd take anyway.
Status: REOPENED → RESOLVED
Closed: 5 years ago → 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 908222
You need to log in before you can comment on or make changes to this bug.