README
noflo-rsf
Welcome to the Rapid Sensemaking Framework ecosystem entry point!
- Skip to
Using the RSF App
- Skip to
Principles
- Skip to
RSF Components
- Skip to
RSF Contactables
- Skip to
Using Flowhub for Deep Design
What Is The "Rapid Sensemaking Framework"?
The rapid sensemaking framework is a set of tools designed to facilitate human conversation, ideation, reasoning, and decision taking at a large scale.
Common processes for gathering human expressions (be they ideas, questions, claims, votes, edits, etc) are encoded as pluggable open-source modules that can reach across the various digital devices and applications we commonly use.
Skilled facilitators and process designers can use the rapid sensemaking framework to conduct and unfold processes for ideation, discussion, evaluation, and decision making.
Inspirations and related projects include the likes of
- Kialo
- tool to engage in thoughtful discussion, understand different points of view, and help with collaborative decision-making
- Pol.is
- helps organizations understand themselves by visualizing what their members think. Get a clear picture of all the points of view to help move a conversation forward.
- Twitter Polls
- Slido
- Audience participation platform (corporate), Q&A and polling platform
- Teeming
- Poll Everywhere
- Pulse Sense Evolve
- Groupmap
- capturing individual thinking, revealing the group perspective, all in real-time. Collaborative decision making.
- All Our Ideas
- start with a question and some seed ideas and create a "wiki survey". The best ideas bubble to the top.
- Stormz
- enables you to design and facilitate collective intelligence sessions to test participant's knowledge, foster meaningful conversations, co-create solutions and make informed decisions.
- Codigital
- "Real-Time Ideas Engine". For large groups to generate, prioritize and refine ideas.
- Loomio
- helps people have discussions and make decisions together
- Assembl
- massive collective intelligence is the capacity to mobilize communities on a large scale (hundreds and thousands of participants) around key stakes and challenges to co-create new solutions in a short space of time
- IdeaLoom
- sister project to Assembl
- allows large communities to hold a meaningful conversation at scale, reach a common understanding, and develop solutions beyond what each participant could have envisioned
The basic tenets are
- ideation
- evaluation and ranking, sorting
- selection, voting, consenting
Apart from a few integrations, such as ones that Loomio has with Slack, these platforms require participants to join a new platform, and familiarize with a new tool. The RSF assumes the opposite, and brings the conversation to an already familiar space to participants: a chat platform they're already using. The process designer can even specify different people as reachable on DIFFERENT platforms, and the process can still be conducted.
Using the RSF App
For any good "conversation", there is always a frame. The conversation, at least loosely, has a direction that the people who will participate in it are agreeable to and interested in. Divergent phases and convergent phases of the conversation should nicely flow and blend.
So someone who has a frame for a conversation, and wants to foster engagement begins with a selection of available recipes for a social process. Things that this person would be tuning could include amount of time available for each part of the process. Loomio includes some wonderful help text explaining best practices for using the powerful tools in the decision/polling toolbox of Loomio.
As they draft the flow, they setup either an opt-in process where participants will select themselves, or if they have verbal or written consent via a personal connection, they could input each participant. To input a participant just requires adding the relevant info for the contact method they want to connect via, such as email, text, or something else.
Configure Public Link
Participant Registration at the Public Link
Finally, kickoff the process...
A live dashboard of events taking place in the process, and results coming in are viewable.
Once every step of the process has completed, the final results are saved to the computer that was hosting the process. From there, they could be uploaded to somewhere available online, or posted into a database for longevity.
This app is currently a work in progress, under development at the rsf-electron repository. In the future it will be available for download there.
Principles
The tools should offer participants in processes as much transparency into the process as makes sense for the use case. In most cases, all the participants should have the results of the entire process, rather than constrict the results to the facilitator. The process should benefit everyone, and be non value extractive in its approach to working with data.
RSF Components
Components are little modules of code. These operations can either be very quick, just performing a very simple transformation on data, requiring no human input, or they can involve lots of human input, and be medium to long running operations, meaning they could take days or weeks.
A component can do whatever it takes to ingest and coordinate this human input, which will very likely involve standing up web servers, and other connection/protocol variants.
At the time of writing, just a few components of interest have been developed, that are made to be plug and play with one another.
- CollectResponses
- for a prompt, collect statements numbering up to a given maximum (or unlimited) from a list of participants
- ResponseForEach
- for a list/array of statements, collect a response or vote (from a limited number of valid options, or unlimited) for each from a list of participants
- PairwiseComparison
- input: a list of statements, process: have all participants choose preferences between pairs of statements, return the list of compared/ranked results.
- PairwiseComparisonQual
- like PairwiseComparison, but allows for freeform response to the relationship between the two compared elements
- PairwiseComparisonQuant
- like PairwiseComparison, but allows for numerical quantified response to the relationship between the two compared elements
- ParticipantRegister
- input: nothing, process: spin up a form on a webserver and collect peoples contact info that opt in to participate, output: a list of Contactable participantConfigs
- FormatReactionsList
- input: reactions list (from ResponseForEach), output: a string containing a nice, simple, human-readable version of the results
- FormatStatementList
- input: statement list, output: a string containing a nice, simple, human-readable version of the results
- SendMessageToAll
- Send a given string to a list of given people (by contactableConfigs). Useful in a wide array of circumstances.
- SortPairwiseResults
- Take a list of
statements
and a list of votes fromPairwiseComparison
and sort the list by the votes.
- Take a list of
Lots of other Components have already been considered for implementation, for example
- SortFullList
- a 'social sort' algorithm
- DotVote
- a classic dot vote process, where people have a designated number of 'dots' to distribute across a variety of options given
- PickFromFullList
- select one, or a few, from a longer list
Other ideas:
- run results through analysis algorithms for useful stats
- publish results to spreadsheets
- publish results to api endpoint
- export results for CSV download
The idea is that each component should clearly define what properties or values it expects as input, and what properties or values it returns as output, if its successful.
By doing so, RSF Components can build up as a library over time, and where outputs of one component match the inputs of another,
those components can be strung together into more complex sequences. They could start to be combined in many different orders and in many different ways. For example, the output of CollectResponses
feeds nicely into the statements
input of ResponseForEach
.
Using Flowhub for Deep Design
- Use flowhub to design a process... you can actually run it that way too.
- https://app.flowhub.io
RSF Contactables
Contactables are at the heart of the Rapid Sensemaking Framework. They represent a way to open up bi-directional channels of communication between a "bot", and a human, represented in the most basic form of digital communication, strings of text.
A Contactable represents the idea that the Component can "hear" a person, and a person can "hear" a Component. Thus, the API for a Contactable is literally as simple in node
as .speak()
, .listen()
. The full API will be defined soon.
Each Contactable will represent an ability to bi-directionally communicate with a human, via the same API, independent of what technology and protocol is carrying the communications.
Configurations for people will be given as arrays in participantsConfig
, and the Components will carry out their operations, independent of what channels they are communicating via, thus enabling the full cross-platform cross-protocol solution.
A personConfig
object will be at a minimum something like:
{
"type": "sms",
"id": "+12223334444"
}
"name"
is treated as an optional property
At the time of writing, Components that use Contactables include PairwiseComparison, CollectResponses and ResponseForEach.
There is a module that collect a participantsConfig
array as an output, which can then be fed in to another module. That is ParticipantRegister.
Implementations So Far
rsf-contactable is the main source of information on implemented carrier types, but here is a short and simple list:
- rsf-smsable implements a texting carrier, via the Twilio APIs
- the
type
to give as apersonConfig
JSON object isphone
and the format ofid
must be like '+12223334444' (North American)
- the
- rsf-mattermostable implements a Mattermost carrier, via the Mattermost APIs
- the
type
to give as apersonConfig
JSON object ismattermost
and the format ofid
must be like 'username@https://mattermost-server.com'
- the
- rsf-telegramable implements a Telegram carrier, via the Telegram APIs
- the
type
to give as apersonConfig
JSON object istelegram
and the format ofid
must be like 'username'
- the
Work In Progress
Implementations under consideration:
- rsf-messenger (fb)
- rsf-emailable
- rsf-matrix
- rsf-twitter
Challenges
The biggest challenge so far encountered is rate limits on APIs. This constrains the number of messages that can be sent by a "bot" within a certain period of time, limited differently depending on the system. If the contactable implementation doesn't take that into account, some messages will be dropped, which breaks the viability of the system. It is important to research the rate limits of a given system and make sure that an implementation conforms to them.
Contactable API Specification
Please write other Contactable carriers, simply conforming to this minimal API! To get them fully implemented, please submit a PR to rsf-contactable.
constructor(id, name)
id
: string
, this value should represent the full information required to contact a person via the type of carrier it is over. For example, if type
is phone
, then id
should be of the format +12223334444
, but if type
is email
then id
should be a valid email, e.g. person@somesite.com
name
: string
, optional, a name which can be used throughout the Components at times to address the person in a more congenial way, during communications with them, if appropriate.
.speak(text: string): Promise<void>
Send a string of text to the person represented by the given Contactable.
Todo
- update .speak API so that it returns a promise that resolves when confirmation that the message has successfully been sent and received occurs. this will allow finer control of flow important in modules.
.listen(callback(text: string) => void): void
Set a function which will be called any time that the person represented sends a string of text back to the Component.
.stopListening(): void
Calling this will prevent any and all callbacks passed to listen
from firing again. Should be called as cleanup after use.
: .idstring
The id
of the person given to the constructor
function.
: .namestring
The name
of the person given to the constructor
function.
Valid noflo port datatypes are: all, string, number, int, object, array, boolean, color, date, bang, function, buffer, stream
Contributors
Code Contributors
This project exists thanks to all the people who contribute. [Contribute].
Financial Contributors
Become a financial contributor and help us sustain our community. [Contribute]
Individuals
Organizations
Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]