There is already a bubble that displays how much activity has been missed when a tab or character loses focus. I am wondering how (non) trivial adding a Last Activity Viewed marker line would be to add so that people don’t have to scroll back if it’s more than a couple of lines in a super “noisy” location (e.g. Station Park).
2 Likes
This along with some nice way to see if there are whispers or messages in the unread portion of the message log would be a major UX improvement.
I ran across this sample on the forums:
ETA: For illustrative purposes, I know that the forums and Wolfery don’t share a backend.
I’ve made a few QoL changes to my Wolfery habits: mute travel has greatly improved my experience, and I’ve been using @Zalyra’s nifty little self-focus workaround (detailed here) – which helps! Thanks @Zalyra!
That said I’m running into limitations that cannot be worked around, especially in public when I’m more of an observer than a participant. I feel like I’m constantly re-reading the same lines in the scrollback log every time I switch tabs. I find extremely easy to lose my place in Station Park when ooc messages are flying quickly and the badge on my tab reads 9+.
What might make this more useful is if there were a way to detect when the user has scrolled back to respond to something and then returns to “real-time”.
2 Likes
Sorry for the late reply to this. But yes. This would be a nice one.
We have similar on Discord too, which is nice.
We currently have a feature that tracks unseen events, including targeted ones (like whispers, addresses, and mentions). But that one only tracks the number of unseen messages, and does not show any “Last visit” or “New” border; is simply just shows a counter.
Also, that feature zeroes the “unseen” counter once you reach the bottom of the log.
But… Shouldn’t we be able to just do this:
Each time the unseen counter goes from 0 to > 1, we add a line above that event. If another line already existed, that previous line is removed.
This solution would, however, have this effect:
- You have a character in Station Park which has a counter of 20 unseen messages.
- You switch over to that character tab. The counter is set to zero.
- You scroll up to find the line, 20 poses up.
- While scrolling, a new pose is made causing the unseen counter to go from 0 to 1. Because of this, a NEW line is added above that new pose, and the previous line is removed.
- … you fail to find where the line was previously at.
So. It has its flaws. How to improve the behavior of this line?
2 Likes
What I would do is at step 2.-3. of the problem, instead of scrolling up to find the line, the log could automatically scroll so that the line is in view. And then, if the count doesn’t clear until the bottom is reached, the problem is avoided almost completely.
This way, if a new pose is made while reading the log, it won’t affect the position of the current breakpoint since the log hasn’t been at the bottom yet.
Then, for ergonomy’s sake, the marker can be moved via an Intersection Observer maybe after the line is visible on the screen for a set amount of time and the user has interacted with the page since the last update. Effectively marking the looked at events as read.
This is how I planned on implementing it via the userscript anyway.
As a minorly related aside, what I’d also do is if the currently controlled character goes idle, then stop autoscrolling the log with new messages. Though that should likely be an option…
Would it be easier to only update the position of the line when focus is switched to another tab?
I don’t really know the implications on mobile, but at least on the desktop it would seem to me that the marker line would only need to be drawn if a new event came in and the log window and the logging frame wasn’t in focus.
Although this might lead to cases of the line being drawn more than absolutely necessary (i.e. switching back and forth between characters in the same location), but I think it may simplify the logic?