Loop windows should close on call ending

RESOLVED WORKSFORME

Status

Hello (Loop)
Client
P2
enhancement
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: abr, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needs UX clarification once all main calling scenarios are implemented])

(Reporter)

Description

4 years ago
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.
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.
Darrin -- What behavior do you recommend here?
Flags: needinfo?(dhenein)
Target Milestone: --- → mozilla34
Priority: -- → P2
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?
Flags: needinfo?(dhenein) → needinfo?(rtestard)

Comment 4

4 years ago
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.
Blocks: 1015857
Flags: needinfo?(rtestard)

Updated

4 years ago
No longer blocks: 1015857

Updated

4 years ago
Depends on: 1000186

Comment 5

4 years ago
Actually I was wrong, this does not block 1015857.
1000186 (Desktop client needs "call failed" visual and audio notifications) block this bug.
No longer depends on: 1000186

Updated

4 years ago
Depends on: 1000186

Comment 6

4 years ago
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).
Flags: needinfo?(dhenein)
Target Milestone: mozilla34 → mozilla35
Agreed -- the "auto-close on certain call scenarios" feels like polish and out of MVP scope. Fine to push to 35 if needed.
Flags: needinfo?(dhenein)
Severity: normal → enhancement
No longer depends on: 1000186
Depends on: 1012743
Whiteboard: [needs UX clarification once all main calling scenarios are implemented]

Comment 8

4 years ago
Based on the work already in queue for Fx35 and the uplift of Fx34 work to Beta - moving this out at least until Fx36.
Target Milestone: mozilla35 → mozilla36
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.
(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

3 years ago
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.
Blocks: 1082944
backlog: --- → -
Flags: needinfo?(dhenein)
Target Milestone: mozilla36 → ---
Flags: needinfo?(dhenein) → needinfo?(sfranks)

Updated

3 years ago
No longer depends on: 1012743

Comment 13

3 years ago
see if this is still an issues with latest version.  lower priority if is.
Flags: needinfo?(sescalante)
Flags: needinfo?(sfranks)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(sescalante)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.