Per-app Settings feature discovery issue

asked 2017-06-12 20:44:06 +0300

pisarz1958
1123 ●19 ●36 ●41

This is just me complaining about UX, nothing to see here.

It's really nice to have a centralized place where you can access your apps settings but to be fair, the current setup leads to some UX problems imho. So, the current flow expects you to go to settings app, find "Apps" on the list and tap on an icon to access settings for a given app. The ones that don't have it (or simply have settings shoved in to the main app cause almost nobody is writing plugins that integrate with this menu). Also, AlienDalvik apps always have some screen available, which shows some basic info about it and let you kill it, reset it etc. - which seems like a way more natural flow to me.

This leads to a really confusing flow for a user. I'm pretty new to SFOS and at first I thought there are no settings for system apps at all, until I accidentally found it while exploring the settings. Here is an example:

User wants to change the unit from Fahrenheit to Celsius in Weather app.
User checks the pulley menu for "Settings" entry (this is what everyone is used to and some Sailfish app from Harbour follow that behaviour).
There is no settings entry, so user switches back to settings app.
User taps on Weather app and finds a list with just one entry.

I think following the trends here seems more user-friendly and natural, so in this case "Apps" settings would simply let you manage your apps (as it does for AlienDalvik apps already) and app settings could be moved to a more intuitive place. You could still leave some kind of shortcut there so it'd be easier for die-hards to get used to the new way of living.

answered 2017-06-12 22:00:44 +0300

Dylan Van Assche

3781 ●75 ●105 ●124

https://www.dylanvanassch...

updated 2017-06-12 22:01:58 +0300

The problem is that the API for adding settings for each app in Settings App is not allowed by Harbour due the priviliged level on which the Settings App runs.

We developers want to use it but then we can't publish it in Harbour. I understand this is confusing but it's up to Jolla to allow this (we're asking this for several years now).

edit flag offensive delete publish link

Comments

So it seems like we have another problem here, since we have a central hub for app settings that nobody can tap into. If this is some kind of a security issue, maybe it would be better to not have it as this kind of hub at all?

pisarz1958 ( 2017-06-13 10:33:48 +0300 )edit

If this is some kind of a security issue, maybe it would be better to not have it as this kind of hub at all?

The Settings pages running with a higher privileges so allowing them to be used by the Harbour apps would lead to a potential security issues.

AFAIK the following things need to be done to support this:

The Settings page must run the Harbour settings pages with reduced privilege. This seems to be an easy task.
- The Settings page needs to be modified to be able to detect if an app settings page is coming from a Harbour App or not. To make it simple I think separating the Harbour apps pages to a separate folder could be an option (/usr/share/jolla-settings/entries for the Jolla apps, /usr/share/jolla-settings/entries-harbour for the rest). This change would require an OS upgrade.
The Harbour rpm validator should be patched. This had been done already see here: https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/pull/79

martonmiklos ( 2017-06-13 21:41:22 +0300 )edit

There is one more thing though. Even if any dev could use it, users, especially new ones, might simply not know it's there. So either we need to educate users about it or simply put these in a place that's more natural and obvious. Maybe simply some other way to access these plugins.

pisarz1958 ( 2017-06-14 00:50:18 +0300 )edit

Per-app Settings feature discovery issue

1 Answer

Comments

Question tools

Stats

Related questions

Per-app Settings feature discovery issue

1 Answer

Comments

Question tools

Public thread

Stats

Related questions