Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Comments on Allow including larger images

Post

Allow including larger images

+3
−4

Many images and screenshots captured today, are larger than 2 MB, the max allowed size on Codidact. This means users will regularly run into a barrier when attempting to upload images to their posts (or profile). Just now, I wanted to create a new post, which would benefit from some screenshots, however, that process was more complicated than it should have to be, because I was denied uploading the screenshots, as they were too large. I can still upload them, but I'll have to go compress them first. Codidact should accept images with a larger file size more reasonable today.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

4 comment threads

Also a UX and accessibility issue (1 comment)
Realism about compression (3 comments)
Server Side is MUCH Better (7 comments)
Implementation (1 comment)
Server Side is MUCH Better
manassehkatz‭ wrote about 1 year ago

Client-side implementation has a lot of issues. What I think would work better is a server-side implementation. Something like a much larger limit - perhaps 20 MB. On upload, server code compresses on the fly down to the desired size (e.g., 2 MB) and only stores the compressed image. This is relatively easy to do in most languages. I actually created a small web site to do this for use Somewhere Else but obviously can't integrate it into that system, while I have hopes that someday I will be able to do that here (after learning Ruby, etc.). There are additional problems - a lot of casual users know how to take pictures with their phones and share them via email/WhatsApp/text/etc. but have no clue how to upload directly to a web site, so I have some ideas on fixing that as well by allowing directed emails - e.g., send to postid-image@codidact.com and it automagically is compressed and loaded into the post.

Andreas witnessed the end of the world today‭ wrote about 1 year ago · edited about 1 year ago

manassehkatz‭ Well, I just assumed the purpose of having that low limit was to reduce server load, by requiring far less data transfer. As long as the server can handle such higher limits, and there's nothing to actually save by doing it client-side, then it's a possibility to do it server-side. Although, even if the server is fine with receiving such amounts of data, the client might not have such a good bandwidth. Not too many years ago, I lived with horrible data upload speeds, and I assume lots of people still do.

a lot of casual users know how to take pictures with their phones and share them via email/WhatsApp/text/etc. but have no clue how to upload directly to a web site, so I have some ideas on fixing that as well by allowing directed emails - e.g., send to postid-image@codidact.com and it automagically is compressed and loaded into the post.*

I honestly have no idea how that makes sense. Maybe I'm too used to computers. I just don't find that to be realistic. I'm aware certain people struggle with computers, and might already know how to send a file over e-mail, for instance, but under no circumstance does that seem simpler than tapping the image upload button in the editor. It's far more complicated.

manassehkatz‭ wrote about 1 year ago

The issue isn't so much transfer time (it is a one-time thing if compression is done immediately after transfer) as it is storage space. Storage space is a lot cheaper than it used to be, but some limit is necessary for both economic and practical reasons. An awful lot of people take pictures on their phones and have no idea how to do anything with the pictures except what the phone makes it trivially easy to do. Typically that means: email, text, WhatsApp, etc. where the phone (Android or iOS) "knows" certain things to do and can feed a saved picture into another application. But the image upload button inside a web page works differently and for a lot of people figuring out how to browse/find their pictures is not so easy.

Antares‭ wrote 3 months ago · edited 3 months ago

I agree on server-side implementation. But this can also mean client-browser-side (before upload) Andreas lost his angel wings mentioned this in the other comment. Generally it should not mean user-side.

A user should not be loaded with server-side concerns. If there is need for restrictions, make them transparent for the user. Meaning: don't make them fit your concerns. That is just off-loading problems to their shoulders. Accept their input and apply your concerns on it. That is ease-of-use and the right way of handling those restrictions.

Also just stating "max 2MB" without some nice buttons offering "Auto-Resize" and "Auto-Compress" or "Auto-Upload-to-Sharing-Service" is very 1990.

Monica Cellio‭ wrote 3 months ago

The other data-transfer issue is serving the web page. We need to support a user on a phone with a so-so connection. If the page takes forever to load, that's bad - and all that extra resolution won't even be useful when it does finally load.

On the upload side, we should resize images that exceed our limit (whatever that limit is) instead of making the user do it. If we allow storing high-res pictures, we should scale down if the user agent is a small screen. Either part of this would be an improvement; both would be a big win for users.

Andreas witnessed the end of the world today‭ wrote 3 months ago · edited 3 months ago

Monica Cellio‭ Loading images should be deferred to after the page itself has loaded, such that they don't hold up loading in the page itself, and interacting with it. Additionally, you can load in lower quality versions until the full quality one has been downloaded.