I knew, when designing the "Location" settings, that I'd soon be
designing settings for other app privileges too. I didn't put "Location"
in its own screen merely because I designed it first, and it's not
correct that "there really isn't any reason why Location shouldn't be
grouped with the other trust-store-enabled services". There are two
reasons. First, most people using the phone will not, and should not,
have any idea that audio recording is a "service", nor any idea that the
Ubuntu code includes something called a "trust store"; so that's not
relevant to which organization is best. And second, there are three non-
app-specific items in the "Location" settings design: the global
"Location detection" switch, the "Send occasional location data" switch,
and the "Privacy policy" item. Since those aren't about individual apps,
they would seem weird inside a branch of System Settings that was
labelled as if it *was* controlling individual apps, while separating
them out would mean we'd awkwardly have two screens of location-related
settings.
Now, it might still be best to group all the app privileges together ...
just not for those reasons. What makes the word "should" a danger sign,
in a bug report title, is that it both assumes the problem and assumes
there is only one possible solution. Here, there's little empirical
evidence for a problem, and there are at least three other ways these
settings could be arranged.
(A) As you suggest, all inside "Security & Privacy", something like
"Things apps have access to", then organized by service: a screen for
each service, each with a toggle list of apps.
(B) All inside "Security & Privacy", something like "Things apps have
access to", then organized by app: a screen for each app, each with a
toggle list of services. (Benjamin Keyser has suggested this.)
(C) As many as possible inside related screens: for example, app access
to location with the rest of the "Location" settings, app access to the
microphone with the rest of the "Sound" settings, and app access to your
call history with the rest of the "Phone" settings.
These aren't mutually exclusive. For example, we could do both (A) and
(B) with a control to toggle between those views. Or we could take
approach (C) for some services, and a different approach for others.
It's fortunate we can mix and match, because some services are much more
interesting than others. For example, notifications are a high-profile
service where we provide external control over whether apps can use
them. (I don't know whether notifications use the trust-store or not,
but remember, that's not relevant.) It's harder to tell, in the first
few minutes of using an app, whether it's a good idea to give it the
ability to send notifications than whether it's a good idea to give it
the ability to access your location. Therefore, people will change their
mind about whether an app uses notifications much more often than about
whether an app uses their microphone. That's why "Notifications"
deserves to be at the top level of System Settings, while "Microphone"
is much deeper.
As for the wording, it's true that "Other app access" is not a brilliant
example of clarity. If I had room I would have called it "Other things
that apps have access to", but as it is, it sounds like it's referring
to some "other apps". If that's your real problem here, I'd be happy to
narrow this bug report to just that issue and brainstorm some
alternative phrases. Otherwise, please reopen if you have evidence that
the current arrangement is causing findability or efficiency problems.
** Changed in: ubuntu-ux
Status: New => Incomplete
** Changed in: ubuntu-system-settings (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1374570
Title:
'location access' and 'other app access' should be merged
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-ux/+bug/1374570/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
