People Don’t Read Similar Dialogs
See a problem there? Well, I didn’t, and neither did my testers. But the dialogs are very similar – same heading text, same buttons – the fine print is different and the Default Folder X icons are in different places, but they’re a lot alike. The first dialog pops up, and after you follow its instructions, it is automatically replaced by the second one. Because they look alike, a lot of people thought that the instructions hadn’t changed and that they were stuck, with no option but to hit the “Quit Without Authorizing” button. And send me a freakin’ email… I got lots of email.
I’ve seen this type of thing with my apps, as well.
He has an interesting solution to the problem of requesting Full Disk Access: an icon in the app’s dialog that the user can drag and drop into the System Preferences window. I’ve had issues with customers not seeing + button to manually add an app and not being able to find the desired app, e.g. because the Applications folder was sorted by date instead of by name. This avoids those problems, however I’ve also seen people get confused when asked to drag between two windows, particularly when one may be partially on top of the other. I wish macOS had an API to request Full Disk Access. The current approach is sort of like security through obscurity.
Previously: Mojave’s New Security and Privacy Protections Face Usability Challenges.
9 Comments RSS · Twitter
I've had pretty good results with helping people authorize Full Disk Access by giving them the draggable icon in the dialog. One associated trick is to also position the dialog window so it is right next to the System Preferences window. They first click an "Open System Preferences" button, that brings up System Preferences > Security & Privacy > Privacy > Full Disk Access. Then the dialog with the draggable icon pops up _right_next_to_ the System Preferences window. Sort of a "Here's System Preferences, now here's what you do next."
@Jon Do you have to first request Accessibility access to be able to figure out where the System Preferences window is (and move it if it's in the middle such that you can’t position next to it)?
No, you can use CGWindowListCopyWindowInfo() to get window locations without resorting to the Accessibility API. Shoot me an email and I can send you the code (though it's Obj-C, not Swift...).
@Jon Did you get feedback from users who dragged the app icon into the /Applications folder (in the Finder) instead?
@Jon Oh, that’s great. I’m familiar with that API, but I thought it had been locked down. And AFAIK it’s read-only.
Stefan Fürst and I have implemented a mechanism much like what @Jon describes. We bring up Privacy Preferences using the x-apple.systempreferences URL scheme and then position a window with a draggable icon and instructions next to the System Preferences window. You can see this in action in CheatSheet (video: https://vimeo.com/314000152 , app: https://mediaatelier.com/CheatSheet/?lang=en ) and HoudahSpot (video: https://vimeo.com/314006679 , app: https://www.houdah.com/houdahSpot/ )
Apple kindly made the behavior, user experience, and API different between the various privacy domains. Dragging works for Accessibility and Full Disk Access. Most other areas list applications that have request access and just need the user to check a box. So that is what the floating instructions window will say. Automation has multiple checkboxes for each application. It requires longer instructions.
@Will Yes, I did get a support email from one user who dragged the icon to his /Applications folder, so confusion's still possible. I think the solution @Pierre came up with, putting a narrow bar below Sys Prefs and including arrows showing where to drag the icon, is a better solution. The only time that'll cause confusion is if the x-apple.systempreferences URL scheme fails to open the correct pane in Sys Prefs (I've had trouble with it not going to the Automation pane myself).
@Jon The URL scheme is indeed not always reliable. We call open the URL with the anchor for the name we want to show. Then we wait for NSWorkspaceDidActivateApplicationNotification for System Preferences and open the same URL again. With two those attempts it has yet to fail.
@Pierre That is a really nice solution. Only problem i can see is when the screen resolution is too small. But that's an extremely rare case these days.
