1020450 - Loop windows should close on call ending

Status: RESOLVED WORKSFORME

(Hello (Loop) :: Client, enhancement, P2)

Description

[Adam Roach [:abr]]

When the call is over, currently users are required to press the 'x' in the Loop window to make it go away -- otherwise they continue to accrete. This is surprising. Rather than displaying an 'end of call' window, the windows should simply close.

Comment 1

[Mark Banner (:standard8)]

I believe it was decided a while ago that the UX should be that the user is notified that the call has been completed / ended - at least by the other end. If the window just disappears, then the user would have no idea what happened.

From the perspective of the person who ends the call, if we auto close the window, then closing the window will be in conflict with bug 972992 which wants to ask the user for feedback about the call quality.

Comment 2

[Maire Reavy [:mreavy]]

Darrin -- What behavior do you recommend here?

Comment 3

[Darrin Henein [:darrin]]

If the call has happened and we determine that feedback should be collected (i.e. the call was over 30s, or some other heuristic), then yes the feedback form should be shown. If the call is ended because it couldn't connect or for whatever reason we are not showing the feedback form (I'm assuming Romain has some guidance for when the feedback form should/shouldn't be shown) then i suggested a ~5 second delay where we show the Call Ended UI, then auto-dismiss the window.

Romain, thoughts?

Comment 4

[Romain Testard [:RT]]

Yes, the feedback form should be shown if the call connected (i.e the callee answered).
If the call did not connect (any reason - busy, timeout, error, reject), as Darrin suggests keeping the call ended UI for a few seconds is the right approach to enable the user to redial if he wants to (bug 1015857).

I mark this bug as blocking 1015857.

Comment 5

[Romain Testard [:RT]]

Actually I was wrong, this does not block 1015857.
1000186 (Desktop client needs "call failed" visual and audio notifications) block this bug.

Comment 6

[:shell escalante]

this is a nice to have polish for 35 IMHO.  flagging Darrin if he objects strongly -but our list of 34 is high to get a really nice experience (of the call).

Comment 7

[Darrin Henein [:darrin]]

Agreed -- the "auto-close on certain call scenarios" feels like polish and out of MVP scope. Fine to push to 35 if needed.

Comment 8

[:shell escalante]

Based on the work already in queue for Fx35 and the uplift of Fx34 work to Beta - moving this out at least until Fx36.

Comment 9

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

We're automatically closing the window after the feedback form has been displayed. I don't think we want to close the window until the feedback form had a chance to be filled, so I think this should be marked as resolved/invalid.

Comment 10

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

s/displayed/sent, obviously.

Comment 11

[Mark Banner (:standard8)]

(In reply to Nicolas Perriault (:NiKo`) from comment #9)
> We're automatically closing the window after the feedback form has been
> displayed. I don't think we want to close the window until the feedback form
> had a chance to be filled, so I think this should be marked as
> resolved/invalid.

There's some discussion about how to handle call failed (if to auto close that). I think we should get the full flow implemented, and revisit this in 36.

Comment 12

[:shell escalante]

putting this into UX queue as it sounds like the discussion is over what we want to do at end of Rooms and calls- not actually implementing it :).  Put blocking bug 1082944 so it can be priorities.  just needing darrin for info so he sees - and can object if wanted - or else just queue up with design behavior.  If the behavior is determined - let us know and we'll pull back onto work log.

Comment 13

[:shell escalante]

see if this is still an issues with latest version.  lower priority if is.