Converse end-user UI does not get notified of rejection

[guusdk]

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="[email protected]" to="[email protected]/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]

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 guusdk@5adf07c

[guusdk]

Ah, is "joining a MUC room with no-one it it" desired behavior? I assumed it was a bug (see #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]

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

[guusdk]

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]

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]

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