Proposal: Extend chapter capabilities

[theDanielJLewis]

Text blocks

#399 about <podcast:notes> (a tag I've wanted for a while) made me think of another consideration, or possibly even a replacement for the notes tag: textblocks in chapters.

I think the notes someone sees in their podcast app should be concise, clean, and actionable. They should not be the full written version of the content (either as an article or the transcript), but more like an outline with any citations or links.

But this is potentially redundant with chapters. I think it's a good practice to give a chapter to every section of a podcast, just like the written version would have headings. Within each section, there might be multiple citations or links necessary to share, but that would make for a poor user experience if the links were timed to microchapters.

Thus, my idea is to offer an additional field for Podcasting 2.0 chapters. It could be "content," or "text," but it would need to accept multiple lines and basic formatting (bold, italics, strikethrough, and hyperlinks).

Take my episode "What Is Podcasting 2.0 and Why Does It Matter?" for example.

I have a chapter for my section "How to upgrade your podcast experience with Podcasting 2.0." In the full article, I link to each option I recommend, and information explaining each.

But in my basic outline (that I would love to show in all podcast apps through a tag like #399's <podcast:notes>), I only briefly and actionably list the same links:

    <p>Here are my top recommendations to start using Podcasting 2.0 today!</p>
    <ul>
      <li><a href="https://github.com/Lehmancreations/Podcast-Namespace-Wordpress-Plugin/releases">WordPress with PowerPress, plus the Podcast Namespace plugin</a></li>
      <li><a href="https://theaudacitytopodcast.com/blubrry">Blubrry podcast hosting</a></li>
      <li><a href="https://theaudacitytopodcast.com/buzzsprout">Buzzsprout</a></li>
      <li><a href="https://theaudacitytopodcast.com/libsyn">Libsyn</a></li>
      <li><a href="https://theaudacitytopodcast.com/captivate">Captivate</a></li>
      <li><a href="https://podcastindex.org/apps">More options</a></li>
    </ul>

Now imagine if, instead, I could put that formatted list of links inside my chapter instead of only a single URL per chapter!

Another example of this could be if my chapter is using only a single link to a resource I recommend, but I use the chapter text field to provide a necessary affiliate disclosure or a promo code.

As for the UI, text could replace the image, so the chapter could have only an image or a text block, but not both. But I can foresee several cases where you would need both an image and text block.

So inside the episode data JSON file, the chapters section would look like this:

"chapters":
    [
        {
            "startTime": 450,
            "title": "How to upgrade your podcast experience with Podcasting 2.0",
            "text": "<ul>
      <li><a href=\"https://github.com/Lehmancreations/Podcast-Namespace-Wordpress-Plugin/releases\">WordPress with PowerPress, plus the Podcast Namespace plugin</a></li>
      <li><a href=\"https://theaudacitytopodcast.com/blubrry\">Blubrry podcast hosting</a></li>
      <li><a href=\"https://theaudacitytopodcast.com/buzzsprout\">Buzzsprout</a></li>
      <li><a href=\"https://theaudacitytopodcast.com/libsyn\">Libsyn</a></li>
      <li><a href=\"https://theaudacitytopodcast.com/captivate\">Captivate</a></li>
      <li><a href=\"https://podcastindex.org/apps\">More options</a></li>
    </ul>"
        },
    ]

And I think calling it "text" makes more sense than "content," so it's obviously a specific form of content, and it's not where images go.

Galleries

The other idea is to allow an array of image URLs so a single chapter can display multiple images, allowing the listener to view and even navigate the images at their own pace. Consider how No Agenda mentions multiple submitted artwork pieces and how it would be so much more enjoyable for the listener if they could swipe back and forth between images—while listening or even while paused. This would provide a better experience for the listener than a barrage of images speeding past.

Another potential use could be for a movie- or TV-fan podcast discussing a particular scene. They could upload multiple screenshots from that scene—maybe showing specific things they're talking about.

Or someone wants to show a before and after photos, letting the listener switch back and forth between them instead of the app's display one and forcefully moving on to the next with a new chapter.

I think each image in the gallery should function similar to normal chapters, but making title and URL fields option.

Here's an example for the episode data file:

"chapters":
    [
        {
            "startTime": 400,
            "title": "Submitted artwork",
            "gallery": 
              [
                {
                  "title": "Airplane by Amy",
                  "img": "https://example.com/images/airplane-by-amy.jpg",
                },
                {
                  "title": "Boat by John",
                  "img": "https://example.com/images/boat-by-john.jpg",
                  "url": "https://link-to-buy-tshirt.com",
                }
              ]
        }
    ]

If a chapter could receive a "gallery" of child chapters, this could be used for my idea of providing a list of links, but I think that overcomplicates the process, and thus I think this gallery idea should be used only for images (plus maybe videos?).

[theDanielJLewis]

Another use of a text block could be for dev-related podcasts to display code in a monospaced font instead of a screenshot.

[theDanielJLewis]

Another cool thing would be if comments could be left on chapters, giving more specificity than episode comments, but also more inclusion and conversation-inspiration than timestamp comments.

[brianoflondon]

Another use of a text block could be for dev-related podcasts to display code in a monospaced font instead of a screenshot.

Markdown (as the or a format) would fix this.

[jamescridland]

Markdown seems ideal for this. There will be libraries to decode it, and it is designed to be humanly-readable if not supported.

...looks kind of decent, but

doesn't look entirely horrible. (Welcome to my writing software!)

It's also good for security, since it can't contain HTML that needs to be sanitised. I'd support the user of Markdown.

(I'd still mourn the fact that we're unable to make this into semantic data, but that's a different argument.)

[theDanielJLewis]

I like the idea of supporting markdown. I just wonder if that creates unnecessarily more work for developers when they might already have sanitized HTML support in both creation and consumption apps.

[theDanielJLewis]

I'm not giving up on this idea!

The other huge benefit to this is that it can move byte-heavy data out of the RSS feed and into the episode metadata files.

[theDanielJLewis]

This could also be the ideal place to put polls and such, unless such poll would be for the entire episode.

[theDanielJLewis]

@daveajones, I would really love this to be considered for phase six. There are so many ways we can make chapters actually better in Podcasting 2.0, not simply located somewhere else.