dotcom-rendering
dotcom-rendering copied to clipboard
Today in Focus
The Today in Focus
podcast container is special and has its own layout. This is passed to DCR as a normal container but gets rendered differently. How is this variation from the model decided?
How is Listen to Previous episodes entered?
Right now in DCR this renders as
Comment from Harry:
When you build the podcast (Today in Focus) container please see new design here: Mobile: https://www.figma.com/file/5CfbWOeZPRi15lXBD5u1rW/Card-layout-system?node-id=165%3A4437 Desktop: https://www.figma.com/file/5CfbWOeZPRi15lXBD5u1rW/Card-layout-system?node-id=165%3A3979
These changes are due to the current buttons not being in Source
URLs Apple: https://podcasts.apple.com/gb/podcast/today-in-focus/id1440133626?mt=2 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly93d3cudGhlZ3VhcmRpYW4uY29tL25ld3Mvc2VyaWVzL3RvZGF5aW5mb2N1cy9wb2RjYXN0LnhtbA== Spotify: https://open.spotify.com/show/2cSQmzYnf6LyrN0Mi6E64p Amazon Music: https://music.amazon.co.uk/podcasts/36dd85f2-afab-4d2e-8701-431133c77f01/today-in-focus
Listen to previous episodes: https://www.theguardian.com/news/series/todayinfocus
we need an approach forward
Currently this container is rendered via a bespoke template (I don't think it's used for anything else?) called flagshipContainer
.
It looks like we check the container id against a hard-coded list of ids in Frontend, to decide whether a collection should be rendered in this container:
https://github.com/guardian/frontend/blob/e9b68762e57a98602c0647535d9bb6ba9a13d3e2/common/app/conf/audio/FlagshipFrontContainer.scala#L6-L12
This flagship container is enabled by a switch which was added in 2018 (the file itself hasn't been edited since 2020). It would be good to know whether this switch is needed anymore -- is it ever switched off?
The switch is listed as being owned by the 'journalism team', but I'm not sure whether that team still exists. Do you know who ownership of this might sit with now @rhiannareechaye or @jamesgorrie ?
Comment from Harry:
When you build the podcast (Today in Focus) container please see new design here: Mobile: figma.com/file/5CfbWOeZPRi15lXBD5u1rW/Card-layout-system?node-id=165%3A4437 Desktop: figma.com/file/5CfbWOeZPRi15lXBD5u1rW/Card-layout-system?node-id=165%3A3979
These changes are due to the current buttons not being in Source
@HarryFischer are the new designs in the figma files linked above still the correct designs that we should be creating in DCR, or should we follow the current Frontend design?
Update on this issue:
- We've got more context on the switch. From what we can tell it looks like this could be deprecated and then removed. The container can be added and removed in the Fronts tool like any other container.
- The current draft designs diverge from the figma designs above, in discussion with @HarryFischer. This is partly due to changes in the general card layout (e.g. kickers) since those designs were made. In addition, Harry and I have been exploring whether we can avoid adding too much custom styling to the first card in the desktop design, by using DCR's existing card picture settings. Harry's going to discuss the new design with Alex B soon so it makes sense to pause the work until that's happened. I should be back from annual leave by then, too.
Design team doesn't currently have capacity to review updated designs, so I'm putting this on hold for the time being. I'll plan to check in with them again when they have more capacity.
I do have a branch which implements a certain amount of the functionality that we need. So if someone else picks this up in the future please reach out and I can share what I've got.
We've also been asked to make it so that the icon colour on media cards picks up the pillar colour even when there's no kicker on the card; could be done as part of this ticket?
@HarryFischer aware you're stacked at the moment, but just putting this with you for when you have capacity
@bryophyta thank you for gathering all this info! I'm just looking at picking up this work, is there any existing PR I may have missed?
@alinaboghiu I did make a start on a branch but to be honest I think you'd be better off starting fresh because it's using some patterns that are out of date with the main branch now, and iirc there was a plan to revisit the design a bit to see whether it could be brought more into line with card/container layouts that we use elsewhere (though I'm not sure what the status of that discussion is -- I believe that @HarryFischer has spoken to Alex B about it?)
Could we suggest to editorial whether they might want to use a normal container instead? There is an example on this code front: https://m.code.dev-theguardian.com/uk#today-in-focus
The main difference is that the links to Amazon/Apple etc are provided as treat so they do not appear below tablet breakpoint.
The main difference is that the links to Amazon/Apple etc are provided as treat so they do not appear below tablet breakpoint.
On that topic, do we know what the reasons are for not showing treats on mobile? I'm guessing it would require a proper design process to roll it out to all containers, but we could add an option for FrontSection
to show treats on mobile which would just be activated for this container to start off with (the podcast container already requires some custom logic). I don't feel great about the idea of adding a new option to FrontSection
just for this case, but I spent 10 mins seeing what it would involve and it looks like it wouldn't actually add that much extra code (though it would require more design effort than I put in below!)
Just a thought really :)
This is a very good question and a very good idea. Presumably if someone has gone through the effort of adding treats it's worth displaying them on mobile?
Worth remembering there are also treats that appear as badges (e.g. US headlines https://www.theguardian.com/us?INTCMP=CE_US)
Maybe we could see what @HarryFischer and @ajbreuer think about this?
As for the use of FrontsContainer we could potentially use the podcast palette to only roll it out to podcasts to begin with. Not a great use of palette but if we wanted to roll it out to all containers eventually then it could work.
But in general I think using a real container that they can edit in the fronts tool as and when they wish to is much better than having to edit a thrasher every time (and finding a person who knows how to do so).
on app is a carusel of podcast - which does not show only today in focus - ideal would be carusel so that it looks in App - buttons can be v2 - investigate how much work
I am reopening this issue.
The update is:
- We went live to 1% of Fronts with a new podcast container. This replaced the Today in Focus container and the old podcast container.
- There is a slight issue with the container we are live with right now - it only shows 4 cards
- We have a solution which is to use the 'fixed video container' for podcasts, but if we implement this solution while we're still rolling out network fronts, it will appear on Frontend, and the new fixed video container isn't supported on Frontend
Therefore our priority when we've rolled out to 100% is to swap the containers over
@alinaboghiu not sure I've got all this correct - my brain is tired of github today, would you mind correcting anything I've got wrong?
To do immediately after 100% launch
Email CP and ask them to:
- Make changes to the podcast container
- Delete the web podcast container
- Change the 'app only' container to be on both web and app
- Change the 'app only' container to use the 'slow 7' type and add the podcast label
- NOTE: We must keep using the app-only container as we need to make sure this container retains some logic within the app
ensure Alex B, Jonathan Haynes, @tkgnm @DavidLawes @alinaboghiu @jamesgorrie are cc'd + Petter
7 cards are now displaying on both web and app with the same container so I am closing this issue