-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "Typing" message for automatic replies #3029
Comments
There is one caveat I "discovered" yesterday: the first response should be ignored as it is returned every time and is returned "quickly". This message usually just says that our bot is going to try to answer. |
@svenseeberg can you clarify a little more why we should not display the typing indicator in that case? Our current polling interval is 16s, so the user might have to wait 16s until he gets the automatic message. I think that is not really quick. Or do you mean the typing indicator should still be shown after the first automatic response because we are still going to receive the chatbot message? |
Yes the first message, that comes back within seconds, should be ignored. This is always the same boiler plate that is not really relevant.
The real automatic response takes about 60s. However, the user has no idea how long it will take. Indicating that a message might come back is IMHO useful to keep the user waiting for that amount of time. If no message arrives within 60 or 90s, usually the back end is broken and no automatic answer will arrive (soon). |
We discussed the topic in person and the result was the following:
|
As long as we expect automatic replies, we should show a placeholder message with 3 dots (...). This is the default indicator that the other side is typing. This message should be shown for about 60s when the last message is a user message. After 60s the message should disappear.
This is not a perfect mechanism but should do the trick in most cases. It will provide a hint to the user that an answer can most likely be expected. We have no good indication (yet?) for the front end that the back end is still working on an answer.
In the long run we probably want to indicate that the back end is actually working on an answer. However, this is only in reach when we merge the chat back end into the Integreat CMS and start implementing websockets.
Additional information
Tracking issue in integreat-chat: digitalfabrik/integreat-chat#120
The text was updated successfully, but these errors were encountered: