Drag-and-drop upload

[AllAboutLearningPress]

• [x] The user should be able to upload on any page.
• [x] Error message when upload fails.
• [ ] Max file size: 20mb for raster images (.png, .jpg, etc). 11gb for source (.psd), however most are around 15mb.

[AshrafAkon]

@dyner Confirming that eleven gigabytes is the max file size for .psd. .psd files will be rendered as a normal image for viewing. But when downloaded, original file will be downloaded.

[dyner]

@dyner Confirming that eleven gigabytes is the max file size for .psd. .psd files will be rendered as a normal image for viewing. But when downloaded, original file will be downloaded.

Correct.

[andreyvolokitin]

Search by image, and general images upload:

1. Mobile devices require a button which activates a system file picker, because it's the only way to upload files there
2. It isn't possible to reliably detect mobile devices. Touch support and screen size aren't reliable signs of a mobile device like iPhone (touch can be present on desktop, screen size doesn't signify anything except a screen size, UA sniffing is fragile). That's the point of a whole mobile-first movement: can't detect mobile, so design everything with a mobile in mind by default
3. Because of 1 and 2, we have a button to pick an image for a search everywhere, including desktop
4. Adding yet another button to trigger a separate drag-n-drop for image search (and again everywhere, because we can't reliably distinguish a mobile device) looks like a bad idea

So it comes to this:

• we have 2 buttons, each triggering a system file picker: one for image search, another for files upload, which are the only working things on mobile
• we have 1 drop zone for drag-n-drop, if a single file of allowed type is being dragged — upload by default, but show the text note that a search can be activated instead by holding a key (i.e. Shift)

That's how I implemented it, but feel free to propose alternatives. The current result can be seen at the fe branch.

P.S.: not sure if image view page should also have a search-by-image thing on drag-and-drop (I think it doesn't, and currently it only have an upload)

[dyner]

@andreyvolokitin At first look I think you handled the issue excellently. I'll let you know if I have any ideas as the project progresses.

[andreyvolokitin]

The one downside is that the browser window doesn't gets active/focused right away (if it wasn't already) on file drag. So to be able to track a key press, the browser window should be first focused. For that a mouse cursor should stop, then wait a bit, then window gets activated, then it can receive key presses. Maybe something can be done about it. But the 2-drop-zones approach also have a downside — when dragging a file into the window, the target zone can be obscured by i.e. overlaying OS folder window containing dragged files. With 1 zone it doesn't matter, if you can drop anywhere, you're (almost) good to go

Another approach is to chose to search after the drop is finished and an image starts uploading regularly — i.e. click "search by this image" when it is already uploading in a standard detailed upload screen. But that seems like a complex UX

[andreyvolokitin]

(So I made the keyboard management and the instruction message to activate only when the browser window gets a focus)

[AshrafAkon]

There is no file size limit for now. I will be keeping an eye on the user uploaded image sizes. To see if we need to add one. As this is a closed software we are mostly safe on this.