I announced recently that Bridgy Publish for Facebook would shut down soon. Facebook’s moves to restrict its API to improve privacy and security are laudable, and arguably ...
This is so disappointing. Facebook is literally killing itself for me. So much for their “connecting everyone” philosophy.
Brid.gy was the last thing really keeping me connected to Facebook at all. Now that Facebook is shutting down its most useful functionality from my perspective, perhaps it’s time to deactivate it and move toward shutting it all down?
This week, using the magic of open web standards, I was able to write an issue post on my own website, automatically syndicate a copy of it to GitHub, and later automatically receive a reply to the copy on GitHub back to my original post as a comment there. This gives my personal website a means of doing two way communication with GitHub.
This functionality is another in a long line of content types my website is able to support so that I’m able to own my own content, yet still be able to interact with people on other websites and social media services. Given the number of social sites I’ve seen disappear over the years (often taking my content with them), this functionality gives me a tremendously larger amount of control and ownership over my web presence and identity while still allowing me to easily communicate with others.
In this post I wanted to briefly sketch what I’ve done to enable this functionality, so others who are so inclined can follow along to do the same thing.
Setting up WordPress to syndicate to GitHub
I’ll presume as a first step that one has both a GitHub account and a self-hosted WordPress website, though the details will also broadly apply to just about any content management system out there that supports the web standards mentioned.
Register your GitHub account and your website with Bridgy
Ryan Barrett runs a fantastic free open sourced service called Bridgy. To use it you’ll need the microformat rel=“me” links on both your GitHub account and your website’s homepage that point at each other. GitHub will do most of the work on its side for you simply by adding the URL of your website to the URL field for your GitHub account at https://github.com/settings/profile. Next on your website’s homepage, you’ll want to add a corresponding rel=“me” link from your website to your GitHub account.
In my case, I have a simple widget on my homepage with roughly the following link: <a href="https://github.com/username">GitHub</a>
in which I’ve replaced ‘username’ with my own GitHub username. There are a variety of other ways to add a rel=“me” link to your webpage, some of which are documented on the IndieWeb wiki.
Now you can go to Brid.gy and under “Connect your accounts” click on the GitHub button. This will prompt you to sign into GitHub via oAuth if you’re not already logged into the site. If you are already signed in, Brid.gy will check that the rel=“me” links on both your site and your GitHub account reciprocally point at each other and allow you to begin using the service to pull replies to your posts on GitHub back to your website.
To allow Brid.gy to publish to GitHub on your behalf (via webmention, which we’ll set up shortly), click on the “Publish” button.
Install the Webmention Plugin
The underlying technology that allows the Bridgy service to both publish on one’s behalf as well as for the replies from GitHub to come back to one’s site is an open web standard known as Webmention. WordPress can quickly and easily support this standard with the simple Webmention plugin that can be downloaded and activated on one’s site without any additional configuration.
For replies coming back from GitHub to one’s site it’s also recommended that one also install and activate the Semantic Linkbacks Plugin which also doesn’t require any configuration. This plugin provides better integration and UI features in the comments section of one’s website.
Install Post Kinds Plugin
The Post Kinds Plugin is somewhat similar to WordPress’s Post Formats core functionality, it just goes the extra mile to support a broader array of post types with the appropriate meta data and semantic markup for interacting with Bridgy, other web parsers, and readers.
Download the plugin, activate it, and in the plugin’s settings page enable the “Issue” kind. For more details on using it, I’ve written about this plugin in relative detail in the past.
Install Bridgy Publish Plugin
One can just as easily install the Bridgy Publish Plugin for WordPress and activate it. This will add a meta box to one’s publishing dashboard that, after a quick configuration of which social media silos one wishes to support, will allow one to click a quick checkbox to automatically syndicate their posts.
Install the Syndication Links Plugin
The Syndication Links plugin is also a quick install and activate process. You can modify the settings to allow a variety of ways to display your syndication links (or not) on your website if you wish.
This plugin will provide the Bridgy Publish Plugin a place to indicate the permalink of where your syndicated content lives on GitHub. The Bridgy service will use this permalink to match up the original content on your website and the copy on GitHub so that when there are replies, it will know which post to send those replies to as comments which will then live on your own website.
You should now be ready to write your first issue on your website, cross post it to GitHub (a process known in IndieWeb parlance as POSSE), and receive any replies to your GitHub issue as comments back to your own website.
Create a new post.
In the “Kinds” meta box, choose the “Issue” option.
Type in a title for the issue in the “Title” field.
In the “Response Properties” meta box, put the permalink URL of the Github repopository for which you’re creating an issue. The plugin should automatically process the URL and import the repository name and details.
In the primary editor, type up any details for the issue as you would on GitHub in their comment box. You can include a relatively wide variety of custom symbols and raw html including
and with code samples which will cross-post and render properly.
In the GitHub meta box, select the GitHub option. You can optionally select other boxes if you’re also syndicating your content to other services as well. See the documentation for Bridgy and the plugin for how to do this.
Optionally set any additional metadata for your post (tags, categories, etc.) as necessary.
Publish your post.
On publication, your issue should be automatically filed to the issue queue of the appropriate GitHub repo and include a link back to your original (if selected). Your post should receive the syndicated permalink of the issue on GitHub and be displayed (depending on your settings) at the bottom of your post.
When Bridgy detects future interactions with the copy of your post on GitHub, it will copy them and send them to your original post as a webmention so that they can be displayed as comments there.
If you frequently create issues on GitHub like this you might want a slightly faster way of posting. Toward that end, I’ve previously sketched out how to create browser bookmarklets that will allow you one click post creation from a particular GitHub repo to speed things along. Be sure to change the base URL of your website and include the correct bookmarklet type of “issue” in the code.
The Post Kinds plugin will also conveniently provide you with an archive of all your past Issue posts at the URL http://example.com/kind/issue/, where you can replace example.com with your own website. Adding feed/ to the end of that URL provides an RSS feed link as well. Post Kinds will also let you choose the “Reply” option instead of “Issue” to create and own your own replies to GitHub issues while still syndicating them in a similar manner and receive replies back.
Given the general set up of the variety of IndieWeb-based tools, there are a multitude of other ways one can also accomplish this workflow (both on WordPress as well as with an infinity of other CMSes). The outline I’ve provided here is one of the quickest methods for beginners that will allow a relatively high level of automation and almost no manual work.
One doesn’t necessarily need to use the Post Kinds Plugin, but could manually insert all the requisite HTML into their post editor to accomplish the post side of things via webmention. (One also has the option to manually syndicate the content to GitHub by cutting and pasting it as well.) If doing things manually this way is desired, then one will need to also manually provide a link to the syndicated post on GitHub into their original so that Bridgy can match up the copy and the original to send the replies via webmention.
If you’ve followed many of these broad steps, you’ve given already given yourself an incredibly strong IndieWeb-based WordPress installation. With a minimal amount of small modifications you can also use it to dovetail your website with other social services like Twitter, Facebook, Flickr, Instagram, Google+ and many others. Why not take a quick look around on the IndieWeb wiki to see what other magic you can perform with your website!
I’ve documented many of my experiments, including this one, in a collection of posts for reference.
If you have questions or problems, feel free to comment below or via webmention using your own website. You can also find a broad array of help with these plugins, services, and many other pieces of IndieWeb technology in their online chat rooms.
...the issue for me was Known was contextless for social media. I often post across various sites in response to things and share my photos as part of a conversation, so doing it through Known seemed a bit like working in a vacuum. I use Twitter less and less for discussion, so I wonder if I would feel different about this now, but what I wanted from Known was a way to also view and respond to Tweets, Facebooks statuses, photos on Flickr, Instagram, etc. A kind of reader for my content that would collapse those various conversations for me, and I could respond through my Known as if I was within those apps. I increasingly thought Known would make an awesome read//write feed reader if it had such a feature. The main reason Known fell by the wayside for me was I was not using it to publish in all these spaces, rather doing it post-facto if at all. Does that make sense?
Interestingly, Known had a lot of these features hidden in code under the hood. Sadly they weren’t all built out. It in fact, did have much of a reader (something which Ben indicated they were going to take out of the v1.0 release to slim down the code since it wasn’t being used). It also had a follow/following block of code (and even a bookmarklet at /account/settings/following) so you could follow specific sites and easily add them to your reader. Also unbeknownst to most was a built-in notifications UI which could have been found at /account/notifications.
It’s a shame that they put many of these half-built features on hold in their pivot to focus on the education market and creating a viable cash flow based company as this is the half that most CMSs lack. (If you think about what makes Twitter and Facebook both popular and really simple, I think it is that they’re 95% excellent feed readers with 5% built-in posting interfaces.)
I’ve managed to replace some of that missing functionality with Woodwind, a reader at http://woodwind.xyz, which one could connect with Known to do the reading and then integrate the posting, commenting, and replies to complete the loop. I do have a few very serious developer friends who are endeavoring to make this specific feed reader portion of the equation much easier to implement (and even self-host) to make the hurdle of this problem far lower, but I suspect it’ll be another 3-6 months before a usable product comes out of the process. For those looking to get more social into their feed readers, I often recommend Ryan Barrett’s appspot tools including https://twitter-atom.appspot.com/ which has instructions for extracting content from Twitter via Atom/RSS. It includes links at the bottom of the page for doing similar things with Facebook, Instagram and Google+ as well.
Interestingly there are now enough moving pieces (plugins) in the WordPress community to recreate all of the functionality Known has, one just needs to install them all separately and there are even a few different options for various portions depending on one’s needs. This includes adding reply contexts for social media as well as both the ability to syndicate posts to multiple social sites for interaction as well as getting the comments, etc. backfeed from those social sites back into the comments section of your post the way Known did. Sadly, the feed reader problem still exists, but it may soon be greatly improved.
Our new book club reading is Cathy O’Neil’s Weapons of Math Destruction. In this post I’ll lay out a reading agenda, along with ways to participate.
The way people read along in this book club is through the web, essentially. It’s a distributed experience.
It occurs to me while reading the set up for this distributed online book club that posting on your own site and syndicating elsewhere (POSSE) while pulling back responses in an IndieWeb fashion is an awesome idea for this type of online activity. Now if only the social silos supported salmention!
I’m definitely in for this general schedule and someone has already gifted me a copy of the book. Given the level of comments I suspect will come about, I’m putting aside the fact that this book wasn’t written for me as an audience and will read along with the crowd. I’m much more curious how Bryan’s audience will see and react to it. But I’m also interested in the functionality and semantics of an online book club run in such a distributed way.
Today I’m happy to announce I’ve added a discussions section to the website, directly below each article. Here you’ll be able to directly respond to what you’ve just read, share your thoughts, and have a discussion with other readers of my site. Today’s post is going to take a bit of a look inside why I’m doing this and how discussions work.
Jason your blogpost does a great job of laying out the values (and distractions) of comments on blogs and why someone would want to have them. I particularly like your choice to call this area of his personal site a “Discussion” area instead of the traditional “Comments” moniker most would give it.
While you use the oft-quoted statement (usually said in a dismissive tone in my experience):
If you want to respond, do so on your own website and tell me.
in the section espousing not allowing comments, I realize that this long-held concept of writing on your own website not only has significant value, but that the Indieweb way of replying and utilizing Webmentions (with moderation enabled if one prefers) for the notifications portion adds even more tremendous value.
Far too often, either in a blog’s comments section or even within social media, it’s all too easy to post an ill-conceived or hurtful drive-by response. It takes little time and thought to say “me too”, “I hate you”, “insert slur here”, or even click an innocuous “like” button many which do nothing for the conversation or discussion being proffered by the site owner. Worse, a very small portion of the world will see that a reader took these actions because they don’t really reflect heavily, if at all, within the reader’s own online presence–who searches for comments others have made online? How would you easily? It’s usually in these interactions that only the writer who spent some significant time trying to communicate can be crushed by overwhelming negativity rather than being showered with the intelligence, logic, or forethought they deserve for putting themselves out there, much less receiving praise for their work. It’s no wonder that people prefer to turn off comments.
Earlier this evening as I was reviewing the online discussion from the San Francisco Homebrew Website Club, I saw a comment from bdesham captured by Tantek Çelik, “I heard not having comments on Tumblr was a deliberate design, to avoid abuse, so to comment you have to reblog?” I recall having an HWC at Yahoo’s LA headquarters and hearing from someone within Yahoo that indeed this was exactly the reason that drove this piece of UX/UI. If you wanted to comment on Tumblr, you had to repost the content to your own front page along with the comment. This meant that you had to take true ownership of your words as they appeared front and center on your own site there. Who wants to publicly mark themselves with a proverbial Scarlet Letter just to be mean? (Some will, but increasingly many won’t because it redounds directly to their reputation.) Perhaps this is why some of the most marginalized people on the internet heavily use Tumblr and feel safe within their communities there?
As some will know, for the past few years I’ve been using the W3C’s recommended Webmention specification, a sort of cross-website universal @mention or @reply, which I’ve implemented on WordPress with the Webmention plugin and a few others, to accept replies/comments and other associated interactions on my blog in addition to the traditional comments box. While the traditional comment box has largely been unused on my site–making it often feel in the early days like I was “spewing words out into the void” as Jason describes–the Webmention piece seems to have made a far larger difference to me.
The majority of the interaction my site receives comes via Webmentions from Brid.gy in the form of short one-offs or simple “likes” which are backfed from Facebook, Twitter, or Google+. However a growing number of interactions are actually interesting and more substantive discussions. It’s these more “traditional” replies via Webmention that have the most value to me. They are better thought out replies and helpful commentary, which almost always appear front and center on the commenter’s own site (much the way Tumblr designed theirs) before they ever appear on my site as a comment. As Jason astutely points out, having comments that are longer than 140 characters can be very valuable as well; since my commenters are posting on their own sites where they have ultimate freedom, most of them aren’t constrained in any way except perhaps for the amount of time they wish to take.
So here you are Jason, I’ve commented by posting on my own site first and notifying you by manually copying it to your discussion section where others can participate as well. (If you supported receiving Webmentions, the interaction would be automatic and nearly seamless.) I’m curious if you’d consider implementing the Webmention spec (both sending and receiving) on your website and if you think it would have the same intended effect you mean when you enabled “Discussions” on yours?–I know it feels like it has on mine.
If you care to reply back, feel free to reply on your own site, include a permalink to my original and use the manual Webmention form (below the traditional comment box) and click “Ping Me!” Of course, if you’re old school, feel free to dust off the old comment box and give that a whirl too!
Some additional miscellaneous thoughts, highlights, and short comments on Jason’s post:
Comments sections often become shouting matches or spam-riddled.
They can also become filled with “me too” type of commentary which more than often doesn’t add anything substantive to the conversation.
One of my all-time favorite comment moderation notes comes from the FAQ section of Peter Woit’s blog under “Why Did you Delete my comment?” He writes:
I delete a lot of the comments submitted here. For some postings, the majority of submitted comments get deleted. I don’t delete comments because the commenter disagrees with me, actually comments agreeing with me are deleted far more often than ones that disagree with me. The overall goal is to try and maintain a comment section worth reading, so comments should ideally be well-informed and tell us something true that we didn’t already know. The most common reason for deleting a comment is that it’s off-topic. Often people are inspired by something in a posting to start discussing something else that interests them and that they feel is likely to interest others here. Unfortunately I have neither the time nor inclination to take on the thankless job of running a general discussion forum here.
I hope my thoughts pass the Woit-comment-test for Jason.
For a website the size and popularity of Daring Fireball, it’d probably be madness to foster any kind of coherent conversation.
Certainly to do it without a staff would be difficult… Again here, Audrey Watter’s post about turning off comments indicates to some extent that even though she views her site as her personal blog, it’s audience, like that of Daring Fireball, has gotten so large that it’s not just friends, family, and community, but something beyond “community” (beyond the pale) that changes the dynamic of accepting comments.
I never felt like I was talking with anyone or anyone’s website, but more like I was spewing words out into the void.
I often feel this way, but supporting Webmentions and backfeed has largely negated these feelings for me in the last few years. I can now communicate directly with websites (and their authors) that support these open protocols.
It has the added benefit of making one-word smart-ass posts impossible.
I do remember the days of old, when people would comment “First!”, but beyond that #OneWordSmartAss is usually overrated unless you’re a professional comedian like Jon Stewart.
The evolution of comments on articles takes a new journalistic turn
Outside Your Bubble
This past Wednesday, BuzzFeed rolled out a new feature on their website called “Outside your Bubble”. I think the concept is so well-described and so laudable from a journalistic perspective, that I’ll excerpt their editor-in-chief’s entire description of the feature below. In short, they’ll be featuring some of the commentary on their pieces by pulling it in from social media silos.
What is interesting is that this isn’t a new concept and even more intriguing, there’s some great off-the-shelf technology that helps people move towards doing this type of functionality already.
The IndieWeb and backfeed
For the past several years, there’s been a growing movement on the the internet known as the IndieWeb, a “people-focused alternative to the ‘corporate web’.” Their primary goal is for people to better control their online identities by owning their own domain and the content they put on it while also allowing them to be better connected.
As part of the movement, users can more easily post their content on their own site and syndicate it elsewhere (a process known by the acronym POSSE). Many of these social media sites allow for increased distribution, but they also have the side effect of cordoning off or siloing the conversation. As a result many IndieWeb proponents backfeed the comments, likes, and other interactions on their syndicated content back to their original post.
Backfeed is the process of pulling back interactions on your syndicated content back (AKA reverse syndicating) to your original posts.
This concept of backfeed is exactly what BuzzFeed is proposing, but with a more editorial slant meant to provide additional thought and analysis on their original piece. In some sense, from a journalistic perspective, it also seems like an evolutionary step towards making traditional comments have more value to the casual reader. Instead of a simple chronological list of comments which may or may not have any value, they’re also using the feature to surface the more valuable comments which appear on their pieces. In a crowded journalistic marketplace, which is often misguided by market metrics like numbers of clicks, I have a feeling that more discerning readers will want this type of surfaced value if it’s done well. And discerning readers can bring their own value to a content publisher.
I find it interesting that not only is BuzzFeed using the concept of backfeed like this, but in Ben Smith’s piece, he eschews the typical verbiage ascribed to social media sites, namely the common phrase “walled garden,” in lieu of the word silo, which is also the word adopted by the IndieWeb movement to describe a “centralized web site typically owned by a for-profit corporation that stakes some claim to content contributed to it and restricts access in some way (has walls).”
To some extent, it almost appears that the BuzzFeed piece parrots back portions of the Why IndieWeb? page on the IndieWeb wiki.
Helping You See Outside Your Bubble | BuzzFeed
A new feature on some of our most widely shared articles.
BuzzFeed News is launching an experiment this week called “Outside Your Bubble,” an attempt to give our audience a glimpse at what’s happening outside their own social media spaces.
The Outside Your Bubble feature will appear as a module at the bottom of some widely shared news articles and will pull in what people are saying about the piece on Twitter, Facebook, Reddit, the web, and other platforms. It’s a response to the reality that often the same story will have two or three distinct and siloed conversations taking place around it on social media, where people talk to the like-minded without even being aware of other perspectives on the same reporting.
Our goal is to give readers a sense of these conversations around an article, and to add a kind of transparency that has been lost in the rise of social-media-driven filter bubbles. We view it in part as a way to amplify the work of BuzzFeed News reporters, and to add for readers a sense of the context in which news lives now.
And if you think there’s a relevant viewpoint we’re missing, you can contact the curator at firstname.lastname@example.org.
The big caveat on this type of journalistic functionality is that it may become a game of diminishing returns. When a new story comes out, most of the current ecosystem is geared too heavily towards freshness: which story is newest? It would be far richer if there were better canonical ways of indicating which articles were the most thorough, accurate, timely and interesting instead of just focusing on which was simply the most recent. Google News, as an example, might feature a breaking story for several hours, but thereafter every Tom, Dick, and Harry outlet on the planet will have their version of the story–often just a poorer quality rehash of the original without any new content–which somehow becomes the top of the heap because it’s the newest in the batch. Aram Zucker-Scharff mentioned this type of issue a few days ago in a tweetstorm which I touched upon last week.
Worse, for the feature to work well, it relies on the continuing compilation of responses, and the editorial effort required seems somewhat wasted in doing this as, over time, the audience for the article slowly diminishes. Thus for the largest portion of the audience there will be no commentary, all the while ever-dwindling incoming audiences get to see the richer content. This is just the opposite of the aphorism “the early bird gets the worm.” Even if the outlet compiled responses on a story from social media as they were writing in real time, it becomes a huge effort to stay current and capture eyeballs at scale. Hopefully the two effects will balance each other out creating an overall increase of value for both the publisher and the audience to have a more profound effect on the overall journalism ecosystem.
Personally and from a user experience perspective, I’d like to have the ability to subscribe to an article I read and enjoyed so that I can come back to it at a prescribed later date to see what the further thoughts on it were. As things stand, it’s painfully difficult and time consuming as a reader to attempt to engage on interesting pieces at a deeper level. Publications that can do this type of coverage and/or provide further analysis on ongoing topics will also have a potential edge over me-too publications that are simply rehashing the same exact stories on a regular basis. Outlets could also leverage this type user interface and other readers’ similar desire to increase their relationship with their readers by providing this value that others won’t or can’t.
In some sense, some of this journalistic workflow reminds me how much I miss Slate.com’s Today’s Papers feature in which someone read through the early edition copies of 4-5 major newspapers and did a quick synopsis of the day’s headlines and then analyzed the coverage of each to show how the stories differed, who got the real scoop, and at times declare a “winner” in coverage so that readers could then focus on reading that particular piece from the particular outlet.
Backfeed in action
What do you think about this idea? Will it change journalism and how readers consume it?
As always, you can feel free to comment on this story directly below, but you can also go to most of the syndicated versions of this post indicated below, and reply to or comment on them there. Your responses via Twitter, Facebook, and Google+ will be backfed via Brid.gy to this post and appear as comments below, so the entire audience will be able to see the otherwise dis-aggregated conversation compiled into one place.
If you prefer to own the content of your own comment or are worried your voice could be “moderated out of existence” (an experience I’ve felt the sting of in the past), feel free to post your response on your own website or blog, include a permalink to this article in your response, put the URL of your commentary into the box labeled “URL/Permalink of your Article”, and then click the “Ping Me” button. My site will then grab your response and add it to the comment stream with all the others.