Change conversation target automatically when buddies' availability changes

RESOLVED WONTFIX

Status

--
enhancement
RESOLVED WONTFIX
5 years ago
9 hours ago

People

(Reporter: florian, Unassigned)

Tracking

Details

(Whiteboard: [wanted])

(Reporter)

Description

5 years ago
*** Original post on bio 742 at 2011-03-28 20:48:00 UTC ***

When the buddy used for a conversation becomes offline (or "less available"?), the target of the conversation should be changed automatically to the most available/preferred buddy of the contact.

(I sometimes referred to this feature as "auto switch conversation target".)
(Reporter)

Updated

5 years ago
Blocks: 954133
(Reporter)

Updated

5 years ago
Whiteboard: [0.3-wanted]
(Reporter)

Comment 1

5 years ago
*** Original post on bio 742 at 2011-05-23 16:26:29 UTC ***

It's too late to start working on this for 0.3. We still want this for a later release.
Whiteboard: [0.3-wanted] → [wanted]
(Reporter)

Comment 2

5 years ago
*** Original post on bio 742 at 2011-05-26 09:35:13 UTC ***

This seems easy, but there are actually complicated implementation details.

Especially, if we suppose that all the buddies of the contact are connected from the same multiprotocol client, and that contact's network connection drops, and a few minutes later the connection gets back and all the buddies reconnect, how many target changes should we have in this case?
As a user I would expect 0. But if we pick the most available target each time the current one goes offline, we will change the target each time an account timeouts, and then each time an account reconnects (-> probably about a dozen target changes shown in the UI).
(Reporter)

Comment 3

5 years ago
*** Original post on bio 742 at 2011-05-26 09:36:37 UTC ***

The solution I thought (a while ago!) for this would be to do the target change after some delay, but do it immediately when the user is typing.

Comment 4

5 years ago
*** Original post on bio 742 by patrickjdempsey <pjdkrunkt AT lycos.com> at 2011-07-10 23:08:31 UTC ***

Some possible concerns here:

1. How would this impact a conversation if the buddy you are chatting with goes "invisible" but wishes to continue the conversation from that client?  I suppose if they type first it would be fine, but if I type first the message will go to a different client?  Would there be an exception for clients that are apparently logged off but sending messages?  Facebook may also have weird issues with status. 

2. If there is a temporary glitch: a bad connection or if your buddy had to restart their chat client, would the conversation resume to the original preferred client?  I could see this happening especially with Yahoo which is very sensitive to weak connections that other chat clients don't seem to have any problems with, and which has a bad habit of logging in and out automatically if you visit Yahoo Mail.  

3. SMS should probably be opted out.  It would be very unexpected for someone to suddenly get a text on their phone continuing a conversation they were having on their computer just because of a temporary glitch.  

Perhaps the switching shouldn't be instantaneous, but have a delay?  Facebook deals with missed chats by sending them as emails, and several other chat clients offer a "while you were out" missed messages system that works pretty flawlessly for conversations interrupted by temporary connection hiccups.  It feels like it would be awkward on the other end (and possibly viewed as over-aggressive) for a conversation to suddenly switch to a different client window.  There may also be important contextual pieces of the conversation left off, such as a link or the top half of a long quote.  It is a really cool idea though!
On the behalf of Florian:
Closing bugs related to the Instantbird UI as WONTFIX, as the development of the standalone chat client Instantbird has stopped. Instantbird users are encouraged to migrate to Thunderbird. The user interface of instant messaging in Thunderbird will feel familiar, as the Thunderbird IM support started as a fork of Instantbird.
Status: NEW → RESOLVED
Last Resolved: 9 hours ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.