Scary Quest permissions dialog
@mikesky - considering it's triggering bad reviews - what can we do to improve first impressions regarding the scary "we can access all your files" warning?
36 Replies
1. Can we show it later in the process? (when the user saves their first sketch?)
2. Can we give more context before the OS dialog appears? ("not our fault, guv. Blame Meta")
3. Can it be optional? ("Feel free to say 'no' but don't come crying to us when you lose all your work)
the lowest common denominator often ruins things
I think the newest OS update has fucked us as the scary popup isn't even popping up for some users anymore, judging by our one star reviews. we might need to do more on the loading screen now.
1. No, we do a lot of stuff on initial run like unpacking samples and generating OpenBrush.cfg
2. This could be possible, but better make it generic in case Pico do something similar
3. Could be, but then we'd need to save to the persistent path location. two paths for saving sounds horrific, especially for support/troubleshooting
Yeah. (3) was a case of "it would be cool to do this but I'm not volunteering"
a button to explicitly run the popup again might be useful on the loading screen
(1) could be solved by deferring some of this stuff until later.
could also check if SAF is finally implemented, but i doubt it
re: (2) - that wasn't meant as my proposed draft of the wording. (although, i wish...)
@andybak @mikeage okay, SAF may be an option. you don't have to sleep/wake anymore on my test branch
the app goes black but comes back immediately when you press the oculus button, which is what you need to do anyways with our current jank
ok. so an improvement with no downsides?
can i try a build?
this is a test with a plugin rammed in there, it's not actually functional for what we need
it was just a "select a file using SAF"
we need "select a folder using SAF"
that's fine. i just want to see what the ux is like
oh, sure
i guess - i could watch the video!
GitHub
Merge branch 'main' into feature/file-picker-meta · icosa-foundatio...
Open Brush is the open source, community led evolution of Tilt Brush! Forked from https://github.com/googlevr/tilt-brush - Merge branch 'main' into feature/file-picker-meta · icosa-...
i mean yeah the video shows it, haha
so. what if they pick the wrong folder?
i.e. a folder with stuff already in it?
and can they create a folder with a different name than our default?
"how many ways could this go wrong?"
Yes to all the above? 😄 we can guide them to the right spot so all they have to do is click a button that's "Select Folder"
they have to create an empty folder i presume? or do they just pick their main documents folder?
We can't use our current one, I will add.
ugh
They pick their documents folder, then we can create /Open Brush inside it
and if they already have one?
we already have permissions in that case so --- we can move the files?
yeah so there's a provision that we can nab our old files from the current folder location
I'm in favour of doing this but I'd really like to not be the person doing it!
Yeah this one is probably on me, I accepted that 2 years ago 😂
@sbanca and @leon_van_kammen#4615 both seem to still have a high tolerance for these kind of tasks! (i.e. they are less burned out and jaded than me 😆 )
that won't last...
that won't last...(I realise that can be interpreted in two different ways. that's probably for the best)
@andybak we'll also need to do SAF stuff before we can use the Play store anyways
google will definitely not let us publish with the MANAGE stuff
weirdly the current apk works fine on my phone
ah - yeah.. review
but yeah - it does work for me on recent android
good to know!
Nextcloud (self hosted google suite alternative) just got hit by a similar limitation. Some users moved to the F-droid version; most just complain 😉
next challenge. building an .aab instead of an .apk
@mikeage ?
Builder | GameCI
Building the project as part of a workflow may help to create mind-space and focus on the project
I didn't try this, but it seems like it should work
Although maybe our custom build method also needs to change
Yeah it's that. though I did wonder about using the "export project" option for a single android build, then doing the custom stuff from that exported project
seeing as in the future, the quest build will just be a package rename