Last read indicator

[matthewrfennell]

It could be useful to let the user pass the last read message, e.g.

ChatView(messages: messages, lastRead: lastReadMessage) { draft in
    yourViewModel.send(draft: draft)
}

Where lastRead has type Message? and a default value of nil.

This could then show a view above or below that particular message, telling the user everything since then is unread.

I had a brief look at how I could implement it. Here's what I am thinking:

• Introduce an enum Row that contains MessageRow and a new LastReadRow
• Modify MessageSection's rows to be of type [Row]
• Modify WrappingMessages to return this new Row instead of MessageRow
• Modify UIList's tableView(_:cellForRowAt:) to take a Row and return a ChatMessageView or ChatLastReadView as appropriate

I think this refactoring could also be useful to allow other non-message cells in the future, such as status messages, which are not really messages but could still be shown in their own cells.

I'd be happy to work on this if you think it would be useful. Let me know what you think!

[f3dm76]

Hey @matthewrfennell, good idea, however reworking the API seems like an overkill. Message already has a status field, containing read/unread info, we could use that to locate the last unread inside UIList updating, assuming you are updating this status for messages on your end, and add this UnreadMessagesView on top of the message cell, as a part of those cell. Its appearance could be a simple builder (by simple I mean AnyView, it sometimes causes problems but for a simple view like this it should be enough).

Also, if you are implementing custom message cells already, you can add it yourself, like:

ChatView(...) {
...
} messageBuilder: { message in 
                if message != lastUnread { 
                        messageCell(message) 
                } else { 
                         VStack {
                              UnreadMessagesView()
                              messageCell(message) 
                         }
                  }
            }

Have a great day!

[matthewrfennell]

Hi, thanks so much for the feedback! I was looking at this and had some extra thoughts:

add this UnreadMessagesView on top of the message cell, as a part of those cell

One implication is that the last unread view would move across the screen on swipe action. This makes me think it should ideally be part of its own cell and separate from the MessageView.

I should have mentioned this - this was my main motivation for the enum - allowing different behaviour for these different kinds of views from within UIList. Although there could be a better way that I have missed.

Message already has a status field, containing read/unread info

I like the idea of deriving both the blue ticks and last read view from the same source. However, one doubt I had with using status as-is is that the blue ticks might have a different meaning to the last read message:

• In a group chat, read might mean "everyone has read this". So, even if you have read the whole chat, as long as someone hasn't read to the end, the last read view will remain "stuck" in the same place

One option could be to make the Status enum more granular, e.g.:

case sending
case sent
case readByCurrentUser
case readByAll
case error(DraftMessage)

Or, like this:

case sending
case sent
case read(by: [User])
case error(DraftMessage)

That could let us derive the last message unread by us as you suggested.

• In a 1-1 chat, some clients might set all message statuses as read as soon as you open the view. In that case, the last read view wouldn't appear

This makes me feel that the last unread view should stay in place for the lifetime of the ChatView, regardless of the current Status of any Message. Perhaps clients should first pass the current Status, the ChatView should calculate and store the lastUnreadMessage in init, and then the client should set the Status of all Messages to read after that?

Let me know if you have any thoughts! Anyway, I'll play around over the next few days and see if any nice designs naturally pop out. Right now every option feels a little messy.

[f3dm76]

Hey @matthewrfennell, valid concerns, let's discuss one by one:

One implication is that the last unread view would move across the screen on swipe action

• yeah, I see why it has to be a separate cell, long press menu too btw, didn't think about that. so we'll have to use careful little index math to insert this extra cell between messages cells, should be doable I think

One option could be to make the Status enum more granular

• yeah, I think case readByCurrentUser case readByAll would be enough and also a nice addition, indeed group chats could be tricky in this concern

In a 1-1 chat, some clients might set all message statuses as read as soon as you open the view.

• I think that if a client chooses to force mark everything read, it's his choice. actually tracking read/unread by tracking on screen messages, and storing it on back-end is a bit complicated and not everyone choose to actually do it. so we shouldn't force this view on them
  And if a client chooses to accurately update message's status, then UIList update method will get an update and move LastUnreadView accordingly
  And the easy option to still get the LastUnreadView is to mark all as read, when user leaves the chat.
  I don't think there is a need for storing lastUnreadMessage, it has to be calculated on the fly every update to be up-tp-date, no?
  What I'm mostly trying to say here, is that we have to make it absolutely seamless for the user, without having to manually pass anything but read message statuses. All the user would see is a modifier .showLastUnreadView(yes/no)

[matthewrfennell]

Thanks again for the detailed feedback!

On the last point: I still feel the meaning of the lastUnreadMessage conflicts with the Message status and it could be more accurate to model it separately. That said - I do see that this comes at the cost of the more seamless API. So ultimately, I'm happy to go with your suggested design if you prefer!

I don't think there is a need for storing lastUnreadMessage, it has to be calculated on the fly every update to be up-tp-date, no?

I'm not sure, I think this might be a case where we don't want live updates, since the LastUnreadView moving down the screen could be confusing/distracting UI.

I have two assumptions about these views in an ideal world:

• I think the LastUnreadView should be static, even when message statuses change
  • A user might open the chat, skim through the unread messages to see how many there are, and then scroll back to the last unread to read them "properly", for example
  • If the read status was updated in the meantime, the view would no longer be visible and they wouldn't be able to find their place again
• I think the MessageStatusView should update live (however the client defines that)
  • That way the user can constantly see the current status of all messages.

I think that if a client chooses to force mark everything read, it's his choice

And the easy option to still get the LastUnreadView is to mark all as read, when user leaves the chat.

I agree this is a client choice in principle, but taking the above two assumptions, the client has to choose between either up-to-date MessageStatusViews, or a static LastUnreadView.

It can't have both at the same time (while they share the same data source and both views update live), since the two views have slightly conflicting meaning.

we have to make it absolutely seamless for the user, without having to manually pass anything but read message statuses

I definitely see the benefit/elegance to using the existing API though - I'm certainly happy to use your suggested approach if that's your preference!

A completely separate complication is answer mode - I don't think having a single "last unread" message makes much sense in that context (since the history is not linear) and perhaps should be disabled by default if that mode is selected.

[f3dm76]

It can't have both at the same time

Let's maybe add a setting like .lastUnreadViewDisplayMode(.static/.live/.none) (can add more options). The point is: last unread MessageStatus and LastUreadView are conceptually the same thing (unread messages tracking), they should use the same data source, we shouldn't separate them artificially because of their UI differences: UI details shouldn't define core implementation logic, always decouple the UI from the business logic.

and perhaps should be disabled by default if that mode is selected

I even think we should disable it completely in that mode, I've never seen such a use case, so it's not needed I think