868549 - [Music] Add right to left marquee for song title in title bar

Status: RESOLVED DUPLICATE of bug 908222

(Firefox OS Graveyard :: Gaia::Music, defect)

Description

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

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 1

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Attachment: Pull Request #9460 - Right to left marquee

Partial implementation of the marquee, starting aligned right, using CSS animations with a bit of JavaScript to dynamically set the width of the marquee (based on the length of the song title).

This patch will be extended to have the marquee start aligned left with a delay of a couple of seconds.

Comment 2

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

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.

Comment 3

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

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 4

[Rob MacDonald [:robmac]]

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

Comment 5

[Rob MacDonald [:robmac]]

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

Comment 6

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

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.

Comment 7

[Martijn Wargers (dead)]

Perhaps use the marquee tag?

Comment 8

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

(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.

Comment 9

[Martijn Wargers (dead)]

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.

Comment 10

[Dominic Kuo [:dkuo]]

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.

Comment 11

[Dietrich Ayala (:dietrich)]

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".

Comment 12

[Staś Małolepszy :stas]

(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?

Comment 13

[Stephany Wilkes]

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.

Comment 14

[Jacqueline Savory [:jsavory] UX]

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.

Comment 15

[Stephany Wilkes]

Resolving invalid to be superseded by 2.2 work that will have RTL specs.

Comment 16

[Dietrich Ayala (:dietrich)]

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?

Comment 17

[Stephany Wilkes]

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.

Comment 18

[Dietrich Ayala (:dietrich)]

Attachment: screenshot of truncated title in 2.2

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.

Comment 19

[Dietrich Ayala (:dietrich)]

> 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.

Comment 20

[Jim Porter (:squib)]

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.