New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MM-23761] [MM-25766] Add "More Messages" button #4416
Conversation
Building app in separate branch. |
* Use viewAreaCoveragePercentThreshold over itemVisiblePercentThreshold * Remove currentUserId check when adding New Message line to postIds and instead update the channel last viewed time when an own post is received
Adding @matthewbirtch for UX review when this is ready for testing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for getting this in @migbot! Great work. This is going to make things so much better on the app. Below is my first review - let me know if anything is unclear.
UI tweaks
- The color of the banner should be using the button background color.
- The height of the banner should be 40px (looks like it's 37px)
- The corner radius on the banner should be 4px (looks like it's 5px)
- The icon for the arrow seems to be a bit small
- The icon for the x seems to be a bit small as well
- The margin to the top/left/right of the banner should be 8px (looks like it's 10px)
Here's the comparison of what's implemented vs. what was designed:
Implemented | Designed |
UX issues
- When you tap the banner to scroll to the new message line, can we add any easing to this scrolling animation? It would feel a lot better if we added an ease-out to this.
- I tapped a banner that said '43 new messages' and it scrolled to the new message line. However it left the banner up and said '43 new messages' and didn't animate away after the scroll transition
- When a banner displays and I scroll through the messages above without tapping the banner, I noticed the number changes as I scroll, which is kind of cool - nice touch! However, I scrolled to the point where the New Messages Line showed and the banner didn't animate away - it stayed on screen displaying "3 more new messages". I would have expected the count to go to zero and animate away. Also, when I tapped the banner at this point, it did nothing. Even the 'x' icon did nothing in this scenario. I should mention that this seems to be a problem either with 40+ new messages or with scrolling fast. With smaller new messages or slower scrolling, the banner seemed to behave as I would expected. See the screenshot below (notice the banner is displaying at the same time as the new messages line)
- When the new messages banner is on screen and I pull up to refresh, the count seems to add 1 and then remove 1 when the load is done - it shouldn't add anything unless it finds new messages on the pull up to refresh
Thanks for the early review... this is still a WIP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@migbot It's looking good from my end. Also, the raw count is now showing up on the banners.
@matthewbirtch @esethna Please update the description in this ticket to reflect the new changes agreed upon. Thanks
https://mattermost.atlassian.net/browse/MM-23761
@esethna @matthewbirtch @josephbaylon You should see a shorter lag between count updates: |
@migbot LGTM. I experience smoother count updates on both iOS and Android. |
@esethna Is this something that needs to be in v1.33? We're past code complete and RC testing has started, so I'm not sure if it's too risky to add this to v1.33 in the last minute as this PR looks big. |
I wasn't having a significant lag before and it seems ok now, but I'm curious if it's improved for @esethna |
@migbot I think you were looking into some other issues based on the thread we had on Friday? |
@esethna Can you try the following builds: |
@esethna @matthewbirtch @josephbaylon Can you test the following (I promise this will be the last one 🤞 !): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@migbot, it's still feeling a bit buggy/unresponsive to me:
- There is still a bit of a delay to update the count when I tap on a banner that has a count larger than 60 new messages
- I got a banner with "105 new messages" that when I tapped, it scrolled up, but did not update the count when it stopped (see screen recording)
@matthewbirtch I want to understand this better
Cause the count has to wait until we fetch more posts from the server to get the new value, isn’t that expected? I struggle to see a wat around that as we can’t know the amount until the posts are actually fetched... or is it that I’m not understanding the issue that you are seeing? |
@matthewbirtch Do you see this consistently? And does this happen when you mark a message as unread in the channel or without having marked a message as unread? |
@migbot it doesn't appear to be happening consistently. I just tried to reproduce on many different channels by marking messages as unread, but can't seem to reproduce the case I got on video |
@enahum We know the total number at the beginning when the banner shows. Then when we scroll, we should know the number of posts we just scrolled past. If that's true, can we not subtract that number from the initial total to get the right number immediately without any delay? Or am I not understanding that correctly |
The initial unread count is not a true total unread count because it only accounts for message posts. In the list we insert non-message posts, like date lines and combined user activity, and these need to be added to the unread count as they load in order to keep the unread count and the new line message index synced. So if we were to subtract from the unread count when scroll ends you would see the unread count change once for the subtraction and then again as the non-message posts in the next set are loaded and the unread count is increased. |
Closing in favor of #4416. |
Summary
This PR removes auto-scrolling to the new message line on channel load and adds a "More Messages" button when there are unread posts. The unread post count is calculated on channel switch from the difference
channel.total_msg_count - member.msg_count
and with the addition of any inserted non-message posts (ie, date line) bymakePreparePostIdsForPostList
. On press of the button the user is scrolled to the index of the new message line or to the index of thehighestMeasuredFrameIndex
if the new message line post has not yet been measured. If there are no more unread messages the button is hidden, otherwise the unread count is updated and pressing again will scroll to the updated index of the new message line or the nexthighestMeasuredFrameIndex
.Because we don't want a new message line to be added when a user submits their own post either in the current channel or in another channel from separate client, there was a previous condition added in
makeFilterPostsAndAddSeparators
to not add the new message line if the post's user_id is the current user's ID. This was problematic for this feature as the index of the final new message line would not coincide with the index of the last unread message and so in this case the "More Messages" button would never hide. To get around this I added anownPost
property to Post. WhenRECEIVED_POST
orRECEIVED_NEW_POST
actions are handled, if the post is the current user's post then the channel'slastChannelViewTime
is updated to be the post's created_at value + 1, ensuring that the new message line is not added since the existing condition post.create_at > lastViewedAt will be false.Ticket Link
https://mattermost.atlassian.net/browse/MM-23761
https://mattermost.atlassian.net/browse/MM-25766
Checklist
Device Information
This PR was tested on: