Conversations are an important topic when it comes to designing conversational interfaces, the key challenges here are -
1. Each platform has their own framework to handle conversations.
2. Being an emerging area of research - platforms upgrade often on in ways which might seem as deterrent for product teams to embrace, hence slowing down pace of adoption.
Although, there might be other factors depending on area of induction or technology used but above 2 are most common.
In this post, I am going to cover with the help of dialog flow as a conversational platform - some techniques which might be useful to streamline this change process quicker.
Each conversation architecture has some key components during conversation journey -
1. outgoing message interface - conversation prompt - modular input based on multi-modular spectrum - with connected devices.
2. conversation closing interface
3. conversation contexts
4. locations interface (this can include geographical & physical address)
5. storage interface (or caching)
6. service invocation interface
7. intent handler interface.
8. account linking & transactional interface
9. permissions interface.
The above interfaces form as key architectural units - the implementations can change but the essential point here is that even if a platform is going for an upgrade, your application framework & logic is decoupled with no impending impact.
There are multiple articles which cover migration strategies when migrating from any conversational platform like dialog flow v1 to dialogflow v2.
For e.g. - switching from tell to close or creating a suggestions object or permissions object via an available class rather than an assisted function or using promises to handle backend service calls.
A good article which covers this in the context of google is given below for reference -
https://medium.com/google-developer-experts/migration-points-for-upgrading-to-actions-on-google-nodejs-version-2-4640648ab8b5
Apart from this google has a bunch of documentation to support this (like the one here - https://dialogflow.com/docs/reference/v1-v2-migration-guide) but application development should be completely decoupled from the fact that any of the third party API can change and might not be backward compatible.
I am expecting a common framework to come into picture which establishes a convention to use conversational interfaces in the near future but the above core areas are fundamental to start with.
1. Each platform has their own framework to handle conversations.
2. Being an emerging area of research - platforms upgrade often on in ways which might seem as deterrent for product teams to embrace, hence slowing down pace of adoption.
Although, there might be other factors depending on area of induction or technology used but above 2 are most common.
In this post, I am going to cover with the help of dialog flow as a conversational platform - some techniques which might be useful to streamline this change process quicker.
Each conversation architecture has some key components during conversation journey -
1. outgoing message interface - conversation prompt - modular input based on multi-modular spectrum - with connected devices.
2. conversation closing interface
3. conversation contexts
4. locations interface (this can include geographical & physical address)
5. storage interface (or caching)
6. service invocation interface
7. intent handler interface.
8. account linking & transactional interface
9. permissions interface.
The above interfaces form as key architectural units - the implementations can change but the essential point here is that even if a platform is going for an upgrade, your application framework & logic is decoupled with no impending impact.
There are multiple articles which cover migration strategies when migrating from any conversational platform like dialog flow v1 to dialogflow v2.
For e.g. - switching from tell to close or creating a suggestions object or permissions object via an available class rather than an assisted function or using promises to handle backend service calls.
A good article which covers this in the context of google is given below for reference -
https://medium.com/google-developer-experts/migration-points-for-upgrading-to-actions-on-google-nodejs-version-2-4640648ab8b5
Apart from this google has a bunch of documentation to support this (like the one here - https://dialogflow.com/docs/reference/v1-v2-migration-guide) but application development should be completely decoupled from the fact that any of the third party API can change and might not be backward compatible.
I am expecting a common framework to come into picture which establishes a convention to use conversational interfaces in the near future but the above core areas are fundamental to start with.
No comments:
Post a Comment