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?"