search

igniterealtime / openfire-fastpath-plugin

Adds support for managed queued chat requests, such as a support team might use
5 stars 12 forks source link

Converse end-user UI does not get notified of rejection #48

Closed guusdk closed 3 years ago

guusdk commented 3 years ago

When all agents reject (or not answer) a request to chat, a rejection is sent back to the client. The stanza looks like this:

<message xmlns="jabber:client" from="demo@workgroup.fastpath.goodbytes.im" to="23cxyv12z9@fastpath.goodbytes.im/23cxyv12z9"><depart-queue xmlns="http://jabber.org/protocol/workgroup"><agent-not-found/></depart-queue></message>

The Converse-based front-end does not seem to pick up this event. It keeps showing a spinner. A user has no way to know that he'll never be answered. The spinner should be replaced.

deleolajide commented 3 years ago

When the workgroup queue is closed, the converse client joins the visitor to a default public MUC with the same name as the workgroup. See https://github.com/guusdk/openfire-fastpath-plugin/blob/64d9a35e693ec7429d958dc1cc6d7e03738566ae/classes/ofmeet.js#L114

When no agent accepts the offer to chat and the visitor departs from the workgroup queue, the same user experience as a closed queue should occur: the visitor joins a public MUC with the same name as the workgroup. See https://github.com/guusdk/openfire-fastpath-plugin/commit/5adf07c209703345628aa0113e6323271f458d61#

guusdk commented 3 years ago

Ah, is "joining a MUC room with no-one it it" desired behavior? I assumed it was a bug (see https://github.com/igniterealtime/openfire-fastpath-plugin/issues/49) What's the rationale for this? I would think it is confusing for people, looking for help, joining a chat room where there's no-one else.

deleolajide commented 3 years ago

What's the rationale for this?

Every workgroup has a private MUC for conversations between agents. Likewise it should have a public MUC for community discussions between visitors to compliment the protected workgroup MUCs between agents and visitors. This is the overall vision driving the implementation

image

guusdk commented 3 years ago

Having a deployment that provides both "group meetings" for clients/customers as well as "live chat" opportunities (where clients/customers can engage directly with staff/agent on a specific topic) is great, and often desirable. No argument there.

However: I see primarily downsides of trying to achieve both in FastPath. They're two very distinct bits of functionality.

Specifically, I'm worried that having just one button that, depending on state that can't be predicted by an end-user, will forward a user to one or the other, to be very, very confusing.

FastPath is something that allows clients/customers to seek help with a staff member/agent. Having/hosting a chatroom for a community is excellent, but is something quite different. In a deployment, this should primarily be made available through different UI elements (and not all under the same button). Also, I can imagine that plenty of people, for reasons that aren't really important for this discussion, explicitly do not want their clients talking amongst themselves.

My suggestion would be to not fallback to a 'community chat' at all, at least not by default, and very much not without first warning the end-user that they're not going to talk to staff/agent. I suggest that we utilize and extend the 'offline settings' that are already implemented. Right now, FastPath can already be configured to either present an email form, or redirect to a website, when a queue is not available. We can extend this with 'redirect to chat room' or something like that, and, if I understand you correctly, achieve the same thing that you're after. The benefit of going down this path is that we're not hard-coding it in the user-facing client.

deleolajide commented 3 years ago

My suggestion would be to not fallback to a 'community chat' at all, at least not by default, and very much not without first warning the end-user that they're not going to talk to staff/agent. I suggest that we utilize and extend the 'offline settings' that are already implemented. Right now, FastPath can already be configured to either present an email form, or redirect to a website, when a queue is not available. We can extend this with 'redirect to chat room' or something like that, and, if I understand you correctly, achieve the same thing that you're after. The benefit of going down this path is that we're not hard-coding it in the user-facing client.

👍

guusdk commented 3 years ago

Alrighty then. I have raised #51 to track that.