Base Last Updates on Titles, not Chapters

[hakito]

You seem to base the content of Latest page in Chapters, not titles, so users may end up seeing a few Titles per page. Even more, some Titles appear to be ever present in many pages (like "Oishinbo") limiting even more the actual Titles that had been updated.

Incidentally, please consider changing the listing making emphasis on Titles, not Chapters (or, sorry, Groups), similar to the screenshot below with custom CSS.

As an example, below is a page showing 16 Titles for the maximum setting of 100 entries(?) per page. BTW, what the heck is a "multiplier"? Would it help, make it worst, or be the same? I didn't see a description of its use.

 

[Valle_reading_manga]

Incidentally, please consider changing the listing making emphasis on Titles, not Chapters (or, sorry, Groups), similar to the screenshot below with custom CSS.

FYI, your library will show titles in order of latest updates (although it's not ideal either).
In any case, this is a known (and previously voiced) complaint, but probably not going to change any time soon/ever (see this thread for example, or use the search to find a bunch of additional threads). Basically, the more frequently chapters get uploaded per title, the fewer individual titles will appear on your updates.

As an example, below is a page showing 16 Titles for the maximum setting of 100 entries(?) per page. BTW, what the heck is a "multiplier"? Would it help, make it worst, or be the same? I didn't see a description of its use.

The multiplier determines the number of chapters loaded on title pages based on the display limit. From the settings page:

Note: Chapter lists load 3 times the selected amount by default.

By default, that results in you seeing 3*32=96 chapters on a manga's page, such as this one.

 

[hakito]

FYI, your library will show titles in order of latest updates (although it's not ideal either).
In any case, this is a known (and previously voiced) complaint, but probably not going to change any time soon/ever (see this thread for example, or use the search to find a bunch of additional threads). Basically, the more frequently chapters get uploaded per title, the fewer individual titles will appear on your updates.

This is interesting, I get a better idea of why nobody else replied, and this also strongly suggests that it's a faulty design too deep into the system so it cannot be changed without a significant rewrite.

Additionally, from the messages quoted by "Ndtm" in that thread, "Tristan" says that "[...]these are likely the same fundamental reasons for why youtube (and pretty much everyone else) can't do it nicely either[...]", so it would be very interesting to know how it is not nice and why this site's approach is nicer, but I guess that won't happen.

I guess that all I'll see are "we do it this way!" messages, without any attempt for logical arguments. This behavior is the main reason why I never returned to this site, given the very crappy user experience, and I do wonder if others may have felt the same but they wouldn't be around anymore.

The multiplier determines the number of chapters loaded on title pages based on the display limit. From the settings page:
By default, that results in you seeing 3*32=96 chapters on a manga's page, such as this one.

Thanks for trying but this does not seem to explain the effect on the latest updates page, which is what I was asking --there is no effect, btw, and the existence of this "setting" strongly supports this being a faulty design.

Maybe the next version will focus on the users a little more. Happy browsing!

 

[RogueKitsune]

The TLDR; for why the updates page works the way it does is because given the resource constraints at the time there was simply no other way to do it and have the site still be usable.

Some additional reading
https://forums.mangadex.org/threads...tch-titles-not-chapters.1523744/post-19799169

https://mangadex.dev/an-api-to-rule-them-all/

This is something we didn't talk about in this post, but feeds are the most expensive request that we have at the moment on MangaDex. And every user has a unique feed based on the titles they are following so it is close to impossible to cache in the same way as other resources. We have some ideas to change that into a mix of pre-computed and on-demand lookups, similarly to how Twitter is handling timelines⁸ which would be a much more scalable long-term solution.

 

[mylovenovels]

FYI, your library will show titles in order of latest updates (although it's not ideal either).
In any case, this is a known (and previously voiced) complaint, but probably not going to change any time soon/ever (see this thread for example, or use the search to find a bunch of additional threads). Basically, the more frequently chapters get uploaded per title, the fewer individual titles will appear on your updates.

The multiplier determines the number of chapters loaded on title pages based on the display limit. From the settings page:

By default, that results in you seeing 3*32=96 chapters on a manga's page, such as this one.

Thanks for the explanation, that actually clears up what the multiplier does and why the behaviour looks the way it does.

That said, this kind of reinforces the original concern rather than resolves it. If the system is fundamentally chapter-driven, then heavy uploaders will always crowd out title diversity on the “Latest” page, which makes it a pretty poor discovery tool unless you already follow those series. Knowing why it works like this doesn’t really make the UX feel any better.

I get that this is a long-standing design choice and probably not trivial to change, but from a user perspective it still feels counterintuitive that increasing the entry limit can result in fewer unique titles being visible. Even a separate, optional “Latest updated titles” view (distinct from chapter activity) would go a long way without breaking existing behaviour.

So yeah explanation appreciated, but the outcome still feels like a design trade-off that heavily favours upload frequency over discoverability.

 

[Valle_reading_manga]

there is no effect, btw, and the existence of this "setting" strongly supports this being a faulty design.

If you're gonna be this entitled, at least learn to read
The multiplier doesn't take effect on your feed (or latest updates) because it's not a title page. If you're still unsure how to distinguish those two, here's a simple explanation: Your feed/latest updates are under mangadex.org/titles/... (latest/feed), while a title page is under mangadex.org/title/...
Additionally, allowing to specify a display limit per page is not a "faulty" design. This simply allows users to adjust performance to their needs, be it setting a lower limit because their connection is bad or bandwidth is limited. Additionally, mobile users can't see hundreds of entries per page properly, while using a bigger screen might warrant to see more than 32 entries at once and the list goes on.
In any case, that's all I will say about this in addition to what roki already reposted. Without any attempt for logical arguments, this isn't worth arguing about further...

 

[Valle_reading_manga]

I get that this is a long-standing design choice and probably not trivial to change, but from a user perspective it still feels counterintuitive that increasing the entry limit can result in fewer unique titles being visible. Even a separate, optional “Latest updated titles” view (distinct from chapter activity) would go a long way without breaking existing behaviour.

So yeah explanation appreciated, but the outcome still feels like a design trade-off that heavily favours upload frequency over discoverability.

Increasing your display limit will not result in less titles showing. In fact, it's the opposite: the higher you set the display limit, the more titles will (potentially) show. Essentially, a feed (both yours and the "global" one) will pull display limit most recent chapters and then group them by titles. So if the 100 most recent chapters were all uploaded to the same title, you will, in fact, only see one title. But if you pick a higher display limit, it's way more unlikely for all the chapters to belong to the same title(s)...
Still, bulk uploads are a problem and frequently updating titles can easily drown out niche/not as frequently updating ones, so I agree that it's not perfect. Tbh, for discovery PNT, recently added, the advanced search's random feature, tags or the recently added recommendations are more useful. Imo, the feeds' primary purpose is to see the most recently uploaded chapters...

 

[mylovenovels]

Increasing your display limit will not result in less titles showing. In fact, it's the opposite: the higher you set the display limit, the more titles will (potentially) show. Essentially, a feed (both yours and the "global" one) will pull display limit most recent chapters and then group them by titles. So if the 100 most recent chapters were all uploaded to the same title, you will, in fact, only see one title. But if you pick a higher display limit, it's way more unlikely for all the chapters to belong to the same title(s)...
Still, bulk uploads are a problem and frequently updating titles can easily drown out niche/not as frequently updating ones, so I agree that it's not perfect. Tbh, for discovery PNT, recently added, the advanced search's random feature, tags or the recently added recommendations are more useful. Imo, the feeds' primary purpose is to see the most recently uploaded chapters...

Thanks for clarifying, that makes sense I see now that the feed pulls N recent chapters first and only then groups by title, so a higher limit statistically increases title diversity rather than reducing it.

That said, the edge case you mention is kind of the core of the frustration: when bulk uploads or very active titles dominate, the feed can still collapse down to just a handful of series, which makes it unreliable for anything beyond tracking already-popular or frequently updated works. So while it works as intended for “latest chapter” monitoring, it’s much weaker as a general overview of what’s newly active across the catalog.

I agree that other sections (PNT, recently added, random, tags, recommendations) are better for discovery it just feels a bit unintuitive that the page most users read as “Latest updates” isn’t really meant for that purpose in practice. Even a clearer distinction in naming or an optional title-focused feed would probably reduce a lot of this confusion.

 

[hakito]

The TLDR; for why the updates page works the way it does is because given the resource constraints at the time there was simply no other way to do it and have the site still be usable.

Some additional reading
https://forums.mangadex.org/threads...tch-titles-not-chapters.1523744/post-19799169

https://mangadex.dev/an-api-to-rule-them-all/

Thanks! The post you quoted is very informative although it seems to refer to "users' feeds", whereas I was referring to the (general) "Last updates". It is interesting that it focuses on the Chapters as the "items" instead of the Titles, which is that the page implies ("Titles > Last Updates"), so simply changing the text to "Chapter Updates" or similar would, at least, adjust user expectations.

FWIW, "As a user, I want to see the latest Titles updated, showing / linking to the latest chapter". I don't really care about how many other chapters have been added --or even bothersome cases like older / repeated chapters. That info is something I'll get once I go to the title's chapter (if I choose to).


As for the Dev site, well... I did not know there was a ".dev" site --nor that what was leaked was the code. That's a bit of a longer read so I'll finish reading it later

 

[hakito]

I'm not sure how you managed to say so little with so much, it's kind of impressive, so much that I'll skip to the end...

In any case, that's all I will say about this in addition to what roki already reposted. Without any attempt for logical arguments, this isn't worth arguing about further...

I agree, feel free to stop posting in this thread. Thank you.