Typing Notification update

[gaelledel]

• Typing notifications need to move from the header to the bottom of the timeline. The style and animation will follow the recent implementation done on iOS.
• Let me know when you get to it so more info can be provided as some more complex behaviour is involved.
  https://www.figma.com/file/uaWc62Ux2DkZC4OGtAGcNc/Voice-Messages?node-id=1855%3A86441

[bmarty]

Doing that will have the effect of moving the timeline up and down every time a user starts and stops typing. Do we really want to have this behavior? Element Web, when the user stops typing, there is an empty space at the bottom of the timeline to avoid blinking, supposedly to let some room for an incoming message even if no message can come if the typing user just does not send any.

Unlike Element Web, the area for the timeline on mobile is limited, so I do not want to mimic the same behavior.

The current implementation of typing notification is similar to what is done on WhatsApp FWIW.

[gaelledel]

Please refer to the iOS current implementation. It was @ara4n who requested that we do not mimic Whatsapp behaviour. Let me know if you need further information but we'd like parity for all platforms please.

[bmarty]

Ok, thanks. @daniellekirkwood do you approve those changes? The current typing notification appear at top of screen for the record, as per the screenshot below

[daniellekirkwood]

While I agree with you @bmarty that we would not want to implement this if it causes the timeline to 'jump' when triggered, the iOS implementation does not do that.

How does the iOS layout differ, do they have greater padding or a space reserved for the typing notification that means there is no 'jump'?

[gaelledel]

@bmarty FYI this is a UX matter not a product focussed matter so if you need more information, please message me directly. This was agreed and approved by @nadonomy and by @ara4n a few months ago.
The timeline would not jump because we have a blank space dedicated for when users stop typing - Again, please check the iOS implementation and the behaviour specs I have given you. I am here if you need further explanation. Thanks

[daniellekirkwood]

FYI this is a UX matter not a product focussed matter so if you need more information, please message me directly.

I'm re-adding the Needs-Product label as I am seeking to understand your request and the work involved in building this - I will then be using that information to prioritise this issue accordingly. Once prioritised in our backlog, according to the company quarterly goals, we can remove the Needs-Product label.
Product should always be included in discussions of your highest priority concerns.
As for messaging you directly - I will, thank you! :) Please know that we're moving towards a model where we keep discussions and notes in the Github issue itself as comments and decisions often get lost in Matrix convos.

This was agreed and approved by @nadonomy and by @ara4n a few months ago.

Thank you for the context.

The timeline would not jump because we have a blank space dedicated for when users stop typing - Again, please check the iOS implementation and the behaviour specs I have given you.

Thank you for this confirmation.

[bmarty]

Should be better to avoid empty area, or we will have issue like this (from the old app) : element-hq/riot-android#1719. There is no screenshot in the issue, but it was like this (see the empty area above the composer):

[daniellekirkwood]

Thanks for your feedback everyone!
The empty area should be minimal based on the designs and looking at the iOS implementation.
This issue is now on our backlog and we'll prioritise it at our earliest opportunity.

[bmarty]

Implemented in 1.4.4