What are ADN Broadcast Channels, what could they become? Could a variant be used to reduce the noise and save our streams?
At first glance, App.net’s new Broadcast feature could be seen as just an RSS replacement; dig a little deeper and you might see some parallels with Twitter’s emergency alerts but what exactly is it?
Dalton Caldwell describes broadcasts over at the App.net blog as follows:
“A Broadcast is a new type of message that is always received as a push notification. A user only receives a Broadcast when they have explicitly subscribed to a Broadcast Channel. No “promoted content”, no black box algorithms, just a simple way to subscribe to valuable information that might otherwise get missed in a busy feed or overloaded inbox.”
The idea is for anyone to be able to publish and subscribe to push notifications about anything as long as it can push alerts to a broadcast channel via the API.
Do we need more notifications?
You may be forgiven for wondering why we would need yet another subscription/notification system and, on the face of it, I would agree but Caldwell makes an important point when defining how broadcasts should be used:
“A good Broadcast Channel will send at most 1-2 Broadcasts per day, and most likely even fewer. A successful Broadcast publisher will only publish the most important and high value messages to their subscribers.”
We respond more positively and consistently to notifications than to items contained within a pool of feeds so a system to reliably deliver important information that subscribers will both see and act upon is desired.
App.net is designed to act as a standard, open social platform (the emergence of the Twitter-like Alpha was largely a proof of concept) so the potential is for us to receive various notifications from anywhere on the web and have them all appear in the same place. Using one app to manage notifications – regardless of their source – makes far more sense than the current scatter gun approach requiring us to switch between multiple apps and services.
The intention is not to be yet another source of notifications but the source.
My immediate reaction in response to broadcast channels was that the process sounded similar to my idea for push curation last year?
While broadcasts are intended for high value, low volume notifications (no “promoted content”, no black box algorithms) I see no reason why the model could not be expanded for the purposes of social curation. Along with the targeted channels we could also have broader, more topic focused, dynamic subscriptions.
Perhaps we could set up channels based on user-created filters and the App.net Passport application (or similar) would let us build these filters from posts based on a range of criteria. If we are willing, I also don’t see why we could not subscribe to channels that are based on recommendations and algorithms.
When Google Reader was closing I said that it was a perfect opportunity for ADN to show it wasn’t just a Twitter clone. I also suggested that RSS functionality could be incorporated within a social network using Google+ as an obvious candidate.
Wheat from the chaff
While Broadcast aims to rescue the important notifications from the chat, we sometimes also need to rescue the chat itself from the deluge of links and shares.
One of my big criticisms of Twitter has been that it rapidly became a sea of links – the company calls itself an information network rather than a social one – so could a version of broadcast channels serve to keep curation within a social network but separate from the primary stream?
We like having curated links within a social network as it means we can get all of our news and conversation in one place but if curation overwhelms the social element, as it has done on Twitter, we start to lose out. A broadcast style arrangement could help us view exactly what we want if combined with better display and filtering options.
Maybe regular curators could use broadcast channels rather than sending shared content to the stream or links shared by “designated curators” could be automatically filtered. Normal client applications could include our subscriptions as well as our usual feeds – viewed separately or integrated based on personal preference.
Just the beginning
App.net still suffers from being considered an ad free, developer friendly alternative to Twitter rather than the social platform it actually is and Broadcasts is the first big attempt to demonstrate its possibilities.
Social news consumption has been touted as an RSS killer for a few years but never quite achieved it. I can imagine, however, that a derivative of Broadcast could become the mechanism for “push curation” letting us rescue our streams and still keep up to date with news or important updates via the same network.