Proposal: Extend chapter capabilities #469
Replies: 17 comments 12 replies
-
|
Another use of a text block could be for dev-related podcasts to display code in a monospaced font instead of a screenshot. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Markdown (as the or a format) would fix this. |
Beta Was this translation helpful? Give feedback.
-
|
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.) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
This could also be the ideal place to put polls and such, unless such poll would be for the entire episode. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
Add chapter-level value splits to this (#512), too. |
Beta Was this translation helpful? Give feedback.
-
|
You could easily put boostagrams in this, too! Like @Lehmancreations was trying to do in a way that's more complicated and clunky than it needs to be. Imagine this. You make a single chapter for your boostagrams. And within that chapter can be like a slideshow of your separate boostagrams, allowing your audience to see the boostagram text on their screen, or even swipe back and forth between boostagrams instead of being forced to switch when the chapters switch. |
Beta Was this translation helpful? Give feedback.
-
|
To be honest it wasn’t me. Yes I used it but it was @johnspurlock that created it |
Beta Was this translation helpful? Give feedback.
-
|
@theDanielJLewis It was Adam's idea; and the idea was to replicate the view you get in SoundCloud, where as you listen to a track, you see the comments appear in real time. I like it as a plan. I would possibly recommend some form of |
Beta Was this translation helpful? Give feedback.
-
|
The idea to jury-rig the chapters system to display boostagrams as a proof of concept was great. But maybe we can do better than adapt chapters to this new use. Let me generalize the concept of displaying boostagrams with the one of "alerts" or "banners" if you prefer. Probably there's a better general term in English. Maybe we should consider creating a completely independent tag, something like <podcast: banners> at the episode level, pointing to a json file with a list of elements consisting in a timestamp and a text. This would make the implementation from the app quite easy and the user experience much more clean. |
Beta Was this translation helpful? Give feedback.
-
|
Franco. I like your idea. Keep it separate but have the app display it in a banner |
Beta Was this translation helpful? Give feedback.
-
|
Chapters already have the ability to be hidden from the table of contents, and thus be invisible chapters. So you could just as easily attach an alert to a chapter or use the chapters protocol only for displaying alerts and not using chapters at all. I'd like to see us make our extensions extensible instead of duplicating data. For example, the time-based value splits should really be in chapters, not a separate item in the feed. Or maybe chapters should be moved back into the feed. My philosophy is that if it's time-based within the episode, it should all be in the same place, using the same protocol, and the chapters seem like the best place for that. |
Beta Was this translation helpful? Give feedback.
-
|
@theDanielJLewis I can see your point of view. The issue is this negates the possibility for the app to display chapters and boostagrams with different and specialized UI representations. Or display both at the same time. Unless we decide to generalize the chapters tag, and make it more like an "events" or "metadata" tag, and add some property to each event specifying if the item is a chapter, an alert, a boostagram, a message... |
Beta Was this translation helpful? Give feedback.
-
|
After recent conversations, including the October 27 boardroom, I'm putting together some (updated) examples of the types of chapters we could make. I even put in a boostagram as an example (but I still oppose the idea of putting boostagrams in chapters, unless the boostagram was read in the episode). {
"chapters": [
{
"startTime": 400,
"title": "Submitted artwork",
"type": "slides",
"children": [
{
"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"
}
]
},
{
"startTime": 500,
"title": "3. The best microphoens for podcasting",
"type": "slides",
"children": [
{
"title": "Audio-Technica ATR2100x-USB",
"img": "https://example.com/images/atr2100x-usb.jpg",
"text": "The best starter mic that can <em>grow</em> with your show!",
"url": "https://link-to-product.com"
},
{
"title": "Shure SM7DB",
"img": "https://example.com/images/sm7db.jpg",
"text": "<p>This update to the SM7B is a great upgrade. But if you get the legacy SM7B, you'll need the following:</p><ul><li>Cloudlifter or a really good preamp</li><li>Mic stand</li></ul>",
"url": "https://link-to-product.com"
}
]
},
{
"startTime": 900,
"title": "Thanks for the boostagrams!",
"type": "slides",
"children": [
{
"text": "Thank you for the show!",
"value": 4000,
"currency": "sats"
},
{
"text": "March on, rubber duckies!",
"value": 22222,
"currency": "sats"
}
]
},
{
"startTime": 1200,
"title": "Ad: Podgagement",
"type": "text",
"text": "Engage your audience and grow your podcast with Podgagement!",
"url": "https://podgagement.com"
},
{
"startTime": 1201,
"type": "text",
"title": "Boostagram from johndoe123",
"text": "That's a great point, John!",
"toc": false
},
{
"startTime": 1400,
"type": "poll",
"title": "What movie should we review next?",
"toc": false,
"children": [
{ "text": "The Lego Movie" },
{ "text": "The Princess Bride" },
{ "text": "The Lego Batman Movie" }
]
},
{
"startTime": 1400,
"type": "music",
"title": "Choice Music",
"img": "https://example.com/images/musician.jpg",
"toc": false,
"valueSplits": [
{ "wallet": "artist-wallet", "split": 90 },
{ "wallet": "cover-designer", "split": 10 }
]
}
]
}A few things to note from this:
(This was written while listening to the Podcasting 2.0 show live, so I might need to come back to edit.) |
Beta Was this translation helpful? Give feedback.
-
|
Several of these are things I already want to use in my podcast. |
Beta Was this translation helpful? Give feedback.
-
|
Here's my humble idea. Instead of trying to merge everything into a single chapter file, why not just allow for multiple This solves a some problems I see with the current Reflex chapter setup:
|
Beta Was this translation helpful? Give feedback.
-
|
I've been following the discussion throughout the week about putting Boostagrams in the chapters file, and I feel there are several design principles that would suggest we not do this, but actually there is one overriding design principle that can explain all of the concerns that I had, and that's "separation of concerns". My critique below has turned out to be a bit long, so: TLDR; Let's honour the "separation of concerns" design principle here. Boostagrams are not chapters for the same reason that transcripts are not chapters and live comments are not chapters. If we want to extend the RSS spec to support transcripts, chapters, boostagrams and live comments, all of which have timestamps that put them on the same timeline, one could theoretically put all these kinds of data and more into a single resource and then have a link to it from the RSS feed. But because the transcripts, chapters and live comments are going to be updated by different people at different times and for different reasons and with different tools, and because we might also want the freedom to substitute different alternative file formats for transcripts and chapters in a modular way, and the freedom to switch to alternative tools to produce transcripts and chapters, or manage live comment and Boostagram events, merging them into one artifact would be disadvantageous. I think there is already agreement that this is true for transcripts, but for the same reasons it is also true for chapters. Let's give a definition of what chapters actually are. They are the subdivisions of the audio file into sections, each with metadata describing the section. Chapters therefore are not instantaneous moments in the timeline, but rather are spans of the timeline going from a certain start point to a certain end point which is typically the start of the next chapter. This is distinctly different from events which are instantaneous and do not divide the timeline into sections, but could nonetheless occur within the timeline, or perhaps even within chapters. If we want to introduce a new data element such as chapter art, the principle of separation of concerns asks us to consider whether chapter art concerns itself with chapters, or whether it is a separate concern altogether. On consideration, we say that yes, chapter art does concern itself with chapters because the chapter art should appear along with the title - they define metadata of exactly the same thing and they span the exact same duration. If we want to introduce a new data element such as events, that may be fine IF the type of events we're talking about are concerned with the metadata of chapters. For example, perhaps a science podcast wants to provide links to citations as they are being talked about within the chapter -- but it is something that needs to be justified and not added haphazardly. As long as we define clearly what chapters fundamentally are, this promotes healthy interoperability between different tools and different formats, because they all agree on what chapters actually are. An authoring tool for chapters will be be able to import chapters from one format, provide editing features concerning chapters, and output those chapters in a potentially different format which still concerns chapters, even if different formats are richer than others. No person is going to open their chapter editor and insert a Boostagram, that is a different concern altogether, not the concern of the person creating chapters, but of an automated agent that happens at a different time from the chapter editor's workflow. And although nobody is forcing people to put Boostagrams in chapters, it at least suggests that we should be looking for a different solution to the problem. Back in another era, Microsoft once tried to merge their web browser and their operating system with a justification that this would unlock some sort of synergy, but the effect is that it would have made it difficult for users to switch between alternative web browsers and alternative operating systems. It's similar to a strategy they were previously famous for called "Embrace and Extend" in which they would destroy competing alternatives by making it impossible to substitute one competing product for another. The only way we can promote the freedom to substitute is to have a clearly defined separation of concerns. Another consideration is that in a distributed system, we need to manage the process of updating the data and of detecting and fetching updates to that data. For this, it is beneficial to put data together if it is likely to be updated around the same time, and so for example we would like to separate static data from dynamic data. In theory, it is possible to have chapters that are completely finalised before the episode is published, and yet for boostagrams to continue to come in later as people will listen to the episode in their own time, maybe tomorrow, maybe next week, maybe next month. These are different update patterns that suggest that we shouldn't have to reload all of the chapter data each time a new boostagram is received. |
Beta Was this translation helpful? Give feedback.
-
To play devil's advocate slightly here... The name of this feature is To be clear, I am not proposing that we change its name! But merely, to propose that we consider a (A 'chapter' may have an end time as well as a start time, though that's not mandatory, and an 'end' time is the same as a 'start' time: it's just a timestamp in reference to a specific audio file). Your post was really helpful to clarify this thought in my mind - that a chapters file is really a timeSynchedMetadata file. And while I'm still rather against putting static, non-timeSynchedMetadata information within this file, I can see how beneficial it would be to have one file with all timeSynchedMetadata to accompany a podcast. (We get even higher marks if we add some method of synching it with the audio that isn't, just, time-based). In terms of updates; I do hear you, but I'd also suggest that these files (after GZIP) are very, very small and the overhead of a client grabbing and parsing the chapter file on a play event is unlikely to be great. Use of the standard HTTP headers to control caching and publication here seems to make most sense; after all, audio itself may have dynamic insertion in it. It seems to me to add complication - and more overhead - to expect the client to parse four or five files all with different data in them. And, probably worth remembering, many of us pay for incoming file requests as well as total bandwidth, so every additional file request means more hosting costs. |
Beta Was this translation helpful? Give feedback.
-
As I said, I don't object to putting other timestamped metadata together with chapters IF that data is related and if the editing process is related. If a multimedia slide show is designed to be overlaid over the audio content, then the slides are supposed to tell a coherent story. Everything in the slide show is related and we would want to edit it together. Note that we are not trying to measure how well all data fits into a given name, otherwise we could just re-christen it If we get the separation of concerns right, we should ideally have a market where Company A can concern itself with chapters, Company B can concern itself with transcripts, and Company C can concern itself with boostagrams, and some super companies can have the resources and expertise to do more than one of these things. Certainly URLs give us that flexibility. A podcaster can host their RSS feed and audio on Company A, then for example include a URL linking to a transcript produced and hosted by Company B, again same for chapters, and again same for a boostagram feed, and again seem for a comments feed. Now as for the inherent relatedness of the data, imagine if a company provides tools for creating educational courses delivered as podcasts, and the output of this tool is a bundle of assets representing the audio content, the transcripts and the additional rich multimedia encoded in the chapters file, and maybe links to interactive quizzes to be done at certain timestamps, and maybe auto pause points. After that course is created, the assets are effectively "finished" and don't require any further edits. You will now want to publish these static assets and run it as a Summer course. Suppose you also want to earn revenue through boostagrams. Do you really want these boostagrams to overwrite your "finished" course assets? What if you want to re-run the course each season with a new cohort of students with a clean live comments feed and a clean boostagram feed, but keep all the actual course content untouched? If the boostagrams need to be inserted into the finished course content, that seems like a kludge, and even if it is a short term workaround, we should still be looking for a better way for the long term. The thing about design principles is that they help you to avoid problems down the line without necessarily being able to foresee what those exact problems will be.
I don't buy it. We're talking about one additional file per episode, whereas chapter art is easily 20 new image files per episode, and that will grow as we start making chapter files even richer. Since the boostagram feed is a dynamic feed, it is also the perfect sort of thing we might want to be managed by a separate 3rd party service that concerns itself with all that crypto stuff (in such a case, it would not be an additional file on the same server). |
Beta Was this translation helpful? Give feedback.
-
|
As one slightly random thought... The problem is that timeSynched data like this breaks when the podcast audio has DAI of differing lengths. If a pre-roll is 30" for me and 40" for you, then this breaks all the timings, since they'll be ten seconds out for someone. With this wider definition of what goes into a chapters file (or a timeSynchedMetadata file), then it occurs to me that we can add some calibration data: {
"id3-tag": "CHP4a",
"intendedTimestamp": 1200,
"type": "calibration",
},In the above, we tell the client that when it sees the ID3 tag named "CHP4a", then it should treat this as being 1200 seconds into the podcast, and make all future calculations based on this. So, if a chapter comes along at a startTime of 1500, the client is really thinking to itself "this is 300 seconds after the CHP4a timestamp. I found that in the audio, so I know exactly where I'm going." This allows for chapter files to be delivered independently of the audio files; and decouples the timing from actual advertising, since the ID3 tag can be placed anywhere in the MP3 file, not surrounding the ads. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like this deserves its own issue/discussion :-) |
Beta Was this translation helpful? Give feedback.
-
|
I haven't read all of @ryan-lp's input but I agree with the sentiment of the TL;DR. When listening to the boardroom, I'm now seeing a lot of machine-generated chapter images for boosts, which aren't really engaging. I love listening to them as they're read out by the hosts, though. Also, these boostagram chapters don't help me navigate the episode (which what chapters are for, in my view). @theDanielJLewis proposed using the existing I think we should avoid this. And I think the best way is to keep different timeSyncedData separate indeed (maybe allowing multiple chapter files as mentioned by @ericpp). |
Beta Was this translation helpful? Give feedback.
-
|
My core proposal is to extend what chapters can do to make them actually better than legacy chapters, namely including text, multiple images, and such. I don't think boostagrams or comments should be in chapters. I agree that chapters are the division of the content, not a timeline of external events. |
Beta Was this translation helpful? Give feedback.
-
|
@daveajones kind suggestion for a next boardroom meeting. For No Agenda it's a bit sad to not really be able to enjoy the chapter images. And navigating episodes in the PC2.0 podcast (which I do sometimes as I want to reference/relisten certain bits) is more challenging with a long chapter list 'polluted' with non-chapter chapters. Personally I agree with @theDanielJLewis about the purpose of chapters, but if |
Beta Was this translation helpful? Give feedback.
-
|
Another idea for these "Super Chapters" (shoutout to @joksas for the great name!): remote items. This isn't merely an offsite link, but it could even trigger the app to play that remote item when hitting that chapter. This would work great for what @daveajones and Adam were talking about in Podcasting 2.0 166 about remote licenses and music or other content. |
Beta Was this translation helpful? Give feedback.
-
@Phantom-Power-Music-JC @kidscallmeray this may be relevant to you. |
Beta Was this translation helpful? Give feedback.
-
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: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:
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:
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?).
Beta Was this translation helpful? Give feedback.
All reactions