Feedback channel from Podcast App to Podcast Producer

Podlove Specifications
1

​
I’d like to make a new suggestion for a specification:

The Podlove Feedback channel <pfc>.

The problem many (especially small) podcasts have is the missing feedback from the listeners. One of the reasons is the distance between the podcasting app and a feedback possibility (mostly based on webforms on the website/blog belonging to the podcast).

The distance between the podcast player and the feedback possibility has to decrease in order to get more and faster feedback from the listeners.
Within this element specifications regarding a feedback channel from an App to the podcast server is defined. To enable more direct feedback coming from the listeners to the producers. It contains following elements

<pfc:url> - the url to the feedback backend http://mylittlepodcast.com/feedback/.
This field is mandatory if the pfc is implemented

<pfc:system> - the definition of the feedback backend the options are:

  • binary (Like/dislike)
  • 5Stars (1-5 Stars)
  • text (free text)
    This field is mandatory if the pfc is implemented and may contain one or more of the mentioned options

Additional feedback might be also defined to be send during the listening including the play position of an episode ans should be linked from the podcast server to the specific position in the media file (similar to the comments seen on soundcloud)

The Feedback send from the App to the Server has to be started by manual input from the user. Automatic feedback sending and therefore privacy violating tracking is not allowed.

The Podcast Player shall send the data via HTTP Post request in json format to the server including a random UUID generated by the App for this podcast to allow blocking several request from the same user/app but disallow tracking over different podcasts.

{
  pfc:
    {
      episodeID : 'MM001'
      feedback : '4'
      uuid : 'd9894a58-c66f-11e5-9912-ba0be0483c18'
    }
}

The server will take this information and might display it next to the episode within the podlove webplayer or in back end visible only for the producer.

Open Questions:

  • How to ensure the security of the feedback channel (no massive feedback created) without requiring a login system
2

I really like the idea!
As far as I know, Podcat will (soon?) implement a feedback feature right into their podcatcher. That’s the closest to “direct feedback” I’ve heard about so far. Here is a thread over at Sendegate discussing this feature.

3

nice. but full comment’s look kind of to big, I would love to see simple and quick feedback. Over there at Sendegate it’s written “Das wird eine offene Podlove Spezifikation und muss daher nicht Podcast only bleiben.” Why isn’t it somewhere here? Doesn’t look any open to me (currently).

4

This might just be very early in development.

@timpritlove, could you comment on this? Any news?

5

Would be great to get some information about what’s planned. I’m not only a podcaster but I also currently developing a podcasting app and I’m really close to implement my proposal in the app, my own and the podcasts of my friends. Would be great not to have different similar systems to support and develop.

6

This idea has been floating around here for a while.

However, the most valuable feedback there is written text or spoken words. So that’s what I focused on first. Also, because Podlove wants to channel this information via the Podcast Feed, it is specified in XML. Here is my current state of the proposal. Feel free to discuss.

Feedback Transport mechanisms

First question is how feedback should travel to the podcaster.

Feedback via E-Mail

The primary, most reliable and offline-capable feedback communication path is E-Mail. This can be considered feasible for any Smartphone device easily by passing on the feedback content to the device’s e-mail subsystem without having to implement any e-mail specific stuff:

<!-- Feedback Method: E-Mail -->

<pfe:feedback type="email" audio-feedback="yes" machine-readable="yes" xmlns:pfe="http://podlove.org/feedback-extensions">
	<pfe:name>LNP Feedback</pfe>
	<pfe:mailto>feedback+lnp163@metaebene.me</pfe:mailto>
	<pfe:subject>Include this in subject</pfe:subject>
</pfe:feedback>

This element goes either inside a channel element (and therefore provides a global feedback address for the whole podcast or inside a item element (so it is limited to just one episode.

The audio-feedback attributes signals to the client if the podcaster is ready for/wants audio comments. This could also be changed to allow video too, not sure how to name the attribute in that case.

The machine-readable attribute is meant to advertise the expectation that a reply should be formatted in a machine-readable way where this spec also defines the format. This could be something like this:

<?xml version="1.0" encoding="UTF-8"?>
<pfe:comment xmlns:pfe="http://podlove.org/feedback-extensions" public="yes">
	<pfe:episode-link>http://logbuch-netzpolitik.de/lnp155</pfe:episode-link>
	<pfe:timecode start="01:13:00" stop="01:25:23" />
	<pfe:text>foo bla bar</pfe:text>
	<pfe:audio attachment-id="attachment1" />
</pfe:comment>

Of course we could also rely on kinda well-formatted e-mails where we take the e-mail content and extract audio attachments but I would be happier if we would nail this from the start by adding this machine readable file. Not sure how easy it will be to refer to an audio attachment if the OS composes the e-mail for you and the attachment ID is generated automatically and at a time where this information can’t be put in other attachments. I’d like some feedback by client programmers here.

The feedback element could also include information about a S/MIME key to allow for encrypted feedback as most smartphones may be able to handle this.

Feedback via HTTP

Of course, we could also add a more sophisticated online feedback method using a HTTP POST API call.

<!-- Feedback Method: HTTP POST -->


<pfe:feedback type="post" xmlns:pfe="http://podlove.org/feedback-extensions">
	<pfe:post-url>http://logbuch-netzpolitik.de/wp-admin/podlove/feedback/124</pfe:post-url>
</pfe:feedback>

In this case we would need to define the parameters and result codes so that this API can be properly implemented. But i see many advantages in just using e-mail.

Other feedback styles

While I am not a big fan of the 5-Star method (I honestly think it is totally broken by design and does not work anywhere), I like the idea of featuring abstract feedback methods.

Apart from the binary method (like/dislike) which I think is a good one as it can’t be any simpler than that, another popular way would be to express feelings. This is a much harder game as the number of emojis are endless :slightly_smiling:

But in a way I think it would be a good start to just provide the e-mail method, leave the door wide open for new feedback types and start from there.

1 Like