MangaDex v5 Dev Suggestions: The Real Thread

[BestBoy]

@Jumballi I feel like grouping all these 1.1 and 1.2 chapter sections into a singular chapter isn't messing with the uploads so much as it is the naming convention here on MD. It'd be nice to have rules 3.2.1 through 3.2.3 explored a bit to address magazines splitting up monthly chapters into weekly/biweekly releases. If we haven't already of course. Ideally I'd like to be able to notify someone that the chapter sections need grouping.

 

[Jumballi]

@BestBoy but you can message someone at this time to regroup the chapters, the scanlation group.

 

[aaliu]

One big thing I would like to see is getting away from cloudflare (https://codeberg.org/crimeflare/cloudflare-tor/ for reasons on why cloudflare is bad)

Something more immediate would be the ability to change your username/email (once a month maybe to avoid abuse of the feature)

Another minor thing is directly hosting web fonts/icons instead of having them delivered via third party network services (I block remote fonts for a few reasons I won't get into here...)

 

[GEORECON]

This is amazing! Thanks for all you do for us!

 

[BestBoy]

@Jumballi Not if the group is disbanded or inactive for a period less than 6 months. Regardless, that naming scheme (1.1, 1.2, 1.3, etc) for regular chapters seems to be a violation of rule 3.4.4.

 

[Nakanowatari]

Maybe its just me that found it weird, but why do you guys use up arrow for descending order and down arrow for ascending order? Its on the sort by whenever i search a manga.

 

[Jumballi]

@BestBoy wouldn’t it actually be allowed by 3.4.4? Specifically the etc. part. With the chapters being release in japan as chapter 1.2 or 1 part 2, they can’t be called chapter 2.

 

[BestBoy]

@Jumballi The rule reads to me to be referencing anything that falls outside the main story of the manga as being marked with decimal notation. But all this is partly why I'd like these rules to be explored. It's a little confusing now.

 

[Holo]

@aaliu

Moving away from CloudFlare will most likely increase our monthly costs by thousands of USD for running the site. We already push almost 1PB of data per month and that only includes non-US/EU image archive traffic and recently uploaded chapters.

 

[aaliu]

@Holo

Sorry, that was kind of stupid of me to throw that suggestion out there without considering what the current network load is like . I still think it's good to keep in mind though for when another comparably priced service (hopefully) comes to light in the future. Thanks for the explanation though!

 

[Superkrza]

Rewriting the site from scratch is a huge task. Thanks for taking that on, and I appreciate all that you guys/gals are doing!

On to my feature request:
- I would love it if the read/unread tag for chapters is unlocked for users even if they don't currently bookmark (as reading) that specific manga. Use case here is that I often read chapters before bookmarking them, then my OCD has me go back to click on the chapters just to turn on the read tag.

 

[LethalDose288]

I mostly us mangadex on the tachiyomi app so o don't use the website that much i mostly use it on my phone to search manga then said manga on the app because the search features don't work on the Mangadex extension, any way what I'm trying to say is that i don't use the website to provide any feed back but i hope the redesign goes well and it helps the people who actually use this site.

 

[RonBWL]

So since my suggestion was left undecided earlier, I'll post it here

Sync "Number of Chapters" with user's setting (show unavailable chapters on/off)
-Current issue: The "Number of Chapters" always counts unavailable chapters whether user sets it on or off. This leads to confusion when you browse a manga and see it has 100 chapters but none shows up in the reader below. A simple fix is to make this number sync with showing unavailable chapters or not.

 

[kaza_hesto]

How about being able to set reading direction at the account level? While some reader settings make sense to vary by device, this one feels strange to since I don't think there would be many people who, for example, prefer right to left on their desktop and left to right on their phone.
Obviously this is low priority since the setting is always a click away, but just something to consider.

 

[Plykiya]

@kaza_hesto server side account settings for the reader will likely never happen, at least that's our current stance.

 

[stufflul]

filter Follows / Manga by language. (edit, found it! ty)
Sort by ones own Rating (not aggregated rating)

 

[Alex]

Having an option to have chapters automatically marked as read on the last page rather than the first would be nice

 

[NodiX]

Have you guys consider optimizing images with mozJPEG or WEBP upon upload? I tested optimizing a random image from one manga, and without sacrificing noticable quality it can be smaller up to 2x-3x than the original.

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/automating-image-optimization

 

[Ark6677]

I don't know if this has been brought up before, but having the ability to search within manga descriptions is something I have wanted for a long time.
Is this something that's planned with the v5 update?

 

[Annoyed]

Would it be possible to implement a completely static feature sparse reader of some kind as a user-selectable fallback for people accessing with non standard or out of date browsers? For example, people viewing from really low power computers, consoles, featurephones, etc: cases where modern js frameworks break or can't load but local download and viewing isn't an option. Its a use case representing a very tiny portion of mangadex users but it would be fantastic to have. Thank you.

Have you guys consider optimizing images with mozJPEG or WEBP upon upload? I tested optimizing a random image from one manga, and without sacrificing noticable quality it can be smaller up to 2x-3x than the original.

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/automating-image-optimization

Please, PLEASE don't do this. mozJPEG compression has very clear effects on certain types of detailing, the process combined with a rescale can make some text and sfx completely unreadable (especially on older releases or poor quality not upscaled raws), and lossy transparency will negatively affect the few webcomics that use it. Depending on implimentation it can also work poorly with compression of large aspect ratios. (webcomics uploaded in strip form, multipage spreads) This is on top of the performance load compressing these at time of delivery, or the additional space needed if both compressed and original images are kept after initial processing at upload.

If it is considered, it should be a user specific setting and off by default.