-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix drag and drop area for file choosers by adding separate ones #2368
Fix drag and drop area for file choosers by adding separate ones #2368
Conversation
- Add separate drag and drop area for file choosers ### Why? Previously, when there were multiple file choosers in the same page, if you attempted to drag and drop any files, they would be added to both file choosers as it was designed at first to handle 1 file chooser present, now that we have multiple ones, it is necessary to adapt our design to match the changing functionality. ### Can you not preserve the old overlay when there's only one file chooser present? Yes, we can, but imagine as a user, you try to drag and drop a file in one page and the fields turn into drag and drop areas then you go to another page and try to drag and drop again but you encounter the old overlay instead, as a user you might get confused and ask yourself "What changed?" or if a user is telling another user the steps to drag and drop files and he didn't know about this case, then it would still be confusing, thus consistency is preferred in this case.
I think we should increase the height of the drag drop area maybe 50-100% more |
Yeah to be honest i think we could replace the whole file input "Click to upload OR drag and drop" and have it remain as the dotted outlined box version I think continuing using the Browse inputter is something we should stop |
This is what I went for some far (I might change font colors to go along with the dark/light modes, same goes for the background and the button color, but this is ) (the image is below). The bottom box should stay hidden unless there are files uploaded. Each uploaded file should have an icon based on its extension, if it's unknown or we have no icon for it at the moment it should be represented as an empty document icon as in the last icon in the second row. Each file should have its name displayed (if it's too long then you'll have to hover the name) and the file size (we might convert it to the closest unit, example: files less than 1 MB could be represented as X KBs - where X is the size of the file after conversion - files greater than 1 MB and less than 1 GB would would represented as X MBs and so on). Why include the name and size and not just "name"? in case more than one file had the same name but different sizes, so that the user can remove the correct one. Why use a box containing icons and their info rather than have them in a vertical list? Because it would occupy less space, if the user has too many files, that way the user wouldn't have to scroll too much. Let me know if you have any notes/questions/ideas |
Looks awesome! Will review more tomorrow and merge! Awesome work as always |
I'm very happy with the implementation you described and reasoning |
Awesome! Thanks a lot! I will start pushing my changes so that it would be ready by tomorrow hopefully |
- Selected files are listed below the file chooser in a selected files container. - Users can now remove uploaded/selected files. - Hide selected files container/box unless there are files selected/uploaded. - Add separate overlay for each drag & drop area. ## FAQ: - Why did you assign a unique id to each file? isn't the filename enough? = Because a user might upload multiple files with the same name, if the user wanted to remove one of them, how would we differentiate between them? we won't be able to unless we assign an identifier, you might argue "we remove based on the filename and size", then what if the user uploaded the same file more than once (intentionally), then we would accidentally remove all the files even though that is not what the user wanted, so going with unique ID approach would prevent this issue/problem from occurring in the first place.
- Rename remove-file css class to remove-selected-file to avoid css conflict with remove-file in merge.css
Use the correct element to dispatch "file-input-change" (input element is the correct one).
The only thing remaining for me is to take a look at how themeing (dark/light) works in the project, to make the UI change based on the current theme, other than that, I believe it's ready. (It still works with light theme but it doesn't look good, so we would need to adjust that) |
Nice I'll hold off merge and review the current impl /deploypr |
🚀 PR Test DeploymentYour PR has been deployed for testing! 🔗 Test URL: http://185.252.234.121:2368 This deployment will be automatically cleaned up when the PR is closed. |
- Adapt file chooser UI to themes by adjusting their font colors and background colors. - Make text more visible in overlay by increasing the font size by 0.1rem and setting font weight to 550.
- Removing overlay's border as it is unnecessary and only causing a double border issue on the file input container.
Might be good to have the whole box be clickable instead of just the browse button |
- Remove browse button. - Make the entire file chooser container clickable. - Add glowing effect on hover for file chooser. - Change color of file chooser on hover.
After making the changes: Light:Dark:I changed the background color on hover as well as adding a box-shadow (glowing effect) on hover, I tried to make the border thicker on hover, but it didn't look good nor smooth when transitioning from thin border to a thicker one, so I went with the glowing effect instead.
I also removed removed the browse button and made the entire box clickable as mentioned
Let me know if you have any notes/questions/ideas (The GIF might not be clear due to quality and resolution changes) |
Looks good to me! Speedy work too! |
🚀 PR Test DeploymentYour PR has been deployed for testing! 🔗 Test URL: http://185.252.234.121:2368 This deployment will be automatically cleaned up when the PR is closed. |
Now, merge should work successfully, I also fixed the issue where files being removed from merge's list wouldn't reflect in the file chooser. |
🚀 PR Test DeploymentYour PR has been deployed for testing! 🔗 Test URL: http://185.252.234.121:2368 This deployment will be automatically cleaned up when the PR is closed. |
files removed from file choose doesn't reflect in merge list though |
I think duplicate file viewing on merge doesn't add much value anyway, if we can figure out a way to remove it for merge it would prob be best |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All working great now as far as I can tell. Thanks for fixing it so promptly!
- Make inputElement optional in removeFileById, this way we could control changing inputElements files.
I believe it's now fixed, it seems like I forgot to do a quick regression testing for file chooser's file removal (as I refactored a little bit of code to reduce duplication when I fixed merge's file removal bug) that's why I didn't notice the bug |
/deploypr |
🚀 PR Test DeploymentYour PR has been deployed for testing! 🔗 Test URL: http://185.252.234.121:2368 This deployment will be automatically cleaned up when the PR is closed. |
I believe we forgot to include translations for "Click", "or" and "Drag & Drop" |
good catch! |
Alright, I will try doing that |
Im also happy to do it in another PR after merge if you are busy :P lemme know! |
It's totally fine, don't worry, I was just stuck with a bug when I was trying to use translations with pseudo element (::after), turns out there was no bug I just placed th:data-text on the wrong HTML element :D
I already added it to messages_en_GB.properties, but I also added it to messages_ar_AR.properties (I haven't yet committed the changes), if this would cause any issues let me know, if not, let me know as well so that I would push the changes |
nope thats all good! |
🚀 Translation Verification Summary🔄 Reference Branch:
|
You can now merge :D |
Merge conflict with your other PR i think? #2365 |
🚀 Translation Verification Summary🔄 Reference Branch:
|
Resolved the conflicts, thanks for letting me know |
I believe this also closes issue #2372 |
Description
Why?
Previously, when there were multiple file choosers in the same page, if you attempted to drag and drop any files, they would be added to both file choosers as it was designed at first to handle 1 file chooser present, now that we have multiple ones, it is necessary to adapt our design to match the changing functionality.
Can you not preserve the old overlay when there's only one file chooser present?
Yes, we can, but imagine as a user, you try to drag and drop a file in one page and the fields turn into drag and drop areas then you go to another page and try to drag and drop again but you encounter the old overlay instead, as a user you might get confused and ask yourself "What changed?" or if a user is telling another user the steps to drag and drop files and he didn't know about this case, then it would still be confusing, thus consistency is preferred in this case.
UI Change:
Before dragging and dropping:
During dragging and dropping:
Closes #2367
Checklist