Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

Redesign: restyle jump to first unread message & rework read marker logic (rebased) #2345

Merged
merged 8 commits into from
Dec 12, 2018

Conversation

bwindels
Copy link
Contributor

@bwindels bwindels commented Dec 11, 2018

element-hq/element-web#7591

Abandoned #2322 in favor of this PR as the commit log is a bit cleaned up here. See also comments there.

image

The read marker logic is also changed, as https://github.com/vector-im/riot-web/issues/4134 has been a long outstanding issue, and making the feature look different without making it work well didn't make sense.

The read marker is now also updated if it is currently above the viewport:

  • if the marker is currently above the viewport, the timeout to move it is 30s.
  • if the marker is within the viewport, the timeout to move it is 10s.
    After the timeout elapses, the read marker is moved below the last event in the viewport when timeout elapses, as before.

The timeout is aborted when the user becomes inactive. The read marker is not touched, and the timer starts counting again once the user is active again. What is considered user activity changed a bit as well: the user is considered active when activating the tab/window, moving the mouse or scrollwheel, or using the keyboard. The user is considered inactive when blurring the window/tab, or 2 minutes have elapsed since the last interaction event was fired. This to prevent the read marker being updated when we know the user is not looking at the page.

Also added a Timer class using promises as the clear/setTimeout's were going to grow a bit unwieldy. Should be reusable for other timeout related usecases.

I'm not doing the badge count for now, as many rooms have gaps in their timeline so we can't give an accurate number of messages since the unread marker. Tried it and it looks confusing.

Parked the work for the badge on the bwindels/jumptofirstunread-badgecount branch (also on js-sdk) if we ever want to get back to it.

with placeholder for message count
Before, UserActivitity emitting actions meant that the user had very recently interaction with their hardware.
Now it means they are likely looking at the app.

You can attach a timer that is aborted when we think the user
stops looking at the page
(or hasn't touched their hardware for 2 minutes).

This works better than the previous approach for larger timeouts,
like the 30s we're about to implement for out-of-view RMs
The only behaviour that should have changed here is that
presence is also set to online when switching back to the
tab/window.

Presence is not set to unavailable when coming back to the window/tab,
as that might be a bit invasive, but only when timing out.
Uses Timer & changed UserActivity promise based api
@turt2live
Copy link
Member

Also added a Timer class using promises as the clear/setTimeout's were going to grow a bit unwieldy. Should be reusable for other timeout related usecases.

🎉

Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not too familiar with the RM before this, but this LGTM

padding-top: 10px;
padding-bottom: 10px;
border-bottom: 1px solid $primary-hairline-color;
z-index: 1000;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might want to double check this doesn't get layered weirdly with widgets or dialogs. I can't remember what their zindex is, but historically we've had problems with layering.

@@ -654,7 +702,6 @@ var TimelinePanel = React.createClass({
if (lastDisplayedIndex === null) {
return;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kinda like having these empty lines every so often, but won't protest strongly for them

@ara4n
Copy link
Member

ara4n commented Dec 12, 2018

thanks for the explanation over at element-hq/element-web#2322. I guess my only concern is that we deliberately implemented presence to not activate when you happened to scan through the riot tabs/windows, but required you to actually be waving the mouse or keyboard around - given it's quite common on WMs to temporarily focus a window without paying any attention to it at all.

HOWEVER, this isn't a big enough deal to merit iterating further, imo; i'm much more interested to get the additional sanity on RMs.

Can I suggest that we do drop the on-screen RM dissolve time back to ~1s though? 10s feels unnecessarily long.

@bwindels bwindels merged commit 9f5a025 into experimental Dec 12, 2018
@bwindels
Copy link
Contributor Author

bwindels commented Dec 12, 2018

@ara4n just played around with adding a delay on user activity started by page visibility/focus, but turns out that the mouse/keyboard interaction is also triggered when just switching tabs, not even hovering over the page, so we already had this behaviour before, so leaving it for now. Parked that experiment on bwindels/useractivitydelay.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants