If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Provide a mechanism to expose application settings

NEW
Unassigned

Status

Firefox OS
General
4 years ago
3 years ago

People

(Reporter: vingtetun, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Many apps have various settings, and in many cases we have abuse the mozSettings API to be able to configure them into the settings apps.

It would be better if there is a define way for an application to expose a some settings. Then it would be possible to create a UI in the settings apps to configure application settings without having to open the application itself and it would also be possible for other apps to access those settings.

For example the Calendar application will be able to ask access to the settings of your Gmail application directly without asking the user to reconfigure everything by hand.

It would even be better if the way to expose those settings does not depends on the application to have a manifest or not. Then some bookmarks will be able to have some settings they expose that can be retrieved into the settings app.

My first thought about that is to have a kind of 'settings' datastore expose by apps through their manifest and think about a way for website/bookmarks to dynamically create a datastore if they want to expose those settings.

Now I'm not sure that datastore is the most appropriated solution here but it fits some use cases. Jonas, any opinions ?
Flags: needinfo?(jonas)
I'm not really sure what your goal is here.

If the idea is to be able to configure application settings through the settings app, then we have a lot of UX challenges to solve first.

The application needs to not just expose the set of "flags" or what-have-you that the settings app can configure. You also need to expose the title for those flags. And likely you'll want to group certain settings together so then you need that grouping as well as title for the group. And many things aren't simple on/off flags, but also text fields or numeric settings, so we need a data type as well. And probably some string values for enumerated types.

And then localize all of that of course.

A better solution here is likely to expose a page within the app that contains application settings. Then the settings app can link to that page directly instead.


But the main use case you are talking about is sharing of account settings. I think that sounds more like some type of identity awareness. I.e. being able to configure a google account, and then have multiple apps use that google account.
Flags: needinfo?(jonas)
(In reply to Jonas Sicking (:sicking) from comment #1)
> 
> The application needs to not just expose the set of "flags" or what-have-you
> that the settings app can configure. You also need to expose the title for
> those flags. And likely you'll want to group certain settings together so
> then you need that grouping as well as title for the group. And many things
> aren't simple on/off flags, but also text fields or numeric settings, so we
> need a data type as well. And probably some string values for enumerated
> types.

I believe that all of those can be guess from a JSON object.

> 
> And then localize all of that of course.
>

The localization can be still in the JSON object. 
 
> A better solution here is likely to expose a page within the app that
> contains application settings. Then the settings app can link to that page
> directly instead.

Do we really need to open the application process to configure a few settings ? That sounds heavy. Also wouldn't it be better if the UX/UI is the same for all apps and define by the platform instead? 

> But the main use case you are talking about is sharing of account settings.
> I think that sounds more like some type of identity awareness. I.e. being
> able to configure a google account, and then have multiple apps use that
> google account.

The fun thing beeing that the use cases I was trying to cover are those that are not related to that. So let's forget this one for now as it is a side effect.
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #2)
> (In reply to Jonas Sicking (:sicking) from comment #1)
> > 
> > The application needs to not just expose the set of "flags" or what-have-you
> > that the settings app can configure. You also need to expose the title for
> > those flags. And likely you'll want to group certain settings together so
> > then you need that grouping as well as title for the group. And many things
> > aren't simple on/off flags, but also text fields or numeric settings, so we
> > need a data type as well. And probably some string values for enumerated
> > types.
> 
> I believe that all of those can be guess from a JSON object.

Now I even remember that we were doing that in the best version of Firefox Mobile that has ever exists: the one in XUL... That was used for addons preferences.
Sure, any data can be described in JSON. Simply saying "we'll put the info in JSON" doesn't really get us very far.

Do you have a proposed format? And can you provide some examples of apps from other platforms whose settings could be solved using said format?

There's also the issue that if we put the settings in the settings app it makes the app less "webby" since settings would only be available once you install an app and not if you browse to it.

Is putting application settings in the settings app really something that's requested by UX? How about simply putting a URL in the app manifest so that we can put a link in the settings app which takes the user to a page in the app where you can configure the app?
Would it make more sense to provide webcomponent style tags that allow an app to specify settings in its own page, but automatically provide the settings app like UX and then use the URL or activities to launch from the Settings. Perhaps the manifest could have an entry to request where in Settings the link should go.
(In reply to Nikhil Marathe [:nsm] from comment #5)
> Would it make more sense to provide webcomponent style tags that allow an
> app to specify settings in its own page, but automatically provide the
> settings app like UX and then use the URL or activities to launch from the
> Settings. Perhaps the manifest could have an entry to request where in
> Settings the link should go.

Also ensure that these tags have some nice behaviour on non-FxOS devices so the app does actually work cross platform.
Blocks: 938898
Blocks: 966035
You need to log in before you can comment on or make changes to this bug.