You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the user problem or growth opportunity you want to see solved?
To address issue #5196, we've right now switched from the ACTION_GET_CONTENT to the ACTION_OPEN_DOCUMENT intent. This is because the GET_CONTENT trigger the new photo picker on devices in which the take_over_get_content is enabled [ref]. The new photo picker has the potential to strip location info from EXIF despite the app having ACCESS_MEDIA_LOCATION permission [ref]. [See also: our related help doc].
Using the ACTION_OPEN_DOCUMENT has the benefit that it always triggers the Documents based picker on all devices. OTOH, the triggered UI only allows picking files via the document viewer without providing any option to pick images from third-party gallery apps. The ACTION_GET_CONTENT intent provides that option. See screenshots below for reference.
ACTION_GET_CONTENT picker screenshot
ACTION_OPEN_DOCUMENT picker screenshot
That said the concern of GET_CONTENT picker not providing location when it triggers the new photo picker is also valid. Considering this, rather than completely switching to the OPEN_DOCUMENT intent, I suggest the following:
Use the GET_CONTENT intent by default.
Observe whether the images uploaded via the standard picker have location information
When user uploads (say X) images without location via the standard picker, intimate user regarding the switch that allows the use of an alternate file picker
In case the user suspects that the location information is being stripped, they are sure to enable the OPEN_DOCUMENT based file picker and report to us in case that fails too.
How do you know that this problem exists today? Why is this important?
This provides a better UX file picker for those users for whom GET_CONTENT is able to upload issues with location without any issues. For those who are affected by the new photo picker, our intimation regarding the existence of the toggle would help them switch to the different picker as necessary.
So, this kind of solution would offer a balance b/w usability and prevention of location loss.
Who will benefit from it?
Any user who is using the app so far and is accustomed to the standard picker opening the GET_CONTENT intent based picker.
Anything else you would like to add?
No response
The text was updated successfully, but these errors were encountered:
What is the user problem or growth opportunity you want to see solved?
To address issue #5196, we've right now switched from the
ACTION_GET_CONTENT
to theACTION_OPEN_DOCUMENT
intent. This is because the GET_CONTENT trigger the new photo picker on devices in which thetake_over_get_content
is enabled [ref]. The new photo picker has the potential to strip location info from EXIF despite the app having ACCESS_MEDIA_LOCATION permission [ref]. [See also: our related help doc].Using the
ACTION_OPEN_DOCUMENT
has the benefit that it always triggers the Documents based picker on all devices. OTOH, the triggered UI only allows picking files via the document viewer without providing any option to pick images from third-party gallery apps. TheACTION_GET_CONTENT
intent provides that option. See screenshots below for reference.ACTION_GET_CONTENT picker screenshot
ACTION_OPEN_DOCUMENT picker screenshot
That said the concern of GET_CONTENT picker not providing location when it triggers the new photo picker is also valid. Considering this, rather than completely switching to the OPEN_DOCUMENT intent, I suggest the following:
OPEN_DOCUMENT
based file picker and report to us in case that fails too.How do you know that this problem exists today? Why is this important?
This provides a better UX file picker for those users for whom
GET_CONTENT
is able to upload issues with location without any issues. For those who are affected by the new photo picker, our intimation regarding the existence of the toggle would help them switch to the different picker as necessary.So, this kind of solution would offer a balance b/w usability and prevention of location loss.
Who will benefit from it?
Any user who is using the app so far and is accustomed to the standard picker opening the GET_CONTENT intent based picker.
Anything else you would like to add?
No response
The text was updated successfully, but these errors were encountered: