Hi Philip,
thx for the Update and all the valuable background information added for the approaches in current solutions.
Enclosed my feedback. - secrets & passwords ==> move to security paper Its ok for me to move this scope to the security paper, with that we can also add more context to it like discussed in another thread. (see enclosed email). But please do not forget a reflection of rollback and its impact the "user secrets and password" approach and where to add this reflection (this paper - e.g in chapter 5 approach - or the security paper - which I feel would may fit better).
The remaining topic to concentrate on is - 5.1.5 user interfaces
I have the feeling we are not on the same page so far. To make it easier to understand, let's call it "an iOS like" solution. There is a settings App, bundled with the system like an App-Launcher Application - providing the preferences to the User. An App carries stuff to be configured in some way, e.g. a manifest, this gets interpreted by some "Settings App" and shown to the User in a consistent way.
- A user do not has to step into an app and to search for it to configure it, it’s at a central place. - We also do not have to coordinate all the different kinds of possibilities to incorporate it within Apps (at different places and in different way) - An OEM can decide to remove configurable parts in his product, so that only a subset gets published to the user for a specific device. - An OEM can also change the look and feel of the Settings-App and it keeps consistent, no need to change the App - One can optionally re-organize / combine configurations of same kind over all Apps into one view (e.g. similar like "privacy" settings) - We can easily add Search capabilities (over all Apps), to help Users to find the topic of interest independent of their organization
Often there are "configurations" which modifies the App behavior but used by the system-integrator at point in time of product creation. By intention, they are not transported to the Used for configuration. It limits the capability of the User, but also reduces complexity. Its maybe used for variant handling. However, it is highly OEM specific, since another OEM my decide differently which configuration capabilities to provide to the User.
Its all central, consistent, it focus on User (minimize distraction) and OEM (enable customization and scope definition).
But to be honest, settings configured by the central Settings App are not covering all App internals. There are settings changed dynamically during usage, e.g. Sat-View/Hybrid-View/Standard-View in a Map, routing parameter like fast/short/eco etc or even stored Favorites. This will be done App-internally, and typically spread over the App-UI to be at the place where it is needed (instead of collected and presented all together at a single place). These App internals are managed by the App itself. Also for this the prepared (preferences & setting) services can be used by the App-developer, and we provide prepared basic widgets, to keep the UI consistent and to customize it easily (and we should have some words about it in the document) but when I say we have to have a central App for the App settings, then I am talking about the "static" ones.
For that we use some basic data structures like "bool", "int", "string" etc and provide widgets as visual representation of it. Lets compare it with the iOS way. In addition, there could be a sequence needed to ease the input of values, e.g. a wizard (e.g. to configure an email account). This should be provided by the App-Developer. An isolated executable (Agent), using some PopUp-Sequence and finally set the key-value pairs shown in the settings App. With that, the Wizard gets shipped with the App, but launched by the Settings Apps.
Once we do have both mechanisms - the wizard together with the standard key/value types - , we have a great tradeoff between the 80% of easy to use Standard stuff and the 20% complex parts not fitting well into the standard patterns. And being well prepared to handle it in a central App, we can easily cover a look & feel where it behaves like bundled to each App (for example a dedicated "Settings Hard Key", which shall show only the Settings of the App (in Foreground at the point in time of key press), by initiating a flip Animation and showing the App-Settings at the Back-Side of the current App Screen. That said, from a solution for central handling we can derive a decentralized setup, but not as easy vice versa. So lets go for the one covering the wider scope.
However, even if we support the central solution, an App developer may decide not to use it. In this case, App settings - which still exists but not exposed centrally - are somehow internally handled, in an app-specific way. Its not consistent, etc, but its possible. And we shall support this too. Its like different levels of integration, similar like with the different level of prepared UI elements (from basic widgets via container to complete views/templates) - we recommend the deepest integration but if the App developer decides not to use it he can go for it but then he has to take the burden for build in functionality. So for "settings", we may expose a "settings key pressed" signal to the App for the case it does not participate on the central handling. Or the OEM customization in look&feel but also in scope. Or the "search settings" functionality. An App Developer can even decide not to use our low level services to handle key-value pairs and uses its own. In this case, he has to take care about under voltage etc,
With that in mind, I do have the feeling that the explanations on page 26, like - disadvantages - ways to embed UI from an application (A) into the system preferences app (B) are not perfectly fitting.
Could you please reflect the things said above - different kind of App settings (which ones are in-app handled, which ones are central) - going for the widest scope solution (central handling, incorporation of wizards) - flexibility in tailoring for a specific product (customization, de-centralized setup)
And also - reflect the iOS User Interface approach for presenting the App settings
Rgds Andre
-----Ursprüngliche Nachricht----- Von: Devel [mailto:devel-bounces@lists.apertis.org] Im Auftrag von Philip Withnall Gesendet: Freitag, 27. November 2015 13:05 An: devel@lists.apertis.org Betreff: [Devel] Preferences and Persistence design 0.3.0
Hi all,
Please find attached version 0.3.0 of the Preferences and Persistence design, plus a document showing the changes between version 0.2.3 and 0.3.0.
This version includes more background research, some alternative designs for the system preferences application (§5.1.5) and clarifications of recommendations for storing secrets and passwords.
Is this one OK to upload to the wiki?
Philip