element-hq / element-meta

Shared/meta documentation and project artefacts for Element clients
75 stars 12 forks source link

[Story] Indicate when calls are unsupported in the timeline/notifications #2563

Closed manuroe closed 3 days ago

manuroe commented 1 month ago

Description

Acceptance criteria

Legacy side:

EX side (already implemented although we might want to tidy up the copy):

Leads

Size estimate

None

Dependencies

Out of scope

Open questions

### Questions

Subtasks

### Android
- [ ] https://github.com/element-hq/element-android/issues/8938
- [ ] https://github.com/element-hq/element-x-android/issues/3853
### iOS
- [ ] https://github.com/element-hq/element-ios/issues/7861
- [ ] https://github.com/element-hq/element-x-ios/pull/3502
### Web
### Other
- [x] Remove the `common.call_invite` string from Localazy.
### bugs
- [ ] https://github.com/element-hq/element-ios/pull/7870
- [ ] https://github.com/element-hq/element-android-rageshakes/issues/72241

Sign-off

Android

iOS

mxandreas commented 1 month ago

do we want to display a popup asking for confirmation before sending like "Alice is trying to call you using legacy call. Do you want inform them they should use Element Call to reach you"

Given, this is a temporary/workaround, I would keep it simple and without confirmation. I think it does not compromise privacy much, only exposes that one is using EX.

Are we ok with "The notice will be in the language of the callee EX app"?

I think that is fine; even hardcoding to English is also probably fine.

In terms of the message itself, I would propose something like:

"Bob may not be able to answer your call since you're using legacy calling. Please use Element X to reach them".

manuroe commented 1 month ago

We had a tech discussion about it. We are all aligned that we need a long term plan for the migration from lecacy calls to Element Calls BUT we cannot go quick to implement it, even with the band aid solution described in the issue. We tried to not overthinking but we kept raising concerns. It makes think we cannot converge in a better solution than what we have now in the 1 or 2 days of work allocate for this.

From the meeting: Problems:

Discussed options:

manuroe commented 1 month ago

The current solution is that the callee gets a notification and a timeline item saying "Call in progress (unsupported)". Then, the callee can they interact with the caller to find a way to communicate.

image

Another option could be to iterate on the wording on this not useful information in the timeline. The copy could invite the callee to engage and chat with the caller. Doing so, we could revisit the mechanism that computes the call state in that timeline item. It is not working well.

bmarty commented 1 month ago

Note: if by "notice" we're talking about m.notice msgtype, we will need to handle https://github.com/element-hq/element-x-android/issues/3636 as well on Android.

davidmehren commented 1 month ago

Instead of just showing "Call in progress (unsupported)", could you not display the Jitsi link, so the callee may join using the Jitsi app or their browser?

ara4n commented 1 month ago

How about we spec m.call.reject code which EX can send to say "sorry, can't answer now as you need to speak MatrixRTC". We then make a trivial change to the legacy apps to display that appropriately?

manuroe commented 1 month ago

Instead of just showing "Call in progress (unsupported)", could you not display the Jitsi link, so the callee may join using the Jitsi app or their browser?

Thanks for the hint. We were focused on the DM case but we could definitely used the Jitsi link for group calls. We just™️ need to make Element X support the widget API :/

How about we spec m.call.reject code which EX can send to say "sorry, can't answer now as you need to speak MatrixRTC". We then make a trivial change to the legacy apps to display that appropriately?

Oh, yes. @bmarty raised it too. I added it to the list

neilisfragile commented 1 month ago

Draft MSC https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc4220/proposals/4220-call-reject-locally.md

manuroe commented 3 weeks ago

I edited the user story indicating what we are going to experiment on Legacy and EX mobile apps. This changes follow the meeting we had with @bmarty and @pixlwave (https://docs.google.com/document/d/13GQLlgFZrJXlERKUYxaUUfm8QSqcvn937b7UBQ_AzGs/edit?tab=t.0_) The EX team is starting this project. Once we are happy with the solution, the EW will join. Hopefully, EW will be able to apply the same logic as legacy mobile apps.

pixlwave commented 2 weeks ago

I've updated the story with the solution we discussed in the room.

manuroe commented 1 week ago

Testing session

Alice is on EX apps and EW. Bob, on legacy apps and EW.

The tests are done for each versions of the mobile apss: EA, EXA, EI and EXI. EW can make both Element Calls and legacy calls.

Legacy side

We must have unsupported banner for:

No unsupported banner. The call just works:

EX side

We must have unsupported banner for:

No unsupported banner. The call just works:

manuroe commented 1 week ago

I checked some items but we need to discuss notificaiton for EC calls in legacy apps: https://github.com/element-hq/element-android-rageshakes/issues/72241.

manuroe commented 3 days ago

The EA notification bug has been fixed in https://github.com/element-hq/element-android/pull/8945.

The whole feature will be available in those versions of legacy and EX apps: