feat(#370): adds file and video upload#742
Conversation
🦋 Changeset detectedLatest commit: 665a139 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
@latin-panda Can I get a review please? I'll tag QA and Aly to test. |
There was a problem hiding this comment.
Looks good! I tested on the desktop and phone. I left a couple of comments below, but approving to unblock.
Remember to use the new CSS variables for spacing 🙂
Would you like to release after this is merged? I believe the Central minor release is coming up soon.
packages/web-forms/src/components/form-elements/upload/UploadControl.vue
Show resolved
Hide resolved
| <template> | ||
| <div class="file-preview-content"> | ||
| <span>{{ fileName }}</span> | ||
| <Button severity="secondary" @click="$emit('clear')"> |
There was a problem hiding this comment.
This button is difficult to locate because it's far from the file name. Could it be positioned closer or have a darker border?
There was a problem hiding this comment.
QA raised the same concern... I'll continue the discussion on Slack.
| <!-- TODO: translations --> | ||
| <span>Choose file</span> | ||
| </Button> | ||
| <input |
There was a problem hiding this comment.
When there is no accept, the default on my Android phone is either camera or gallery. Is it possible that the default is "My files"? Collect opens "My files" and it is more convenient because I can search for any file easier.
There was a problem hiding this comment.
As far as I can tell this isn't possible. Some people say it's a feature not a bug, because users should be able to choose. But it's not great in this case, because in the image upload we have a dedicated button for "take picture" so if they see this the user has already chosen to upload a file.
There was a problem hiding this comment.
Something that seems to work is defaulting the accept to `application/octet-stream', it opens "My Files" and I'm still able to choose video, images, audio, pdf, etc... It's opinionated, but the user experience is better, more useful.
There was a problem hiding this comment.
Nice find!
It seems like there are two places where this could be useful...
- When the form builder is using a generic file upload (not image, video, or audio) and hasn't specified any mimetype or accept parameter. In this case, I would argue it is a better UX to allow the user to choose if they want to capture the file, or select one from the phone. If you default it as you say then they would have to use the camera app first and then select from the file picker. Also, I'm not sure if that's behaviour is a bug or a feature, so I'm reluctant to rely on it.
- When the form builder is using an image control (or video and audio when capture for those is supported) and the user selects the "Choose image" button. In this case the user has already made the choice NOT to take a photo, so prompting them again is annoying. However in this case we actually do have an accept parameter, for example,
image/*. If we replace this withapplication/octet-streamthen we lose the automatic filtering to show only images in the file picker which can be very helpful.
What do you think?
There was a problem hiding this comment.
If you default it as you say then they would have to use the camera app first and then select from the file picker. Also, I'm not sure if that's behaviour is a bug or a feature, so I'm reluctant to rely on it.
I'm confused by this piece. Are we perhaps seeing different behaviors in Android?
I tried accept="application/octet-stream" in the default file question type, when no mimetype and accept parameter where provided. Then, when tapping on the button to pick a file, it opens the file inspector (no camera, no gallery). From there, I can pick any file type, which seems correct since the Form Designer didn't specify any details about it.
I would use accept="application/octet-stream" only in that case where any file/binary data is accepted.
When the form builder is using an image control (or video and audio when capture for those is supported) and the user selects the "Choose image" button...
Yes, I wouldn't use application/octet-stream and would default to image/* (or video/*, audio/*, respectively) when the file types weren't provided by the Form Designer. The OS will decide how to handle that situation. However, for the 'take picture' button, the camera can be enforced using the capture attribute, which is supported by all mobile browsers. The difference between the two buttons is so small that it might make sense to just combine them and always use the camera with capture
There was a problem hiding this comment.
@latin-panda and I caught up in meet regarding this and as it mostly comes down to user experience decided to merge this as is and iterate based on user feedback.
garethbowen
force-pushed
the
370-file-upload
branch
from
bd760fe to
2d6e8d2
Compare
2 participants
Closes #370 #702 #622 #703
I have verified this PR works in these browsers (latest versions):
What else has been done to verify that this works as intended?
Why is this the best possible solution? Were any other approaches considered?
I went away from the primevue fileupload control as there wasn't enough overlap between it and our designs, for example, we don't actually upload the file until submitting the form.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Do we need any specific form for testing your changes? If so, please attach one.
The three forms in
/packages/common/src/fixtures/upload/What's changed