Simplify the user experience of activating a new integration #692

Open
timabbott opened this Issue Apr 22, 2016 · 1 comment

Projects

None yet

1 participant

@timabbott
Member

From @anteq's comments in #660:

"End users shouldn't have to create a "bot", remember the API key, create the URL on his own etc etc... Simplified UX in this case would involve Zulip generating the bot and correct webhook address automatically - user then would just have to copy and paste the generated webhook address. There could also be a place for customizing what types of messages should be posted and what should not - if every integration would explicitly define such message types, it should be possible to support user preferences in choosing which messages should be posted to Zulip and which shouldn't per integration.

Of course, the possibility of creating "raw" bots and "raw" webhooks should be preserved, for custom applications."

Another element that would be nice in this sort of thing is automatically suggesting a default avatar for the bot user from the logo for the integration on /integrations.html

@timabbott timabbott added this to the 2016 roadmap milestone Apr 29, 2016
@timabbott
Member

@TomaszKolek points in #709 out that we will likely end up needing to provide configuration pages for some more complicated bots to provide a reasonable UI for users to set the various settings involved with more complex webhook integrations.

I think to do this well we should start with adding support for a new type of bot user that only can send messages to webhooks. Here's a proposal for how to implement it:

  • Add a new field, is_incoming_webhook to UserProfile (default False)
  • Modify zerver/decorators.py to make is_incoming_webhook bots only able to send messages via the webhook API endpoints, and add tests for this restriction.
  • Add a toggle at the top of the "Add a New Bot" form on the /#settings page to control whether one is creating one of these webhook bots. I'd call the options "Incoming webhook" vs. "Custom Bot". Probably should have help text for the two options explaining the difference. The "Bot" option would work as bots do today.
  • If the user is creating a "Webhook integration", we can do stuff like:
    • auto-populate the default avatar with the logo we have on file for the integration (we'll probably need to add some new table to keep track of these).
    • Let the user pick a stream or stream(s) to send to via a pulldown list of streams in the realm.
    • Offer a custom per-integration configuration template to help the user configure the bot
    • etc.

I would do this project in stages that we try to finish and merge before getting too far into the next stage just to manage the complexity of the project:
(1) Create the "Incoming webhook" integration support, with none of the new features other than restricting to sending webhook messages.
(2) Then add the structures needed to make default avatars work (I think this will probably involve creating some data set of supported webhook integrations...).
(3) Then we can build on a configuration language for controlling what stream to send to, etc.

What do you think @TomaszKolek?

There is some previous work on adding support for hardcoding what stream integrations should send to that is enabled via setting exports.new_bot_ui = true in static/js/feature_flags.js, which doesn't really work and I don't think is totally the right direction but is worth looking at.

@timabbott timabbott modified the milestone: Zulip roadmap, Old roadmap Nov 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment