Post ArUUSYdoOnOLEZqaxM by StevenB@podcastindex.social
(DIR) More posts by StevenB@podcastindex.social
(DIR) Post #ArSQzRJViMr9qb31hQ by dave@podcastindex.social
2025-02-24T22:38:24Z
0 likes, 0 repeats
#namespace Banners:There is a clear desire for a way to specify banner art in a podcast RSS feed. I'm going to try and sum up where things are currently at.
(DIR) Post #ArSRVsP2X7BF866L0y by dave@podcastindex.social
2025-02-24T22:44:18Z
0 likes, 0 repeats
<media:thumbnail>@james advocates for using a 1280x720 <media:thumbnail> tag for this purpose because YouTube ingests this already as a wide art. The spec is here:https://www.rssboard.org/media-rss#media-thumbnailsPro's: - YouTube- ExistsCon's:- Banners aren't the intended purpose of this tag by either the spec or YouTube. It's meant to be a thumbnail.- Stuck to 1280x720 to be recognized as a banner, but most banners are 3:1 aspect ratio, like Bluesky (2048x512).
(DIR) Post #ArSS0y7JL2aBpQdP3Q by dave@podcastindex.social
2025-02-24T22:49:55Z
0 likes, 0 repeats
<podcast:banners> + <podcast:banner>@russell ran with scissors and is already using this tag in the feeds of his hosting platform PodToo.Pro's:- In use already- Clear intent- Has aspect ratio and other hint attributesCon's:- No `width` or `height` attributes- Uni-tasker
(DIR) Post #ArSSIq93iSKqJhyRbk by russell@podcastindex.social
2025-02-24T22:53:09Z
0 likes, 0 repeats
@dave we can add with and height no issues and as it’s not an approved spec I can have that working in 10min without breaking anyone’s apps 😀
(DIR) Post #ArSSVoYivMaTA8AIEa by dave@podcastindex.social
2025-02-24T22:55:29Z
0 likes, 0 repeats
<podcast:images> (with enhancements)@nathan Proposed a set of enhancements to <podcast:images> to add the missing attributes being needed.Pro's:- Multi-tasker tag- Has width/height- Very expandableCon's:- Not in use anywhere- People hate the stink of <podcast:images> 😆
(DIR) Post #ArSSm9rBVWGFqjaq9I by dave@podcastindex.social
2025-02-24T22:58:27Z
0 likes, 0 repeats
I hope this sums up where we are at fairly too all involved.Feedback welcome.
(DIR) Post #ArSWkKTrR9c02J4EKW by russell@podcastindex.social
2025-02-24T23:42:54Z
0 likes, 0 repeats
@dave I can't exactly recall which episode it was, but you said it best in that episodes something along the lines of "they both work" so maybe the solution is they both get added, and then the developers and hosts can choose which one that they want to support.App developers could check for <podcast:images /> first and then if not found, check if the feed for <podcast:banners>+</podcast:banners>it's really just a if/else statement - isn't?
(DIR) Post #ArSo18hsAEb1fCDrPc by james@bne.social
2025-02-25T02:56:24Z
0 likes, 0 repeats
@dave This is an incorrect take on my views. I advocate for using media:thumbnail for additional images, in whatever size. We should settle on a set of suggested sizes, and I would suggest we review existing artwork out there, particularly Apple Podcasts’s spec which has a number of different sizes. They aren’t programmatically available in the RSS feed, but no reason why they shouldn’t be. Use of image sizes (and declaring them) means clients can calculate aspect ratios and can make a decision on whether to crop/resize. YouTube supports a size of 1280x720. That’s up to YouTube, but we’d be foolish to ignore the fact that this size may be created by many publishers.Benefits: exists. Used. And fit for purpose since it clearly defines the size and aspect ratios of the images.
(DIR) Post #ArStsWBc65ivbSPE4u by StevenB@podcastindex.social
2025-02-25T04:02:08Z
0 likes, 0 repeats
@dave @nathan I like this one. I like being expandable. I worry that it becomes too expandable, thus complicated and difficult to implement, sort of like socialInteract.
(DIR) Post #ArSu8eIFitDVNdCeGG by StevenB@podcastindex.social
2025-02-25T04:05:03Z
0 likes, 0 repeats
@dave @russell I also like this one. I tend to prefer uni-taskers over multi-taskers. This one clearly defines what it does and is focused on a single goal. If we want heros, thumbnails, social, canvas, etc, it could be a 'purpose' attribute like in @nathan fine proposal, but that can get complicated quick. Having a separate tag for each purpose feels cleaner to me, but I'm cool either way.
(DIR) Post #ArTmqUxDMZ1klXWoGe by james@bne.social
2025-02-25T02:59:17Z
0 likes, 0 repeats
@dave … and to add, media:thumbnail is just a name, and “it’s just for thumbnails” is a peculiar criticism from someone who has spent the last five years saying that names of tags don’t matter!
(DIR) Post #ArTmqVWfElNqXU77WS by dave@podcastindex.social
2025-02-25T14:18:01Z
0 likes, 0 repeats
@james I'm not basing the use on the name of the tag. I'm basing it on the language of the spec:"Allows particular images to be used as representative images for the media object." That means thumbnail image. Using if for other image types is a hijack of the spec.
(DIR) Post #ArTn7YAYf6kff0ttJY by dave@podcastindex.social
2025-02-25T14:20:55Z
0 likes, 0 repeats
@james Are you saying that `<media:thumbnail>` is the tag you think should be used for all images that are not the standard, square channel art?
(DIR) Post #ArTpk9nRPgoBGtcn0y by russell@podcastindex.social
2025-02-25T12:34:22Z
0 likes, 0 repeats
@StevenB @dave @nathan Out of interest would you like purpose in the podcast:banners tag? as we can add that too :)
(DIR) Post #ArTpkANxDw1168hwvY by StevenB@podcastindex.social
2025-02-25T13:42:36Z
0 likes, 0 repeats
@russell @dave @nathan I don't think it's necessary. It's purpose of being a banner is very clearly defined.
(DIR) Post #ArTpkAyp0rVQwTxOOO by StevenB@podcastindex.social
2025-02-25T13:44:27Z
0 likes, 0 repeats
@russell @dave @nathan I know some people don't like to 'clutter' the namespace with a bunch of tags, but I have a unique perspective in that I build both hosting and playing apps.A multi-purpose tag is very difficult to create a good UX around because the logic of it is quite complicated. If it's too difficult, the hosts won't build for it because they have limited coding time and resources.A think a more simple tag will see wider adoption.
(DIR) Post #ArTpkBRtGml4OdYbhY by russell@podcastindex.social
2025-02-25T13:50:51Z
0 likes, 0 repeats
@StevenB @dave @nathan Thank you and that is how I felt as well.
(DIR) Post #ArTpkBzvEFyq6BTmkK by StevenB@podcastindex.social
2025-02-25T13:53:46Z
0 likes, 0 repeats
@russell @dave @nathan That's not to say I'm against modifying podcast:images, I think it's good path to take, but if we're voting, my vote is with podcast:banner and keeping it simple and later creating more uni-tasker image tags if we need them.
(DIR) Post #ArTpkCV7MGvxew4hN2 by dave@podcastindex.social
2025-02-25T14:50:25Z
0 likes, 0 repeats
@StevenB @russell @nathan Good points.
(DIR) Post #ArTs5vgsjrmbno4Aa0 by dave@podcastindex.social
2025-02-25T15:16:49Z
0 likes, 0 repeats
@StevenB @russell @nathan Is there a functional difference between <podcast:banner> and <podcast:images purpose='banner'> ?I'm hearing your concern about a tag being so flexible that it's very hard to fully support. But, I also see that it's not much different than an <enclosure> with a `type` you can't handle. You just ignore the ones you can't do?
(DIR) Post #ArTt3kKS6ufFwJ683c by StevenB@podcastindex.social
2025-02-25T15:27:40Z
0 likes, 0 repeats
@dave @russell @nathan I thought about that, and as a feed builder, the UX for banner could be simple and just build the tag with the elements needed for a banner. As a playing app, parsing it out is more difficult, because I parse the tag, then have to filter for the purpose I'm looking for, and in some feeds it may not have the purpose I'm looking for.And I think purpose would have to be required so the apps could easily find the purposes they're looking for.
(DIR) Post #ArU1SuPeYU385S2XC4 by StevenB@podcastindex.social
2025-02-25T15:32:09Z
0 likes, 0 repeats
@dave @russell @nathan Also, Nathan's tag is much more complicated than just purpose.It's got multiple purposes, multiple aspect ratios, multiple types, multiple srcsets. My concern is that it's so open ended that figuring out what it does becomes confusing, especially with so much of it being optional.
(DIR) Post #ArU1SvNYxjyJ5G4NZg by StevenB@podcastindex.social
2025-02-25T15:33:52Z
0 likes, 0 repeats
@dave @russell @nathanI think one way it could be simplied is to do away with either purpose or aspect-ratio, and have in the specs something like "A purpose of banner will always be an aspect ratio of 7:1" or vice versa. Also, make purpose or aspect-ratio required, and if we're going to have mime/type, make that required as well. As an app dev, if I don't support video, I'd want to be able to easily figure out if this tag serves my desired purpose.
(DIR) Post #ArU1SvzUgiJSytofhI by StevenB@podcastindex.social
2025-02-25T15:36:50Z
0 likes, 0 repeats
@dave @russell @nathanI lean towards having only purposes with very defined aspect ratios, and the apps know if the purpose is 'artwork' then they can safely put that in a 1:1 square and not have to also figure out if the aspect ratio of the 'artwork' works with their apps design.
(DIR) Post #ArU1Swb4R0N2rROgGe by nathan@xoxo.zone
2025-02-25T15:43:50Z
0 likes, 0 repeats
@StevenB @dave I think I need to start providing sample UX implementations for my proposals because bc they’re written with the assumption that app/host devs will only implement the parts that serve their interests.In my mind, each "use case" warrants its own UI, and doesn’t require some some complex ~image tag builder wizard~.
(DIR) Post #ArU1SxGXwnY0w4nnuq by nathan@xoxo.zone
2025-02-25T15:43:59Z
0 likes, 0 repeats
@StevenB @dave EpisodesFM generates landscape social preview images for every show/episode. I could choose to prioritize feed-provided social media images when present.The bare minimum a host would need to participate would be an image upload field labeled "Social Preview Image" that appends an image with purpose="social" no need to handle aspect-ratios, srcset, type.
(DIR) Post #ArU1Sxy9KgQT7JCcsa by StevenB@podcastindex.social
2025-02-25T16:07:14Z
0 likes, 0 repeats
@nathan @dave I think my main concern is the paradox of choice. When we're given too many choices, we end up in this analysis paralysis. I think part of why some tags aren't widely supported is because they do so much that people just give up. It's not that it's a bad tag, it's that we're all so very busy and overwhelmed and don't have the mental space to figure out how and when to make something work. I have a gut feeling that removing choices would make devs happier.
(DIR) Post #ArU1SyRDabg6ZSnqBk by StevenB@podcastindex.social
2025-02-25T16:12:38Z
0 likes, 0 repeats
@nathan @dave And again, I like your tag, it's well thought out and the documentation is excellent, and I'd be happy to implement it. Just expressing some of my concerns to see if maybe your ideas can improved upon so we can see wider adoption.
(DIR) Post #ArU1SyxpdLlYCc3t1U by nathan@xoxo.zone
2025-02-25T16:32:26Z
0 likes, 0 repeats
@StevenB @dave Thanks. I’m always happy to adapt to encourage wider adoption.Regardless of the final tag(s), each use case for images will be it’s own chicken/egg challenge of adoption. My stance has always been that well-written tags should provide marginal utility even without widespread adoption, and in fact, that’s their only chance of finding any traction in an open ecosystem.
(DIR) Post #ArU1SzNi58SxUsAYMK by StevenB@podcastindex.social
2025-02-25T16:51:04Z
0 likes, 0 repeats
@nathan @dave That all makes sense. And I can totally see one image tag that covers multiple image cases. It makes a lot of sense. I would like to see the purpose of this single tag be required so the apps can easily figure out what it's for. I want to eliminate any guessing as to the podcaster's intent.
(DIR) Post #ArU1SzqmL3iax1llfU by StevenB@podcastindex.social
2025-02-25T16:54:12Z
0 likes, 0 repeats
@nathan @dave I also we prefer to have either fixed purposes or fixed aspect ratios and not a combination of the two. With 6 purposes and 6 ratios, we have 36 possibilities, which is a lot for an app to figure out and design for. I think a purpose having a predefined ratio makes design much easier, and if we want a different ratio, we create a new purpose. Those are the two main concerns I have when I'm thinking about how I would design a player using the podcast:images tag.
(DIR) Post #ArU1T0LyT4fiVmMgIC by dave@podcastindex.social
2025-02-25T17:01:40Z
0 likes, 0 repeats
@StevenB @nathan Nathan, can a "purpose" assume an aspect ratio? Or can we make that the case? Something like `banner` would imply 3:1? Or does that not fit with your design goal?
(DIR) Post #ArU1T4RRGhQ5Bsx6Mi by nathan@xoxo.zone
2025-02-25T15:49:12Z
0 likes, 0 repeats
@StevenB @dave Would you say Transistor shouldn’t claim to support Social Interact if the only platform they support is Bluesky? I expect there’s a range of opinions in this community.I appreciate that Sovereign Feeds takes a more comprehensive approach to supporting tags. If you ever find yourself stuck, I’m happy to help with UX support.
(DIR) Post #ArU3srWW7UeeYzkn8i by StevenB@podcastindex.social
2025-02-25T17:28:57Z
0 likes, 0 repeats
@dave @nathanMaybe muddying the waters, but just playing around with ideas.I also wonder if we can try to standardize the srcset in some way, or maybe deprecate it.So, a thumbnail is always a 1:1 image, but it should also be 150px W. A Square Logo is also always a 1:1 image, but it should be 100px W.As a host, I let them upload a Logo and crop and resize it for them.As a player, I see that it's purpose is Logo. I know it's always 1:1 and the source image is ideally 100px W
(DIR) Post #ArURvbaqCc1cvQcJpA by nathan@xoxo.zone
2025-02-25T21:58:20Z
0 likes, 0 repeats
@dave @StevenB As I was imagining it, an app would indicate they support for a specific purpose, such as a hero image. They’re free to define the name of the purpose and specify any additional requirements regarding dimensions, aspect ratios, file formats, etc. As always, apps aren’t beholden to bend over backwards to support whatever’s thrown at them. Participating hosts could implement a "Hero image" UI with just a file uploader, no other user-facing inputs.
(DIR) Post #ArUUSVzgF26N1X3W7s by nathan@xoxo.zone
2025-02-25T21:58:25Z
0 likes, 0 repeats
@dave @StevenB If a second app wants to support that exact same purpose, they just copy app1’s implementation and can immediately support the existing feeds.If App2 want to have looser restrictions, like allowing video files, but still use the same purpose token, then they just have to document their usage and requirements of that purpose. Hosts could add an additional file uploader labeled "Hero Video."Nothing changes for App1 because they were only accepting image assets to begin with.
(DIR) Post #ArUUSX2uKWHGHpZbnM by StevenB@podcastindex.social
2025-02-25T22:11:45Z
0 likes, 0 repeats
@nathan @dave As a designer and having episodes.fm, so you too have to contend with feeds, how would you handle displaying a situation in which you have four feeds with the purpose of "hero", but one feed has it as a 3/4, another has a 4/3, another has a 1/1, and another has a 16/9?
(DIR) Post #ArUUSXyKt0DN9wRTJA by nathan@xoxo.zone
2025-02-25T22:18:38Z
0 likes, 0 repeats
@StevenB @dave I’d display the image for the one that matches my documented aspect ratio, and treat the rest as if they hadn’t provided a hero image at all, which is the experience the vast majority of feeds will look like anyway.And I wouldn’t even trust the one that gave the correct aspect ratio. I’d use `object-fit:cover;` or equivalent to force it into that size even if the provided asset happen to be wrong.
(DIR) Post #ArUUSYdoOnOLEZqaxM by StevenB@podcastindex.social
2025-02-25T22:20:42Z
0 likes, 0 repeats
@nathan @dave Isn't interop the name of the game here though? If I have a banner in my feed, that banner should be useful in all podcasting apps. A "banner 16:9" being rejected in half of the apps because they only support "banner 3:1" seems like poor interop.I guess as a podcaster, I'd hate to have to make 4 images because episodes.fm, fountain.fm, TrueFans, and Podcast Guru all have different banner expectations they've documented but aren't all the same.
(DIR) Post #ArUUSZFk7ljV8Dat4y by dave@podcastindex.social
2025-02-25T22:26:36Z
0 likes, 0 repeats
@StevenB @nathan Let's just concentrate on banner to make this less difficult to follow. Steven, what you are saying is that you want the banner size defined in the spec so that you know how to lay out the app.Nathan, you're saying the app decides the sizing and chooses the image in the feed that conforms?Trying to get us on the same wavelength with the different perspectives. Correct me if I've gotten that wrong.
(DIR) Post #ArUUevdeik0M2CfnhQ by StevenB@podcastindex.social
2025-02-25T22:28:59Z
0 likes, 0 repeats
@dave @nathan Yes, I want the banner ratio to be consistent across all feeds. It's constricting, but it's consistent across any feed that uses <podcast:images purpose="banner"/> A podcaster can reasonably expect their banner will look similar regardless of the app it's being displayed in.
(DIR) Post #ArUVRar6mQPjlbAe24 by russell@podcastindex.social
2025-02-25T22:37:45Z
0 likes, 0 repeats
@dave @StevenB @nathan This is where I disagree a little - it's the hosting providers that choose which size that they will support the user to upload. Apps like @samsethi allows a user to override, so if they want to login to Truefans and change the banner to make it look nicer then that is something that they can do on Truefans.Otherwise what is the reason for a creator to ever go to a podcast apps player and promote it, if they don't do any work over there on said player?
(DIR) Post #ArUYW5ofuVMCoJryW8 by nathan@xoxo.zone
2025-02-25T22:30:55Z
0 likes, 0 repeats
@StevenB @dave As I see it, app devs are in the business of designing the best experience for their listeners, and how they achieve that is up to them.Maybe another dev would choose to take the "most similar" aspect ratio available and display it cropped. Or hell, adapt the whole UI to fit the provided assets.
(DIR) Post #ArUYW6vRmoMuFc2tiC by StevenB@podcastindex.social
2025-02-25T22:36:47Z
0 likes, 0 repeats
@nathan @dave But we're dealing with more than just app designers. We're dealing with hosts that have to provide the UX for their podcasters, and we're dealing with podcasters that want consistent branding for their podcast across any app their podcast may appear in. Any tag we develop will always have at least those three parties that we have to take into consideration.
(DIR) Post #ArUYW7xFxZPTRVtrAe by nathan@xoxo.zone
2025-02-25T23:01:23Z
0 likes, 0 repeats
@StevenB @dave I 100% agree.My intention was to avoid a multitude of media-related tags in the spec by creating the "ONE IMAGE TAG TO RULE THEM ALL", which essentially just gives apps/feeds the toolkit to define their own image standards without needing the namespace to "bless" each and every one.I think my biggest failing here is not providing a sample podcaster-facing UI for hosts like I did for UpdateFrequency. https://update-frequency.vercel.app/.
(DIR) Post #ArUYW8hLCEGzkRSf0C by StevenB@podcastindex.social
2025-02-25T23:10:07Z
0 likes, 0 repeats
@nathan @dave No failings. I think it's a good tag. Even if it ends up being a very open ended tag, I'll support it. I'm sold on the purpose attribute. It think the media type works well and allowing more video stuff will be cool.Some of this is because I'm choosing to build a bunch of apps, and an open ended tag is more difficult to code for, so I'd prefer simplicity over complexity. This isn't my namespace though, so I'll defer to whatever is decided and work with it.
(DIR) Post #ArUYW9JctstjfBNEg4 by dave@podcastindex.social
2025-02-25T23:12:05Z
0 likes, 0 repeats
@StevenB @nathan This conversation is so helpful.
(DIR) Post #ArUZCQAicS7o6YMdBA by StevenB@podcastindex.social
2025-02-25T23:19:50Z
0 likes, 0 repeats
@dave I know you often bow out of these conversations, but you have a gift of mediation that is very helpful, and I'm encouraging you to use it more often. You've earned everyone's respect, so when you speak, we all listen.@nathan
(DIR) Post #ArUod6PngHWtxfbCXA by james@bne.social
2025-02-26T02:12:40Z
0 likes, 0 repeats
@dave I don’t think it means a thumbnail image. It doesn’t say that in the spec at all as far as I can see. A banner is still representative for the media object.
(DIR) Post #ArUojU1io3Z6vfNYyu by james@bne.social
2025-02-26T02:13:50Z
0 likes, 0 repeats
@dave I really don’t care what we call it.
(DIR) Post #ArV3bo4lsXjk6ebRrc by TurdFerguson@podcastindex.social
2025-02-26T05:00:34Z
0 likes, 0 repeats
@dave Will either of the approaches cause any concerns in regards to compatibility or ease of maintenance to the code?