The update feed should fetch TITLES, not CHAPTERS

[SomeWeeb9001]

So, from my understanding, the way the feed works right now is that there is a GET request being made for the latest 32 chapters that are in my follow list. However, since some titles upload several chapters at once, you end up with an uneven amount of titles on each page.

I guess it's not that big of an issue, but sometimes you end up with situations like this:

https://imgur.com/cUF19jd

It feels a bit... bizarre, from an UX point of view.

Why even fetch that many chapters for a single title? It's a wasted query, at that point I'll probably just go to the title itself and check what's going on.
There should be a fixed amount of titles on each page (for example, 10?), with a maximum of 3 chapters for each one. If a title has more than 3 updates, then the "Show More" button should just take you to the title itself instead.

Maybe for additional info the button could also show how many chapters were added as well? ex: Show More... (+32), would be fine without it as well, though.

I'm aware I can filter the languages to prevent similar cases, though this still happens with English translations as well, sometimes I get 3 titles on a page, sometimes I get like 10.

 

[BzzBzz]

It feels a bit... bizarre, from an UX point of view.

And that's your (wrong) opinion (c)
You dislike how it's formatted doesn't make it wrong.

There should be a fixed amount of titles on each page (for example, 10?)

There is fixed amount of chapters per page.

sometimes I get 3 titles on a page, sometimes I get like 10

No. You never get 3 or 10 titles per page. You always get X chapters per page.

Edit:

The update feed should fetch TITLES, not CHAPTERS

There is update that fetch titles.

 

[SomeWeeb9001]

And that's your (wrong) opinion (c)
You dislike how it's formatted doesn't make it wrong.

There is no professional UX designer in the world who would look at the video I posted and say "Yup, looks fine to me!", and I say that as someone who has 10+ years experience working in web development for a Fortune 500 company.

There is update that fetch titles

Ok, Fair.

The UX/UI for the updates page is still wonky though.

 

[RogueKitsune]

There is no professional UX designer in the world who would look at the video I posted and say "Yup, looks fine to me!", and I say that as someone who has 10+ years experience working in web development for a Fortune 500 company.

The UX/UI for the updates page is still wonky though.

Correct no one really likes the way that page operates, but its perhaps the best it can be at this moment given the insane resource constraints that the site has to operate under. It also doesn't help that a user's feed page is one of the most expensive pages to load.

Some reading material
Dev Blog

 

[BzzBzz]

There is no professional UX designer in the world who would look at the video I posted and say "Yup, looks fine to me!"

Here's your problem. No one gives a F about designer's opinion. Only user opinion matters. I (user) think that page designed acceptable. And that invalidates any number of designer's opinions.

someone who has 10+ years experience working in web development for a Fortune 500 company

and still pirating "chinese comics"... yea, you sure are.
btw, where's your fortune-500-dex?

 

[SomeWeeb9001]

Here's your problem. No one gives a F about designer's opinion. Only user opinion matters. I (user) think that page designed acceptable. And that invalidates any number of designer's opinions.

UX Designer is an User Experience designer, I assure you their opinions are very valued. In fact, they get paid VERY well for their input.
While you are just a singular user, an UX Designer knows what kind of design is more intuitive for a majority of users. It's quite literally their job

and still pirating "chinese comics"... yea, you sure are.

I don't know if this is something you can relate to, but people on the internet have jobs.
I buy physical volumes when I can, and I'm subscribed to J-Novel Club, but most manga isn't available officially, not much else I can do.

btw, where's your fortune-500-dex?

What, so that I can do more work after coming back from work? no thank you.

I understand if Mangadex is the best thing to ever happen in your life, but you don't need to fight tooth and nail to defend bad design, I promise I'm not taking your "chinese comics" from you, lol

Correct no one really likes the way that page operates, but its perhaps the best it can be at this moment given the insane resource constraints that the site has to operate under. It also doesn't help that a user's feed page is one of the most expensive pages to load.

Some reading material
Dev Blog

Thank you for the link, I haven't read it all yet but it seems informative.
I see that the site is using Elasticsearch, it's a good engine but I've seen it absolutely cripple sites when not correctly set up.

I can't make any judgements on that since I can't see what's happening behind the scenes, but I can see that there's some unnecessary data being sent in the response, which isn't being used anywhere on the page.
The current response size hovers at around 10 ~ 20kb after being GZipped, but removing the unneeded response data could lower that even more, which would definitely be noticeable when serving so many users (you can use Source Filtering).
At the very least, it hints that not everything is set up as good as it could be.

Also, I noticed Redis in there as well. Is it being used to cache the feed results? If not, I would recommend looking into it, it would take some heavy load off of your servers.

EDIT: Disregard the above, I just read the rest of the blog and it looks like you're indeed already doing that.

 

[Nolonar]

And that's your (wrong) opinion (c)
You dislike how it's formatted doesn't make it wrong.

You're right that disliking something doesn't make it wrong. Conversely, liking something doesn't make it right either.

But OP gave some reasons why they think this is bad design. I've personally experienced those very same reasons, so I can relate, and I agree with OP. You've given absolutely no reason as to why you think it isn't bad design, other than "I think it's acceptable". Ok, sure, but why?

That alone puts you in the wrong.

Here's your problem. No one gives a F about designer's opinion. Only user opinion matters. I (user) think that page designed acceptable. And that invalidates any number of designer's opinions.

OP is a user too, though. Also, I (user) think that design is bad (for the same reasons as OP). And RogueKitsune claims that:

no one really likes the way that page operates

I can't help but notice that you don't actually like the current design either. You only "think [it's] acceptable", which is a neutral opinion.

So 3 negative voices (at least) + 1 neutral voice + 0 positive voices paint a very clear picture: it's bad design. The designer's opinion is not invalidated in the slightest.

There is fixed amount of chapters per page.

And that is the problem. As per OP:

the way the feed works right now is that there is a GET request being made for the latest 32 chapters that are in my follow list

Not to mention you were replying to this:

There should be a fixed amount of titles on each page (for example, 10?)

No. You never get 3 or 10 titles per page. You always get X chapters per page.

This is both correct and incorrect.

It's correct that you always get 32 chapters per page. I counted them myself. And since OP got the same number, we can conclude that X == 32.

But you are incorrect to think you can never get 3 or 10 titles per page.
If one title received 32 new chapters, you'd get only one title on the page.
If two titles received 16 new chapters, you'd get only two titles on the page.
If four titles received 8 new chapters, you'd get only four titles on the page.

So you can get 3 titles if the 32 newest chapters are spread across 3 titles, and 10 titles if they are spread across 10 titles instead.

This is grade-school level maths. Any 12 year-old can confirm this.

There is update that fetch titles.

This is wrong. That page does not sort titles by updates.

I have titles on the first page that were last updated yesterday and 6 years ago, and titles on page 13 that were updated 8 days and 17 days ago. And yes, I disabled the language filter to be absolutely certain. It's not sorted by updates.

 

[OisE]

You've given absolutely no reason as to why you think it isn't bad design

The fact that I can quickly check if the update is a new chapter translated or an upload of another group uploading a chapter that I already read is useful.
The fact that I can check the number of chapters that was uploaded is useful too.

So 3 negative voices (at least) + 1 neutral voice + 0 positive voices paint a very clear picture: it's bad design. The designer's opinion is not invalidated in the slightest.

That's not representative at all, so no.

This is wrong. That page does not sort titles by updates.

No this is true, that page DOES sort titles by updates, BUT in all languages and MD's staffs are already aware of that, they will someday fix this.

I think fighting like this without giving good idea to improve the design is pointless.

For example, for batch uploads, I would like instead of counting all of these chapters in the X or 32 chapters max showned, it would be better to put the number of uploaded chapters and the 2 first and 2 last, so I can have other titles on the page.

Also, they are working on new library and MDLists functions so it might be reworked at the same time or after the rework.

 

[ieatass69]

I agree that it's a crappy design. At least crappy enough for me to go out of my way to script things into how I like it. But I guess with how perpetual MD is prepping for another revamp, maybe you need to wait a few more quarters to see any changes

 

[Nolonar]

@OisE
I think you completely misunderstand what this is all about.

Nobody here cares about how the chapters are formatted on each title.

The problem here is:
MangaDex retrieves the latest 32 chapters for the titles we follow. It then groups these chapters by title, and then display those titles on the updates list. If the latest 32 chapters all belong to 1 title, only 1 title will be displayed on the first page of the updates list. If you move to the next page, MangaDex will poll the next 32 latest chapters, etc. until there are no more chapters left to poll.

Why this is bad: It makes no sense to have a single title monopolize a single page in the updates list. It is also inconsistent and confusing.

The suggestion:
Have MangaDex poll the (e.g.) 16 followed titles with the latest updates, and display them on the updates page. There's no reason why it can't also poll the X newest chapters for each of those titles. As long as we're not stuck with just 1 title per page, that's all this suggestion is about. How exactly the chapters are organized within each title is a completely different matter altogether.

 

[OisE]

Nobody here cares about how the chapters are formatted on each title.

How exactly the chapters are organized within each title is a completely different matter altogether.

What?? I never cared about that, I was talking about the update page.

Just calm down.

 

[Nolonar]

What?? I never cared about that, I was talking about the update page.

Just calm down.

Yes, that is precisely what we're all talking about.

The update page lists a certain number of titles, each title shows up to 3 of the most recent chapters, with the rest hidden behind a "Show All" button.

The problem doesn't lie with how many chapters are listed, or if they are listed at all. The problem lies with how many titles can be listed, depending on how many chapters have been recently uploaded to a title.

Does that clear up your misunderstanding?

 

[BzzBzz]

This is grade-school level maths. Any 12 year-old can confirm this.

Not sure if you don't understand or don't want to understand what I'm talking about.
Ok, I'll try again... Just because your "always 32 chapters" just this time grouped to 3 titles doesn't mean you get 3 titles.

This is wrong. That page does not sort titles by updates.

Ok. You clearly don't understand the topic. I see no reason to argue anymore.

 

[Nolonar]

Not sure if you don't understand or don't want to understand what I'm talking about.
Ok, I'll try again... Just because your "always 32 chapters" just this time grouped to 3 titles doesn't mean you get 3 titles.

Are you ignoring the "per page" part on purpose?

It's even on the first paragraph of the very first post you replied to:

you end up with an uneven amount of titles on each page.

1. Each page displays 32 chapters grouped into titles.
2. If those 32 chapters belong to 3 titles...
3. ... then the page will display 3 titles.
4. Therefore the Updates Feed will display anywhere between 1 and 32 titles per page, depending on how the latest chapters are spread out.

This is not a theory or a fever dream. This is how it works right now. This is what we've observed while using this site. And it's precisely because we don't like this behavior that we're here asking for it to be changed.

If you have no idea what we're talking about, then go away. You're not contributing to this discussion in any way whatsoever. You're not trying to list the pros and cons of the current system vs the suggested one. You're not trying to improve on the suggestion or provide counter-suggestions. What are you even here for? I can guarantee the devs don't care if you think they're hot or not. The suggestions forum is here because they want to improve MangaDex, not because they want people sucking up to them.

Ok. You clearly don't understand the topic. I see no reason to argue anymore.

So here's my Follows Library (page 1):

Spoiler

It contains Spy Classroom, last updated 2 years ago:

Spoiler

Here's the last page of my Follows Library (page 13):

Spoiler

It contains The One Within the Villainess, last updated 18 days ago:

Spoiler

As well as Sansha Sanyou, last updated 4 years ago:

Spoiler

And for the last time, I've explicitly disabled my language filters when testing this and making my screenshots:

Spoiler

2 years -> 18 days -> 4 years
Does that look sorted to you?

It. Does. Not. Work. At. All. The. Way. You. Claim. It. Does.
Not even remotely.

Are you absolutely certain you understand what this topic is about?

 

[Varpie]

The suggestion:
Have MangaDex poll the (e.g.) 16 followed titles with the latest updates, and display them on the updates page. There's no reason why it can't also poll the X newest chapters for each of those titles. As long as we're not stuck with just 1 title per page, that's all this suggestion is about. How exactly the chapters are organized within each title is a completely different matter altogether.

The problem with that is that it becomes a lot more resource intensive.

The current system fetches the most recent 32 chapters because it's easy: we just have to query the list of chapters, order by last updated and take the top 32. Since 32 is a power of 2, there is probably some extra optimization as well.

With your suggestion, the user would have to do one request to fetch the 16 last updated titles, which is the same complexity as getting the last chapters, then either make 16 more requests to get the last updated chapters on each title, or make a request with extra joins (which are expensive).
In either case, it would require extra resources compared to what we currently have, which is why it isn't done.

I personally think the solution would be a heavier frontend, that keeps in the browser's IndexedDB the chapters that have already been fetched, and would allow us to fetch new chapters only up to the most recently fetched before. So that if I go to the updates page after finishing a chapter, it would only ask for chapters newer than the time it took me to read that chapter, rather than fetching 32 chapters every time.
Fetching 32 chapters at once would then only happen if you've been away for a while, which could free up resources and allow people to fetch multiple times to fill the page in case we don't have many different titles.

 

[Nolonar]

The problem with that is that it becomes a lot more resource intensive.

I think your idea of using a client-side DB cache is a good solution for this problem. Support for the feature seems to be reasonably good, too.

 

[tristan9]

Why this is bad: It makes no sense to have a single title monopolize a single page in the updates list. It is also inconsistent and confusing.

Fwiw, as we've stated before too, we agree it's not ideal.

The problem is that right now, we can't do better. But we do want something that would instead be (for example) the last $someNumber chapters from the last $anotherNumber (let's call it N) titles you follow .

Unfortunately, that is a much more complicated question to ask of a computer, which is why it's not how things work, until we optimise things to be workable that way.

But as you see here, you do need to pick:
1. A number of titles per page <= hard to choose but can be made configurable
2. A number of chapters per title <= really hard to choose, because you don't want ALL chapters ever pushed for a title, and you don't know how many make sense (is it last day? last week? last month? depending on the number of titles? ...)

There's a reason many sites take the same approach as us of sorting by item (chapter), not parent (title). Think of how youtube's subscriptions page is a list of videos, not of channels. Aside from expensive, it is genuinely not obvious what the right way is (besides saying something like "32 chapters, AND within at least 5 titles")

 

[jhs_reika]

Are you ignoring the "per page" part on purpose?

It's even on the first paragraph of the very first post you replied to:

1. Each page displays 32 chapters grouped into titles.
2. If those 32 chapters belong to 3 titles...
3. ... then the page will display 3 titles.
4. Therefore the Updates Feed will display anywhere between 1 and 32 titles per page, depending on how the latest chapters are spread out.

This is not a theory or a fever dream. This is how it works right now. This is what we've observed while using this site. And it's precisely because we don't like this behavior that we're here asking for it to be changed.

If you have no idea what we're talking about, then go away. You're not contributing to this discussion in any way whatsoever. You're not trying to list the pros and cons of the current system vs the suggested one. You're not trying to improve on the suggestion or provide counter-suggestions. What are you even here for? I can guarantee the devs don't care if you think they're hot or not. The suggestions forum is here because they want to improve MangaDex, not because they want people sucking up to them.


So here's my Follows Library (page 1):

Spoiler

It contains Spy Classroom, last updated 2 years ago:

Spoiler

Here's the last page of my Follows Library (page 13):

Spoiler

It contains The One Within the Villainess, last updated 18 days ago:

Spoiler

As well as Sansha Sanyou, last updated 4 years ago:

Spoiler

And for the last time, I've explicitly disabled my language filters when testing this and making my screenshots:

Spoiler

2 years -> 18 days -> 4 years
Does that look sorted to you?

It. Does. Not. Work. At. All. The. Way. You. Claim. It. Does.
Not even remotely.

Are you absolutely certain you understand what this topic is about?

Updated sorting does work, though not in the specific meaning that most users wants.
It is literally sorted by update time, meaning the last time any changes were done on that title.
Adding a new chapter obviously included in that, as well as removing chapters, renaming chapter title, and some others I'm not sure of. Maybe modifying synopsis, changing tags, and adding alternate title and art too.
Basically like last modified time of computer folder.

So yeah, we need better sorting. Though it'd be time consuming to implement.

 

[Varpie]

Updated sorting does work, though not in the specific meaning that most users wants.
It is literally sorted by update time, meaning the last time any changes were done on that title.

I believe there's also another major issue that makes it less relevant: chapters released in another language will update the time a title was updated.
Which makes sense, but it means that a manga that hasn't been touched for years, and just got picked up by a scanlation team in another language, will likely stay in those most recently updated ones for a while.

And of course, having to ask the most recent chapter in your specific language every time we want the last update on a title is expensive, and adding a timestamp for every language a title is translated in could increase its size by a lot, which would be more of an issue on the more popular titles (that have more diverse translations), typically those we want to optimize the most, so it's not a trivial problem to solve.