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
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
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?