Skip to content
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

Implement Chat Scrollback #1619

Open
misslivirose opened this issue Aug 7, 2019 · 7 comments
Open

Implement Chat Scrollback #1619

misslivirose opened this issue Aug 7, 2019 · 7 comments

Comments

@misslivirose
Copy link
Collaborator

@misslivirose misslivirose commented Aug 7, 2019

Is your feature request related to a problem? Please describe.
Currently, chat messages in Hubs disappears very quickly.

Describe the solution you'd like
Chat messages should have a brief history stored (on the client) so that users could scroll back some amount and see what had been said earlier on in their session.

Describe alternatives you've considered
An alternative (and more extensive) solution could be to include chat history as some kind of audit log, but I would suggest that for the first implementation, we consider a client-side solution.

Additional context
This is particularly desired in events and meetings with a large number of people.

@gfodor

This comment has been minimized.

Copy link
Collaborator

@gfodor gfodor commented Aug 7, 2019

one facet to the design is if we want the local session chat history to contain messages from the entire session, or continue to expire them out after some period. having a expiration period (of say, 5 minutes) seems somewhat nicer since it'll provide a clean contract around message lifetime, and ensure we don't accidentally increase the "stakes" of interaction by inadvertently introducing a worst-case message lifetime of "forever" since an idle client could theoretically be storing messages over the life of the room. another benefit is this would limit the frustration of users who refresh the page and accidentally lose history -- if their expectation was messages last 5 minutes anyway, they aren't losing much compared to the full history.

the downside of doing a fixed expiration this is similar to the current situation, but less severe: users may be surprised or annoyed to see old messages expiring out, even if they are from N minutes ago. (obv this seems less likely to be as common to hit compared to now.)

@misslivirose

This comment has been minimized.

Copy link
Collaborator Author

@misslivirose misslivirose commented Aug 7, 2019

I think that expanding to have the last N minutes would be an iterative improvement over what we have now, and as you mention, the longer that is, the less likely it seems that people will have the expectation that it's over the lifetime of the room. I envision we would still suggest bridging rooms to an alternate platform for that case since that aligns to the room <> channel contract.

@misslivirose misslivirose added this to the Q3 milestone Aug 13, 2019
@misslivirose misslivirose modified the milestones: Q3, Q4 Sep 30, 2019
@misslivirose misslivirose modified the milestones: Q4, H1 2020 Planning Oct 23, 2019
@misslivirose

This comment has been minimized.

Copy link
Collaborator Author

@misslivirose misslivirose commented Dec 16, 2019

There are some complications with designing this across all of the platforms, client-local history could be done. We need to figure out the right design. Perhaps a secondary modal that has the full client history?

@emclaren

This comment has been minimized.

Copy link
Collaborator

@emclaren emclaren commented Jan 10, 2020

Just noting that I've had a couple different community members ask for this feature recently.

@gfodor

This comment has been minimized.

Copy link
Collaborator

@gfodor gfodor commented Jan 13, 2020

Consider a mobile/non-mobile UI split where chat goes into a modal on mobile due to screen issues.

@emclaren

This comment has been minimized.

Copy link
Collaborator

@emclaren emclaren commented Mar 10, 2020

The accessibility group using Hubs wrote to me about the text chat message user experience on screen readers. From our contact with this group:

When using Hubs with a screen reader, a user can hear the new message notification (audible tone), and then use the screen reader to read through the DOM to get to the message.

However if/when the message disappears it is not available any more to screen reader. This is one warranting more discussion because it would be nice to have the chat messages automatically read out but not if there are too many messages being read at once. Twitch is currently exploring this problem space and might be interesting to collaborate with on an appropriate design solution.

image(8)

@misslivirose

This comment has been minimized.

Copy link
Collaborator Author

@misslivirose misslivirose commented Mar 27, 2020

More feedback: "Chat history, catching things before they disappear is difficult so having an option to see chat history maybe useful, and maybe also mitigate link/info management problem. Though, how ephemeral are chats intended to be?" - from user Tuism on Discord

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.