Slack, Mattermost and similar tools integration

[mensch72]

It would be nice to integrate vodle polls with Slack, Mattermost, and similar tools, e.g.:

In those tools, ...

• get notifications about vodle polls
• discuss a vodle poll in a poll-specific dedicated channel
• set up a new vodle poll from within those tools, possible based on content from those tools?

[mensch72]

Slack

Maybe use this example to learn how to do it: https://github.com/slackapi/node-tasks-app

Things to decide:

• How much of vodle's functionality shall be accessible directly inside Slack, and what part of the functionality should rather be accessible from Slack via a link to the vodle web or native app. Based on this, decide whether a Slack "app" is needed or a Slack "workflow" suffices.
• Which form of communication between Slack user and vodle is most appropriate for each task: a message to or from a chat bot, a home page, a modal?
• How to enable polls with both Slack and non-Slack participants?

Resources on workflows:

• triggering a message from outside Slack via a webhook: https://slack.com/help/articles/360041352714-Create-more-advanced-workflows-using-webhooks

[mensch72]

Mattermost

Things to decide:

• What functionality (as in Slack)
• What Mattermost feature/technology to use: Slash commands, Webhooks, Apps, Plugins, Bots?
  • Overview: https://docs.mattermost.com/about/integrations.html
  • Apps are probably the best choice since they can be deployed to both cloud and non-cloud Mattermost servers, can be written in Typescript, and are powerful enough to offer things that slash commands or webhooks would not be able to do

[mensch72]

slash commands

Both Slack and Mattermost have "slash commands", so these could be valuable slash commands for a vodle plugin:

• /vodle new poll <Title> <Description> <URL> would set up a new poll in draft mode [with the optionally specified title [and description and/or url]] and return a link to its draft page in vodle. Once the poll is started in vodle, vodle would automatically place its invitation message into the channel.
• /vodle add option <Option Name> <Description> <URL> would return a link to the "add option" page for the last poll in this channel, [prefilled with the optional name [and description and/or url]]
• /vodle show would print a short report about the current state of the last poll in this channel and a recommendation between which options one might want to search for a compromise

[mensch72]

Revisiting this, I have asked ChatGPT about the prospects of a Slack integration:

Integrating vodle as a Slack app can be a compelling idea, especially if the standalone version struggles with user retention and iterative engagement. Here are several in‐depth considerations:
Strategic Rationale

• Contextual Integration:
In a standalone webapp, users often log in, perform an action, and may not return frequently. By moving the functionality into Slack—a platform where teams already communicate daily—you embed decision-making into regular workflows. This increased contextual relevance could boost both adoption and sustained engagement.
• Prompted Interactions:
Slack’s real-time notifications, reminders, and integrations (e.g., scheduled posts or slash commands) can encourage users to revisit and adjust their “waps” (votes or proposals). In environments where consensus is crucial, timely nudges can help nudge users into the iterative conversation needed to converge to consensus, countering the “one-shot” use observed in the standalone version.
Value Proposition

• Seamless Team Collaboration:
Slack is widely used in professional, creative, and technical teams. Incorporating vodle into Slack means that decision-making becomes part of everyday conversation. Users can vote on ideas directly within a channel, fostering collective ownership and a sense of immediacy.
• Reduced Friction:
Since users are already in Slack, there is no additional friction of switching contexts. This seamless integration could enhance the quality of discussions and the willingness to adjust earlier inputs based on group feedback.
• Enhanced Transparency and Accountability:
Displaying current standings, adjustments, and aggregate outcomes within the channel provides a record and encourages accountability. Moreover, interactive voting mechanisms could be designed to display how close the group is to consensus, which, in turn, may encourage continued participation.
Core Features for a Slack App Version

Interactive Voting Interface:
• Slash Commands and Message Actions: Utilize Slack commands (e.g., /vodle) so that users can quickly initiate a vote or update a previously cast “wap.”
• Message Buttons and Select Menus: Implement interactive components that allow users to adjust their votes (or conditional approvals) directly in the Slack interface.

Real-Time Notifications and Reminders:
• Automated Alerts: Send notifications when a voting round is about to close or when a new vote is initiated.
• Periodic Summaries: Provide short, digestible summaries of current consensus status.

Modal Dialogs for In-Depth Input:
• For more detailed input or when multiple parameters are required, modals can help guide users through rating or approving options (leveraging Slack’s modal interfaces).

Integrated Decision Analytics:
• Display graphical summaries or statistics (e.g., current probabilities for each option) using Slack’s Block Kit to craft visual components.

Historical Vote Archive:
• Let users query past decisions, track changes over time, and see how consensus evolved. This not only aids transparency but also reinforces the idea of iterative consensus building.

Adapting the GUI for Slack

• Minimal and Context-Rich Design:
Slack’s interface favors brief, succinct messages. Instead of traditional form fields, make use of Slack’s Block Kit elements (e.g., section blocks, divider blocks, interactive buttons) so that content is easy to consume within a conversation.
• Modals vs. Persistent Views:
For routine decisions, an in-line message update might suffice, whereas more complex decisions can pop up in a modal window. Design for both scenarios while ensuring that the core decision process remains intuitive. • Notification Strategies:
Adapt the design to work within Slack’s notification ecosystem; for example, using ephemeral messages for user-specific reminders or summaries to prevent clutter in general channels.
Marketing Considerations

Target Audience:
• Teams with Frequent Decision-Making Needs: Identify teams (product, operations, design, etc.) that routinely use Slack for collaboration.
• Niche Markets: Explore markets like remote agile teams, startups, or even online communities that desire more democratic decision-making processes.

Value Messaging:
• Position the app as a tool for democratizing decisions, reducing the “tyranny of the majority,” and ensuring that minority voices in discussions can have a proportional impact—an insight derived from the theoretical underpinnings of non-deterministic consensus models.

Integration Partnerships:
• Partner with companies whose culture values collaborative decision-making or fairness.
• Leverage Slack’s ecosystem (App Directory) for increased visibility.

Content Marketing and Case Studies:
• Publish white papers or case studies (possibly referencing the attached theory paper on non-deterministic proportional consensus) that detail how teams have improved decision quality and engagement.

Development Complexity and Workload Estimate

• Initial Research and Planning (1–2 weeks):
• Map current functionality to Slack’s API capabilities.
• Determine key interaction flows (e.g., initiating a vote, updating an input, reviewing results). • Prototyping (2–4 weeks):
• Develop an MVP using Slack’s Block Kit, interactive components, and modal dialogs.
• Integrate backend logic from the standalone webapp, adjusting for the event-driven environment of Slack. • Testing and Iterations (2–4 weeks):
• Conduct internal testing as well as a closed beta with real teams.
• Iterate based on usability feedback, paying attention to both interface intuitiveness and performance. • Deployment and Marketing (1–2 weeks):
• Configure app submissions to Slack’s App Directory and launch marketing efforts.

Overall, you might expect roughly 2–3 months of dedicated work for a well-polished Slack app version, assuming you have an existing codebase to adapt and a small team familiar with Slack APIs. For a solo developer or smaller team, this timeline could extend based on priorities and resource allocation.
Final Thoughts

Turning vodle into a Slack app aligns well with the goal of fostering iterative consensus-building. By embedding decision-making within the daily communication flow of teams, you increase the chance that participants not only contribute initially but also return to refine and adjust their inputs. From a technical standpoint, while there is a non-trivial amount of integration and redesign work involved, the payoff in engagement and relevance to modern collaborative workflows could be significant.

This hybrid approach not only leverages the theoretical foundation (as evident in the research on non-deterministic proportional consensus) but also meets practical needs in group decision-making contexts, offering both fairness and increased efficiency.

[mensch72]

A way easier start that might even solve our syncing issues would be to use the existing codebase to make a matrix/element-based solution:

• turn the ui into a matrix/element widgets (keeping most of the ionic frontend, running in an iframe)
• use the matrix protocol to pass data between voters' widgets, replacing the couchdb completely
• also use the matrix protocol to notify voters via dms or broadcast messages to the room, notifying them about events and asking them to open the widget.
• there is still a minimal role for an optional centralized component only to improve user experience: a matrix bot that can be added to a room and react to certain messages (similar to slash commands in slack), e.g. to add the vodle widget to the room or to send poll closing notifications. this bot server would not need to see any actual data.
• a general consequence of replacing the database server with in-matrix communication is the loss of anonymity since the sender of every message is identifiable at least on the api level (i.e., by a maliciously programmed client for example). so if privacy is a concern, a central bot is also needed for anonymization. it would be sent an encrypted DM that it would broadcast with the sender id removed.

as a first step, we should use make the current app optionally act as a matrix client (via https://github.com/matrix-org/matrix-js-sdk), using a user-specified matrix home-server (test with https://github.com/element-hq/synapse) to store the user data and syndicate the poll data in the room state data of a poll-specific matrix room (bypassing the couchdb altogether): https://spec.matrix.org/latest/#room-structure

also see https://chatgpt.com/share/67f8e9e5-baf0-8003-9875-0b77381d9aca