blog: On broadcasting
'Broadcasting' (name subject to change) is the process of taking some content that's been worked on within a group, and promoting it into more visible locations & communication streams.
When Thiago and I did our three-hour braindump last Sunday, one concept emerged with particular clarity: something we expect groups will be doing, over and over again, is taking content (posts, events, maybe minutes, maybe discussions) they've worked on within the group and promoting it out into a more visible space in the network. e.g., to:
- The homepage for their group
- The homepage for their whole site
- Some broader channels (details TBD) that propagate through the FGA network
The name we were using for that process is broadcasting. Not perfect, subject to change, and all that, but it kinda captures the idea.
What's most important is that the idea has a consistency all the way from the user's experience into the backend implementation. Any given broadcast process has three parts:
- The actual content to be shared around or promoted. An event, a post/statement of some kind, a document; something that's been worked on in a group.
- A process for approving the broadcast. Ideally, this could encompass a number of group decisionmaking processes (simple poll, some kinda consensus thing), but initially it could just be group admin (ugh) approval.
- A broadcast space or target - basically, that first list.
For users, we can make this regular and structured: a button & subsequent workflow around performing this basic action which, while the content, process and broadcast targets change, the overall experience stays the same. When it's time for the group to put something 'out there,' someone can hit the button to start the process of getting it published, and the whole process that makes that happen is transparent. We'll need some good visual language and patterns around that process so that even as the individual components change, the experience and intuition stays the same. In the backend, this sort of modular architecture is excellent: by subdividing the task of broadcasting into these three clear, distinct stages, we make it easy to add new broadcast targets, new processes, and new types of content later on.
One note - it's not that content can only propagate through the network by going through a broadcast process. I'm expecting that people will be able to join and follow groups, including on remote sites, and see a full activity stream of everything that's happening. The power of the broadcast lies in the ability to create separate, special communication channels which will, presumably, be less noisy and contain more high-priority information as they cannot be populated unless a group has gone through some process to approve the message. Even if they turn out to be just as noisy, though, broadcasted messages that have been through a process let us know the answer to that constant question - "is this message just your opinion? or has it been through a group - and which group?"
Comments
I like the concept of 'broadcasting', especially because it's different than 'sharing' or even 'publishing'. One question though, if a piece of content is 'broadcast' by an individual and 'approved' by a group, might there need to be a way to set up a broadcast destination that bypasses the need for approval(s)?
For that matter, from an out-of-the-box user experience perspective, perhaps all the content sources can be un-approved, and then only those channels which elect to have an approvals process can do so, which helps Sam's thought that those channels which elect to have a transparent approval process will supposedly contain higher quality content. We hope. ;)
Can we also just state up front that already-broadcast content which is then edited by it's creator does not have to re-enter the broadcast approval process? Yes, yes, I know that it's the norm for magazines, newspapers, and corporation that haven't yet figured out how to "control" their online image, but it doesn't need to be enforced for the OWS movement's content. Too much overhead.
I like where Joel is going with the removal of bureaucracy related to broadcast edits. But there should then be a way (consensus-based?) to "de-broadcast" if the meaning has changed too much and the group no longer feels it represents the original intent.
I'm thinking an underlying concept will simply be that many public-facing group action will need to have a consensus/polling system in order to go through. Cool opportunity to use Drupal's Rules module to hook in here for actions.
This is dream-land territory, but this provides the future opportunity to have users with "social capital" (Whuffie), where their vote counts toward getting through this process quicker? So if an influential person (with plenty of positive reputation) flags an edited broadcast for de-broadcast, it might take less people than otherwise to get it removed. Anyhow, I'm being tangential :)