Dialogflow is a versatile platform that allows you to develop conversational experiences across a variety of platforms. It supports development not only for Google environments like Assistant and Hangouts but also for other companies’ platforms like Facebook and Slack. However, Google also offers its own Dialogflow Messenger platform. As a beta feature, Dialogflow Messenger may have limited support or incompatibilities with other products. It can be useful, though, for those starting to learn Dialogflow or for developing a quick MVP to test ideas. To fully realize these use cases, though, you need to be able to use rich message responses, like cards or buttons.
What does this richContent syntax provide that we can't get with markdown or HTML? Does this only work with Google frontends? Is richContent syntax usable in other messenger platforms. What features do I get in exchange for vendor "lock-in"?
Asking what features you get in exchange for the constraints of a vendor is important, but an answer to that needs to be based on the project context. What is the purpose of the project? What features are necessary for accomplishing the project? Do you need to leave space for the scope of the project to grow later (i.e., one year or several years later)? Are there any costs associated with such growth that would change the feasibility of continuing with one platform over another? Who is going to develop the project? Who is going to maintain the project? How much technical training do these maintainers have/need?
The rich response messages here are a way of adding content like cards or buttons to the Dialogflow Messenger. Other platforms, such as ManyChat, Rasa, and others, also allow for these features in their own way. Some platforms allow developers to use a GUI; others require some special syntax. Some platforms may not offer direct support for Markdown or HTML, and some organizations may not have the technical expertise to work with platforms that do.
The concept of vendor lock-in, in this case, has several dimensions.
The first is about rich responses themselves. Third-party services offer rich media that can be integrated into different platforms. These services represent a lock-in at the message level. These increase costs, perhaps unnecessarily, depending on what you are trying to accomplish. Working in Messenger with its native objects can be a cheaper, perhaps free, alternative until you need those third-party services.
The second is about the messenger platform. Dialogflow is a multi-channel platform. Designing a bot to work in Dialogflow Messenger does not preclude one from also making the bot accessible on other platforms, both within and outside of the Google ecosystem. Dialogflow allows one to set different responses for different platforms, such as Facebook, Slack, and Telegram. For example, you can add a different channel, then select rich responses relevant to that channel without this syntax. I have not experimented with these integrations fully, though.
Finally, lock-in could apply to the whole platform itself. Dialogflow allows one to export an entire project in JSON format. While this is a nice feature, realistically, exporting between chatbot platforms will take some work as each has different features and implementation strategies.
DialogFlow and its associated messenger are useful, but they may not be ideal for every organization or context. Scoping for a project generally should happen early in the project, and a big part of that is choosing the platform that accomplishes the goals for a project based on a realistic understanding of the context and the available platforms.
What does this richContent syntax provide that we can't get with markdown or HTML? Does this only work with Google frontends? Is richContent syntax usable in other messenger platforms. What features do I get in exchange for vendor "lock-in"?
Asking what features you get in exchange for the constraints of a vendor is important, but an answer to that needs to be based on the project context. What is the purpose of the project? What features are necessary for accomplishing the project? Do you need to leave space for the scope of the project to grow later (i.e., one year or several years later)? Are there any costs associated with such growth that would change the feasibility of continuing with one platform over another? Who is going to develop the project? Who is going to maintain the project? How much technical training do these maintainers have/need?
The rich response messages here are a way of adding content like cards or buttons to the Dialogflow Messenger. Other platforms, such as ManyChat, Rasa, and others, also allow for these features in their own way. Some platforms allow developers to use a GUI; others require some special syntax. Some platforms may not offer direct support for Markdown or HTML, and some organizations may not have the technical expertise to work with platforms that do.
The concept of vendor lock-in, in this case, has several dimensions.
The first is about rich responses themselves. Third-party services offer rich media that can be integrated into different platforms. These services represent a lock-in at the message level. These increase costs, perhaps unnecessarily, depending on what you are trying to accomplish. Working in Messenger with its native objects can be a cheaper, perhaps free, alternative until you need those third-party services.
The second is about the messenger platform. Dialogflow is a multi-channel platform. Designing a bot to work in Dialogflow Messenger does not preclude one from also making the bot accessible on other platforms, both within and outside of the Google ecosystem. Dialogflow allows one to set different responses for different platforms, such as Facebook, Slack, and Telegram. For example, you can add a different channel, then select rich responses relevant to that channel without this syntax. I have not experimented with these integrations fully, though.
Finally, lock-in could apply to the whole platform itself. Dialogflow allows one to export an entire project in JSON format. While this is a nice feature, realistically, exporting between chatbot platforms will take some work as each has different features and implementation strategies.
DialogFlow and its associated messenger are useful, but they may not be ideal for every organization or context. Scoping for a project generally should happen early in the project, and a big part of that is choosing the platform that accomplishes the goals for a project based on a realistic understanding of the context and the available platforms.