mike - mike@macgirvin.com

mike

Fri, 21 May 2021 09:30:36 +1000

Considering doing away with "stream unread notifications" since we have no reliable method to determine if they've actually been seen and our implementation falls over completely in the public stream. I notice none of the commercial platforms implement this, so maybe it isn't that compelling to even try. It would certainly remove a lot of really ugly and potentially fragile code. You'd still get system notifications for any content that concerns you personally.

But... in order for that to work at all, we'll have to change to looking at received timestamps instead of created/changed timestamps because some channels/sites/platforms seem to always take a couple of days to do routine deliveries. And we should also display somewhere the timestamp of the last update to each conversation so it would be easier in "commented" sort order to more easily discover when you're re-reading conversations that haven't changed at all since your last visit.

Just thinking out loud. Say something if you have strong feelings one way or the other.

show all 7 comments

mike

Sat, 22 May 2021 08:27:21 +1000

This is for Zap (etc.).

I'm running some tests now where the only information we have is when you last loaded a particular stream. Nothing is "seen or unseen"; it merely happened before or after that particular time. It doesn't seem to be any better or worse than it was before. There are a couple of usability quirks doing it this way but I believe they're solvable. For instance if we gave you access to the relevant timestamp and let you change it. Then as you click through the notifications, automatically move the timestamp up to that message so they are cleared from the notifications (as well as any you passed over). If you do anything that accidentally clears a notification you can change the timestamp and see them fresh again.

Even though this might seem awkward I consider it a major improvement because I can describe exactly how these notifications work to a person of average intellect - and give them complete control over it by exposing the relevant timestamp and allowing it to be modified. It's something that is predictable and can be tested. The way it works today is hopelessly complicated and only makes sense to folks that know the code, and it works differently in some streams than others. That's what I'm trying to eliminate.

Mario Vavti

Sun, 23 May 2021 19:12:06 +1000

Hubzilla slightly changed this behaviour a while ago, when page caching was implemented.

Basically the items are not marked read when they are fetched from the DB but only after they have been rendered on screen. IIRC the list of rendered mids is sent back to the server when the new notification count is being fetched, an aftervthat marked read. It would not be too hard to change the list to contain just the items that were already in the visible area of the screen. I wonder if it's worth the hassle though...

Einer von Vielen

Sun, 23 May 2021 23:45:15 +1000

to change the list to contain just the items that were already in the visible area of the screen

I guess some users would expect something like this... Hmm.

mike

Mon, 24 May 2021 10:07:10 +1000

After a lot of experimentation with different notification concepts; it seems we'll need a hybrid approach. We cannot do away with seen/unseen state completely; as we can't use the load timestamp for everything we want to do. I've tried it. The major issue which we're confronted with is what to do about seen/unseen state in the public stream, where we need to track what has been shown to a number of different people - not just the stream owner.

It appears the most sensible way to fix that is with session/memory based seen/unseen state which resets on every stream load. That's not as elegant a solution as I was looking for, but I think it's the only one that will behave exactly the same across all the different streams and accommodates all of our current usage patterns. It won't easily scale to manage tens of thousands of unseen messages without creating browser performance issues; but this will quickly become apparent and I believe people will adjust their workflow accordingly. Eventually they will need to load that stream or mark everything seen to reset the memory usage. It's a problem which will likely solve itself since their notifications will ultimately get cluttered with stuff they're trying to ignore and they'll need to clear these out.

In any event, there's at least a man-month of work involved so it's not all going to happen today.