Mark series as read even when they're not followed :maybe:

Group Leader
Joined
Mar 8, 2018
Messages
567
Recently, the behaviour for marking series as read was changed such that series aren't marked as read if they aren't followed. This has caused several annoyances, including read tracking not working for completed series (where there is no point following them), or for the situation where you read some or all chapters of a series, decide you like it and follow, but none of the chapters you've already read have been marked as such.

The suggested change in behaviour is to track read chapters even if they aren't being followed (in other words, revert the change in functionality).

My understanding is that the reason for the change was because the number of database rows for tracking follows was growing out of control. This, to me, seems like an implementation issue, so I thought I'd offer some suggestions on how to mitigate it.

I don't know what MangaDex's database schema looks like, but I assume that the table tracking read chapters has got something like the user ID, the series ID, the chapter ID, and presumably a timestamp. While that's fine from a normalization standpoint, it does lead to a rather large number of rows, as has become the problem. The simplest suggestion would be to stop tracking each chapter's status as a separate row, and instead only store one row per series, with the chapter numbers or IDs stored in a comma delimited string. Generally, string.split() and string.join() operations are quite fast in most languages, and if you're worried about a scenario like the user viewing screens that cover many series (like the follows screen), that can be resolved by caching the parsed results. Just throw the results of parsing that string in an in-memory cache or memcached and just expire the older cached results as required.

A far less drastic alternative: still do everything as now, but just purge read rows for non-followed and non-complete series if the records are older than a certain amount. That covers the scenario where I read a few chapters and then decide I like a series and hit follow, but still gives you the opportunity to keep database size under control.

Another possible idea: it won't help on every series (sometimes there are multiple versions of each chapters, like a LQ and a HQ version), but you can store the "read" record as ranges instead of individual chapters. Give each record a start and end, and then you know the user has read all chapters between those two IDs. If they make a change to remove a read chapter inside a range, you can split the record. If they decide to add a non-contiguous chapter, you just add a new record where the start/end is the same ID. Any time a user adds a new read chapter, first check to see if that ID is contiguous to any existing range, and update that instead of adding a new record.
 
Member
Joined
Jan 23, 2018
Messages
8
Another option: What if the read status of unfollowed chapters was stored locally, rather than on the server?
 
Group Leader
Joined
Mar 8, 2018
Messages
567
That wouldn't fully solve the problem, but it could sufficiently mitigate the problem to avoid the major annoyances. At the very least, it'd catch the "read some chapters then hit followed and nothing is marked as read" scenario most of the time (assuming you do all the initial reading on a single device).
 
Instrumentality Instigator
Staff
Super Moderator
Joined
Jan 29, 2018
Messages
1,342
I'm going to mark this as Maybe and try to herd Holo in this direction.
 
Custom title
Staff
Developer
Joined
Jan 19, 2018
Messages
2,436
Yeah these have been brought up. Consolidating rows just means moving the computation from myql to php which isn't necessarily a much better choice. It might be, but I have some doubts about whether it'd be significant enough. AFAIK there are no time records on the rows so purging old ones wouldn't work. The range thing would easily produce false positives especially in series with multiple translations.

Tracking everything client side would be simple enough but that suffers from the obvious problem that it's tied to the browser. Some kind of a sync feature would help with that but it'd still be kinda annoying to have to use.
 
Group Leader
Joined
Mar 8, 2018
Messages
567
I don't think it should be entirely client-side, as that would not persist between computers/browsers/devices... And I don't think you need to get as complex as a full sync either. A simpler implementation can be used to solve the read-then-follow problem:

1) Each time a chapter on an unfollowed would be marked as read/unread, set a flag client-side appropriately
2) When the user follows a series, as part of that action, read through the client-side flags and persist that data
3) Optionally, after the follow is complete, purge the client-side flags for that series

I don't think you need a full bi-directional sync. Just keep a record locally for the records that would otherwise be missed, and read them server-side when adding a follow. It should be simpler to implement than full two-way sync, but still mostly solve the primary annoyance with the current implementation. You don't need to worry about portability between devices/browsers either, since most of what you're trying to solve is the user sitting in front of one device, reading some chapters, then hitting follow.
 
VIP
Joined
Jan 21, 2018
Messages
854
Hasn't this same topic been brought up with the other thread being marked as :rejected:
 
Group Leader
Joined
Mar 8, 2018
Messages
567
I think the difference here (as to why this one got marked "maybe") was that we were trying to brainstorm potential technical solutions or mitigation strategies, rather than just suggesting the feature?
 
MD@Home
Joined
Jan 22, 2018
Messages
75
Could also store read data for a series as an array of bits in a
Code:
BINARY
column.
 
Member
Joined
Mar 22, 2018
Messages
44
A "mark all as read" function could be implemented. The same way we can mark individual chapters as read, if only there was a mark all as read button i'd appreciate it a lot. Could just put it on the eye icon on the first row, just click it and it marks all chapters as read/unread
 
Joined
Apr 23, 2018
Messages
1,071
[ul]
A far less drastic alternative: still do everything as now, but just purge read rows for non-followed and non-complete series if the records are older than a certain amount
[/ul]I doubt anyone really wants anything more than this. Up until recently, I thought they would utilize last-read chapter history for that, but since they changed that to series history, I guess it was never the plan.
[ul]
Just keep a record locally for the records that would otherwise be missed, and read them server-side when adding a follow. It should be simpler to implement than full two-way sync, but still mostly solve the primary annoyance with the current implementation. You don't need to worry about portability between devices/browsers either, since most of what you're trying to solve is the user sitting in front of one device, reading some chapters, then hitting follow.
[/ul]+1. More than enough for me, while there will definitely be users who notice and complain about this when they try to follow from a different device (following on another device so they don't loose their place while reading a chapter. Remembering they didn't follow it when a new update comes in. etc). This will probably solve over 99%+ of the issue.
For this to not solve your case you would have to:
1) Use multiple devices
2) Not follow the series from the device you originally browsed it on

Even if you don't follow right after reading (for some reason), chances of you reading it again from the same device are rather high. I expect the majority of users who would not fall into this category would be ones that follow on a different device while reading. You could probably get this to solve over 99.9% by adding a means to follow the series from the reader. Which IIRC, was a planned feature.

Some more options, each of which I believe are less elegant than the suggestion above.
Track 3 of timespan N, and gaurentee the last 2 timespans.
Eg. Keep the last 3 days/weeks unfollowed read chapters. At the end of the day/week, drop/remove all but the last 2 days/weeks. You can keep track with the day/week via an id (incrementing every day/week) instead of timestamp, since we really don't care when the user read it, just that its within the time-span. I prefer a triple buffer for shorter time-spans (so the batch deletion is less noticeable), but a double buffer is just as acceptable. The benefit of this over tracking last N chapters read is that it allows more to be cleaned from dead accounts (so, not much better).

Track last N chapters. Tracking the last 100 chapters would be more than enough IMO (especially if we exclude followed series from this). Allows you to read several other series before realizing you forgot to follow it. But even just the last 20 would be enough for most.

You could also just track the read chapters for the last read series, but that would probably be both a more difficult and less elegant solution.
However, it does seem elegant enough for a client side solution. Especially if you add a follow button to the reader, and a one-time follow reminder. "Looks like your enjoying this series! Consider following it --> [magic follow button]". This may be annoying, however, and figuring out when to show it is difficult.
Best answer is probably by measuring reading activity, and then displaying it when it goes over some threshold AND they move to the next chapter (no one wants a popup dialog/notification in the middle of a chapter)
Reading activity could be defined as: Time scrolling/clicking (the two user activities that indicate reading of a page/pages. Split into 15-30 second increments). Or pages read (only counting pages the user stayed on for more than N seconds). The second one is more elegant IMO, but may not work well with long strip comics (which often have very long pages compared to other comics, meaning less pages read for an equally active reader).

Personally, I would be fine with nothing being tracked but the last read chapter of the unfollowed series, but that probably wouldn't be enough for most users. (Cannot assume we read all the ones before. eg. jumped to the last chapter before following, to ensure it didn't take a weird direction. Skipped specials. etc)
 
Contributor
Joined
Feb 12, 2018
Messages
550
Unfortunately I don't know how to program and have nothing of value to add in that vein, but I just wanted to second (or third?) what people above me have said about tracking read chapters client-side. I really think it would solve most of the problem, and it failing to sync across multiple devices is a minor annoyance at best. Much better than individually marking off 20+ chapters of the ongoing series you just binged.
Additionally, though it has also already been mentioned, I strongly support the idea of a "mark all as read" button. While it wouldn't really be needed were we to find a (practical) way to implement read markers on unfollowed manga, it's a highly attractive solution in the meantime. (Though perhaps, to avoid it clogging things up with unnecessary markers on languages the user doesn't read, it should be limited to the languages from the user's language filter.)
 

Users who are viewing this thread

Top