Congratulations! I have to say I’m a bit jealous, but sadly Overcast is Apple only…
It’s always nice if you can provide real-time active tracking and posting on your own website, but is it really necessary? Is it always worthwhile? What value does it provide to you? to others?
The other day I read Eddie Hinkle’s article in which he details how he either actively or passively tracks on his own website things he’s listening to or watching. I thought I’d take a moment to scribble out some of my thoughts and process for how and why I do what I’m doing on my own site.
I too track a lot of things relatively passively. Most of it I do for my own “diary” or commonplace book. Typically I’ll start out using silo services that have either RSS feeds or that work with services like IFTTT.com or Zapier. If those don’t exist, I’ll just use the ubiquitous “share” functionality of nearly all web pages and mobile platforms to share the content or page via email which I can use to post to my website as well. The primary minimal data points I’m looking for are the title of the specific thing I’m capturing (the movie, tv show/episode title, book title, article title, podcast title) and the date/time stamp at which the activity was done.
I’ll use these to take input data and transfer it to my own website, typically in draft form. In many cases, these methods collect all the data I want and put it into a format for immediate sharing. Other times I’ll clean up some bits of the data (almost always context related, so things like images, summaries, the source of the data, etc.) a bit before sharing. Then I optionally decide to post it either publicly or privately on my site.
Some of the sources I use for pulling in data (especially for context) to my website include:
Watches: IMDb.com, Letterboxd, TheTVDB.com, themoviedb.org, direct websites for shows/movies themselves
Listens: typically using share functionality via email from my podcatcher; Spotify, Last.fm,
Reads: reading.am, Pocket, Hypothes.is, GoodReads,
Bookmarks: diigo, Hypothes.is, Twitter, Pocket
Often, going the route of least resistance for doing this sort of tracking is a useful thing to find out if doing so is ultimately useful or valuable to you. If it’s not, then building some massive edifice and code base for doing so may be additional sunk cost to find out that you don’t find it valuable or fulfilling somehow. This is primary value of the idea “manual until it hurts.”
I will note that though I do have the ability to do quick posting to my site using bookmarklets in conjunction with the Post Kinds Plugin for WordPress, more often than not, I find that interrupting my personal life and those around me to post this way seems a bit rude. For things like listen posts, logging them actively could a be a life threatening endeavor because I most often listen while driving. Thus I prefer to take a moment or two to more subtly mark what I want to post and then handle the rest at a more quiet and convenient time. I’ll use down time while passively watching television or listening to music to do this sort of clean up. Often, particularly for bookmarks and annotations, this also forces me to have a second bite at the proverbial apple to either follow up on the bookmarked idea or think about and reflect on the thing I’ve saved. In some sense this follow up is way more valuable to me than having actively posted it and then simply moving on. It also becomes a way for what might otherwise be considered “digital exhaust” to give me some additional value.
Eventually having better active ways to track and post these things in real time would be nice, but the marginal additional value just hasn’t seemed to be there for me. If it were, there are also larger hurdles of doing these posts quickly and in a way that pulls in the context portions I’d like to present. Adding context also generally means having solid pre-existing data bases of information from which to poll from, and often these can be difficult to come by or require API access to something. As a result services like Swarm and OwnYourSwarm are useful as they can not only speed up the process of logging data, but they are underpinned with relatively solid databases. As an example, I frequently can’t use IMDB.com to log in television shows like Meet the Press or Face the Nation because entries and data for those particular episodes often don’t exist even when I’m watching them several hours after they’ve aired. And even in these cases the websites for these shows often don’t yet have photos, synopses, video, or transcripts posted when I’m watching them. Thus posting for these in real-time the way I’d like becomes a much more difficult nightmare and requires a lot more manual effort.
As a follow up to Eddie’s post (which doesn’t yet show the Webmention), I’ll also point out that Jonathan has an excellent description and some code for what he’s doing on his site as well.
Maybe like this?
Marco, your post about supporting rel=”payment” for Overcast made me start thinking about other potential solve-able problems in the podcast space. Now that you’ve solved a piece of the support/payment problem, perhaps you can solve for a big part of the “who actually listened to my podcast” problem?
In a recent article on the topic of Webmention for A List Apart, I covered the topic of listen posts and sending webmentions for them. In addition to people being able to post on their own website that they’ve listened to a particular episode, the hosting podcast site can receive these mentions and display them as social proof that the episode was actually listened to. In addition to individual websites being able to do this, it would be awesome if podcast players/apps could send webmentions on behalf of their users (either with user specific data like Name, website, avatar, etc. if it’s stored, without it, or anonymized by the player itself) so that the canonical page for the podcast could collect (and potentially display) them.
As a proof of concept, here’s a page for a podcast episode that can receive webmentions. Someone listens to it, makes a “listen post” on their site, and sends a webmention of that fact. The original page can then collect it on the backend or display it if it chooses. Just imagine what this could do for the podcast world at scale for providing actual listening statistics?
In addition to aggregate numbers of downloads a podcast is receiving, they could also begin to have direct data about actual listens. Naturally the app/player would have to set (or allow a configuration) some percentage threshold of how much was played before sending such a notification to the receiving site. Perhaps the webmention spec for listens could also include the data for the percentage listened and send that number in the payload?
The toughest part may be collecting the rel=”canonical” URL for the podcast’s post (to send the webmention there) rather than the audio file’s URL, though I suspect that the feed for the podcast may have this depending on the feed’s source.
If you want to go a step further, you could add Micropub support to Overcast, so that when people are done listening to episodes, the app could send a micropub request to their registered website (perhaps via authentication using IndieAuth?). This would allow people to automatically make “listen posts” to their websites using Overcast and thereby help those following them to discover new and interesting podcasts. (Naturally, you might need a setting for sites that support both micropub and webmention, so that the app doesn’t send a webmention when it does a micropub post for a site that will then send a second webmention as well.)
One could also have podcast players with Micropub support that would allow text entry for commenting on particular portions of podcasts (perhaps using media fragments)? Suddenly we’re closer to commenting on individual portions of audio content in a way that’s not too dissimilar to SoundCloud’s commenting interface, but done in a more open web way.
As further example, I maintain a list of listen posts on my personal website. Because it includes links to the original audio files, it also becomes a “faux-cast” that friends and colleagues can subscribe to everything I’m listening to (or sub-categorizations thereof) via RSS. Perhaps this also works toward helping to fix some of the discovery problem as well?
Thanks, as always, for your dedication to building one of the best podcast tools out there!
I’ve been meaning to write regular updates to highlight some of the useful changes in the functionality of the IndieWeb suite of WordPress plugins, but never gotten around to it. There’s been a few really interesting ones lately, so I thought I’d start. Observant watchers who read through either the code or even the scant change logs before they update their code may catch some of these features, but sometimes interesting tidbits can slip by the most vigilant. Here are some interesting recent ones:
Display of Reads, Listens, and Watches in comments sections
David Shanske’s excellent Post Kinds Plugin allows one to post what they’re reading, listening to, or watching in simple IndieWeb fashion. (Examples of these on my site: read posts, listen posts, watch posts.) These posts types automatically include the appropriate microformats classes so the user doesn’t need to bother doing them manually. For a long time when replying to another’s site, bookmarking it, or even mentioning it when also using the Webmentions plugin would send the site a Webmention that would generally cause it to show up as a native comment, bookmark or mention. With an update late last year, from within the
Discussion settings in WordPress, one could set toggles so that many of these webmentions could be displayed as facepiles. Other broadly unsupported post types would typically default to a simple mention.
Recently David Shanske and I started a podcast, and he thought it would be useful if his site could accept listen posts and show them visually within his comments section just like these replies, bookmarks, and mentions. Thus over the past month he’s added code to the Semantic Linkbacks Plugin to add the functionality for these types of posts to properly render showing facepiles for listens, reads, and watches.
This is what webmentions of listen posts look like on his site in his comments section:
Listen (or scrobble) posts can send webmentions (or notifications) to the original content potentially with the experimental
listen-of microformat. In the case of scrobbles of podcasts, these webmentions could be displayed as “Listens” which would provide the canonical copy of the podcast some indicator of its popularity and actual audience. It is tremendously difficult to obtain data on the actual number of listens within most of the podcast community and typically a fraction of the number of downloads must be used as an indicator of the actual reach. Being able to display listens could potentially be a boon to the podcasting market, particularly with respect to advertising as this type of open social web functionality spreads.
Similarly read posts with the
read-of microformat and watches with
watch-of will be accepted and show up within the comments section. Like the previous types, they can be set to display as facepiles within the user interface.
Knowing that this read functionality would be available, this week I helped ColoradoBoulevard.net set up their site to be able to accept and display reads of their articles. Here’s an example from their site:
I haven’t yet seen one for watches in the wild yet, but maybe you’ll be either the first to send or receive one?
The microformats on these posts is generally considered to be experimental, but with the ~500+ users of this suite of tools as well as others who are already using them on other sites, they’ve now taken a dramatic step into the open internet and more widespread use and potential official adoption.
Editable Webmention Types and Avatars
Just yesterday, I spent a few minutes in the IndieWeb chat helping someone to laboriously delve into their mySQL databaset and find a particular snippet of data so they could manually change a received webmention from being a simple
mention to being a
reply so that it would display as a native comment on their website. I’ve often done this to take what sometimes seem like simple mentions and change them to replies to reveal the richer content they often contain for the broader conversation. Sadly the process is boring, laborious, and fraught with potential ways to mess things up.
As of this weekend, this process is no longer necessary. One can now go to the admin interface for their comments and webmentions (found at the path
/wp-admin/edit-comments.php), click on
edit for the particular comment they’re changing and then scroll down to reveal a droplist interface to be able to manually change the webmention type.
As another example of a use for this functionality, perhaps you’ve received a listen mention on one of your podcast episodes that has a lot of useful notes or commentary germane to your episode? Instead of hiding it as a simple listen, why not change the type to
reply to allow a richer conversation around your content? After all, with a reasonable reply it will be implicit that the commenter actually listened to the episode, right?
Because there is currently no functionality in WordPress for saving or caching the avatars of commenters via webmention, when users change their profile images on siloed services like Facebook, Twitter, et al. the link to their old avatars quits working and they were displaying blank spaces. This is an unfortunate form of linkrot, but one that can become more visually apparent over time.
As one can see in the image for the commenting edit box above, the field for the
Avatar is now editable. This means one can update out-of-date or blank avatars. One now also has the ability to moderate/edit or easily remove/switch avatars if users are sending inappropriate photos for one’s site’s audience.
In addition to being dead simple to use to track my reading, I love that Reading.am is able to add things I’m currently listening to and watching. Even better, some sites like Huffduffer.com dovetail with it incredibly well and provide in-line audio files without needing to click through to the original. What a lovely win for UI!
I don’t really think of it as a “podcast” per se, but since I make “listen” posts of all the various podcasts and audio I listen to and the vast majority of those posts include direct links to the audio files, my own listen feed essentially becomes a self-published podcast of all the stuff I’m listening to that others could potentially consume. Maybe I should call it a faux-cast?
Here’s the link you can use to subscribe in your favorite podcatcher: http://boffosocko.com/kind/listen/feed/
Perhaps one day I’ll do more with feed validation and submit it to various distribution channels to make searching/subscribing easier, but since I’m not really “promoting” it as anything other than a means of discovery (or extreme stalker behavior) I won’t take the time now.
As I think about creating “want” posts in the near term, perhaps I’ll create a feed of want-to-listen-to items as another discovery channel option as well. In some sense, this is how I use my Huffduffer.com account. It has a subscribe-able list of audio items I want to listen to at some point in the future. Since I can add my Huffduffer feed (or those of others) to my podcatcher, it helps enable me to easily get the content to my phone or other devices to listen to a variety of new things. There’s no reason not to do all of this on my own site explicitly.
Now if only podcatchers could support micropub for more easily creating scrobbles or “listens”…