Post Notification Emails: "Listen on Spotify" links to the post URL, not Spotify

[donalirl]

Quick summary

New post notification emails contain a "Listen on Spotify" button when the post contains a Spotify embed, but the button's link is wrong.

Steps to reproduce

1. Create a new post
2. In the body of a post, embed a Spotify link such as https://open.spotify.com/track/3C6zk9mkmv8f522AghQD9G?si=f755e920481840b0
3. Publish the post
4. Check the new post notification email sent to subscribers
5. Click on "Listen on Spotify"

What you expected to happen

I expected to be taken to spotify.com to listen to the full track.

What actually happened

The link takes the user to the post URL (where just a preview of the Spotify track is shown)

Impact

All

Available workarounds?

No but the platform is still usable

Platform (Simple and/or Atomic)

No response

Logs or notes

No response

[donalirl]

This might have been a recent change, because as recently as July 2 there was no "Listen on Spotify" button. Instead, the full Spotify URL displayed instead as per #8442801-zen

[simison]

We just implemented these audio embeds in the emails with Zap. 👋 (D152331-code)

We debated if to link to Spotify or to the post, and I wanted us to link to the post since that's where they can listen as well, have commenting available, have potentially transcript/accompanying text available, and aren't redirected outside the blog.

Similar case are YouTube video embeds.

We did leave the copy somewhat confusing though. @crisbusquets @enejb thoughts?

[github-actions[bot]]

Support References

This comment is automatically generated. Please do not edit it.

• [x] 8442801-zen

[crisbusquets]

We did leave the copy somewhat confusing though. @crisbusquets @enejb thoughts?

I agree the copy is confusing. Can we use something more generic? In Figma I had Listen to the audio in the post.

[simison]

That copy sounds good to me 👍

[enejb]

@simison and @crisbusquets I am happy to change the copy from "Listen on Spotify" to "Listen to the audio in the post" but as I understand it the user is not confused by wording but by where the link takes once they click on it.

Another problem that currently exits if we link users to just the post is that if there are multiple audio blocks that they end they have to find the audio and click on it. There are already a number of ways for the user to get to the post and experience the audio clips there so using the the audio buttons to do the same things here is not really solving the issue. IMHO I think we should link to the different sources. And provide folks with a heads up with the wording such as "Listen on Spotify" that they will be take to Spotify or a different service that the URL might take them to. This will give the readers the choice how they want to experience the audio piece.

[donalirl]

Listen to the audio in the post

Something to consider here is that the Spotify embed in the post will only play a short preview of the audio (I think 30 seconds), not the full audio. The user then needs to visit Spotify to hear the audio in full.

So if the user's goal is to listen to the audio, they'll have extra clicks with the current flow: email → post → spotify If the button says "Listen to the audio in the post", it could be seen as misleading since they can't listen to the full audio in the post.

If you decide to keep the button linking to the post, then I feel button copy like "View post" will be the clearest.

Or if you decide to link the button to the Spotify URL, then the current "Listen on Spotify" copy will be the clearest.

[crisbusquets]

So if the user's goal is to listen to the audio, they'll have extra clicks with the current flow: email → post → spotify If the button says "Listen to the audio in the post", it could be seen as misleading since they can't listen to the full audio in the post.

Thanks for the input, @donalirl. This is aligned with the approach @enejb shared above. It works for me, as long as the copy is clear and people know where they're going to land.

[simison]

Yeah, came from disconnect between the copy & action — and thanks for noting the "preview" nature of spotify embeds, makes sense now. 👍

[simison]

This will give the readers the choice how they want to experience the audio piece.

Right, I was thinking more about the publisher who decided to embed content on their blog rather than link elsewhere, but it really depends on nature of embedded service like seen with this Spotify example. 🙂

[crisbusquets]

I'd say we do what @donalirl suggested (for example, if it's a Spotify embed, open Spotify) and keep track of tickets to see if site/newsletter owners have something to say. WDYT?

[enejb]

A fix for this was shipped! cc @donalirl in case you want to let the user know.