An audience/context-conscious POSSE syndication plugin for WordPress
In my January post titled Identity, content, audience and the (independent) web, I described the approach of using a self-owned website as the primary place to publish online content, while sending out (“syndicating”) copies of the content to social platforms. My motive was to reflect on some of the implicit social aspects.
In the discussion presented, it became evident that the so called “silos” of third-party social network services can not be treated as just outlets for content syndicated from the central master hub, but that each of these services has its own context of audience and identity to be considered in creating or syndicating content within them:
The question of how to create/restore a more open web providing control over one’s own representation hovers around three core issues: identity, content, and audience. It needs to be considered how an independent identity is being established, how users control their content and how they can build and cater to an audience despite independent ownership of identities and full control over content.
I also referenced different views about whether pushing copies of self-hosted content into silos (the IndieWeb movement coined the acronym POSSE to describe it) or creating content in each service and aggregating it back to the own site (aka. PESOS) would be the better approach.
Yet, the main takeaway was that the key to a meaningful syndication strategy is selectivity: the context- and identity-aware choice where to create each piece of content and what parts of it to syndicate one way or the other.
After further contemplation, I was now ready to implement POSSE syndication on my site. Being a WordPress devotee, I did some research on the available options - namely Publicize, Social and SNAP - but could not find a solution that would meet my requirements (the plugins reviewed either were externally hosted or came with a big set of other features, while lacking something I wanted). So I set out to develop my own tailor-made plugin to test and verify my vision of how it could be done.
http://github.com/sebastiangreger/sg-syndication
The use case
Based on my considerations from the identity-content-audience model, I see a need to make syndication a conscious process. While it should not induce excessive cognitive overhead (i.e. slow down the publishing process), it has to go beyond automatic cross-publication of content - to ensure that the messages to the individual silos are signal, not noise.
The concept’s design drivers boil down to two core elements:
1. Intentional syndication
Syndication of newly created content is off by default (or on by default if defined so by a specific, user-made preset), but can be activated with one click in an unobtrusive UI during the publication process or at any point later.
This allows the author to choose what audiences a piece of content is relevant to or what identity context it contributes to; “talking to the silo audiences” becomes part of the publishing mindset. An author might curate different channels for different audiences, for example posting work-related content to one Twitter account, while preferring to post hobby-related content to another.
Automatic always-on syndication would limit the ability of the user to cater to the needs of their different audiences (e.g. business contacts receiving updates on kite surfing), so there is a clear need for a POSSE feature that chiefly treats publishing content as conversation not broadcast.
2. Editable messages
The post content for distribution to third-party services is automatically generated by the plugin (potentially using a templating feature), but presented for easy modification during the publishing process if needed or desired.
This empowers the user to further tailor a syndication message to the individual context of a service, for instance it allows to not just tweet “New blog post: Lorem ipsum” + URL, but to add Twitter-specific elements like “via”-references, hashtags or pinging contacts using their @-handle.
While auto-generated messages probably serve the majority of use cases (even more so if they can be templated), I believe that a POSSE plugin needs to allow the user to cater to the assumed readership of the syndicated message in the most intuitive way possible.
The sg-syndication plugin
With the goals set and an initial flow in mind, I set out to build an experimental prototype, following the IndieWeb principles of building software for own use, prioritizing UX/design and eating one’s own dogfood. In this first version, I added the two most relevant services for me personally: Twitter and Flickr.
The vision for the UI was very clear from the beginning and I was able to reuse code from earlier plugin work, while the backend parts with the APIs of Twitter and Flickr involved some more extensive research and learning.
a) The editor UI
On the post editor page, a small “Syndication” box is added, featuring a checkbox to turn on syndication of the post to an external service (ideally, this should even be part of the “Publish” box itself - a possible future update).
When checked, a text field with a pre-filled POSSE message is displayed and can be edited by the user. In the case of photo services (e.g. Flickr in this first prototype), the featured image of the current post is automatically inserted into the message.
To integrate syndication with the publishing process and avoid any additional interactions beyond the bare minimum (ticking the checkbox, to be considered as the equivalent to “starting a conversation within the silo”), I hooked the syndication trigger into the publishing/update flow of WordPress (i.e. clicking the blue “Publish” or “Update” button checks for selected POSSE services and carries out the API magic in the background). This also allows to syndicate a post already published, by simply selecting the POSSE service and saving an updated version of the post.
Obviously, one of the most important usability requirements is user feedback, therefore the plugin shows success/error messages after syndication has been triggered.
After a post has been syndicated to a service, the “Syndication” box displays a link to the third-party service (providing a possible anchor for later addition of edit/delete functionalities). Since the link is stored in the database, it can be used for other purposes like including it in a theme as rel-syndication meta link.
b) The settings UI
Since the syndication to external services is based on API interfaces, a good amount of access keys are needed. For now, I implemented a new “Syndication” settings page tothe WordPress Admin UI which provides both the information where to get the keys and the fields to add them to the database.
If this were ever to be developed into a consumer plugin, a simple plug-and-play design would be needed, as manually retrieving the required API keys actually turned out to be surprisingly tricky:
- The Twitter API requires a mobile phone activation for write access, but the “long flow” for users of telephone providers not supported by default (as for example all Finnish providers) did not seem to work; luckily I still had some old credentials from a discontinued application that I was able to re-assign.
- The Flickr API does not hand out the token (the third value required) in any other way than by responding to an application over the API, requiring the user to use a “fake app” to retrieve the string as required by this plugin in its current state.
The checkbox for a service is only presented in the editor UI if all required credentials have been submitted; if only partial data has been entered, the box on the edit screen displays a message with a link back to the settings page. If no services have been set up at all, the box always displays a “get started” link to this settings page.
c) The backend
On the backend side, the work on this plugin has (in addition to the standard UI and action hooks) mainly been about figuring out how to communicate with the APIs of Twitter et al. After some research, I chose codebird-php by Jublo IT Solutions (for Twitter) and phpFlickr by Dan Coulter for easy access to the communication layers. Both plugins worked fine out-of-the-box and truly made the communication with the services a charm.
Next steps
By collecting and reflecting on hands-on experience with this particular approach to POSSE - the main intention for creating the plugin - I aim to further examine the role of “silo audiences” and “silo identities” in the publishing process of syndicated content, as started in the posts from January.
I intend to add more services to the plugin as time allows or new needs emerge. In addition, I hope to have a chance to make the code more modular to allow for easier re-use and extension; right now, it still shows a lot of signs of a hacky prototype. But despite some rough edges it works as intended (at least for me) and the first syndicated messages have been sent.
Ultimately, this is a small first step in my explorations of how to potentially bring the benefits of an “IndieWeb” approach to the masses - or, as I wrote in my New Year’s post 2014 – time to fix the internet?!:
[…] how can we contribute to lowering the threshold for “non-geeks” to participate in an independent web or for enterprises and organisations to take the leap and build on the power of the web itself?
Apart from the impressive work being done around specific software platforms (e.g. Idno), I believe that the best way to promote this better way of doing things is to experiment with its integration in the world’s most popular CMS and personal blogging software, WordPress.
Does this approach to content syndication trigger any thoughts? Reply to the syndicated tweet, leave a comment/webmention below - in particular if you dare to try out the plugin yourself (and manage to obtain the required API access from Twitter/Flickr) I would be most happy to hear back!