Replace unread messages banner

[alya]

The unread messages banner is not very intuitive or visually appealing in its current form. The first thing to fix is #4526, but we should also experiment with other ideas for improving it. A couple of ideas:

• The banner could become a pill at the bottom of the view, which is more intuitive, because unread messages are generally below the viewport. Possible pill wording: "Mark all X unread messages as read". Ideally, there would be some kind of visual indication that messages got marked as read, besides the button disappearing when you click it. There is also a question of whether the button should scroll the view in some way.
• Another option is top put the indicator at bottom when there are unreads below, at the top when the are unreads above, and both when both are the case. For example, this is what Dropbox Paper does:

See also CZO discussion.

[Jumeb]

I would love to work on this task and also experiment with the ideas you have given to see the end results. Will be sending screenshots in the days ahead.

[Jumeb]

The unread messages banner is not very intuitive or visually appealing in its current form. The first thing to fix is #4526, but we should also experiment with other ideas for improving it. A couple of ideas:

• The banner could become a pill at the bottom of the view, which is more intuitive, because unread messages are generally below the viewport. Possible pill wording: "Mark all X unread messages as read". Ideally, there would be some kind of visual indication that messages got marked as read, besides the button disappearing when you click it. There is also a question of whether the button should scroll the view in some way.
• Another option is top put the indicator at bottom when there are unreads below, at the top when the are unreads above, and both when both are the case. For example, this is what Dropbox Paper does:

See also CZO discussion.

@alya I read the tread attached to this issue and I think I found origin of the webView jumps. I did some experiments and I found out that when we animate the scalling, there's some sort of virtual box that is left behind by the animated component, then we now abruptly change the the display from flex to none without animation (cannot animate display) then it creates this empty space which the webView then fills it up instanteneously thus causing the jump.

Solution: From my experiments I found out the best way to solve the jump was to animate the height instead of switching the display property: -

• I tried to find an alternative which was to animate the maxHeightof the AnimatedScaleComponent to scale from 0 to the height of its content and from the height of it content to 0 to avoid the jump but I could not interpolate maxHeight using the animations provided by react-native.

• I then tried to use react-native-reanimated to animate this component and I have been unable to set it up, I keep an error Reanimated 2 failed to create a worklet, maybe you forgot to add Reanimated's babel plugin?. I followed the installation guides but no progress.

Please can you help me out.

[alya]

Since I'm not an engineer, @gnprice or @chrisbobbe will need to comment on the technical details. :)

[alya]

It's probably best to have a discussion more interactively on chat.zulip.org.

[Jumeb]

Thanks for the comment @alya

[gnprice]

I think I found origin of the webView jumps.

It looks like this is really about #4526, about making the banner no longer cause the screen to jump. This issue #4930 is about replacing the banner with something else.

In any case, for cross-reference, here's the chat thread from that comment.