OnlineAccounts

Differences between revisions 3 and 4
Revision 3 as of 2013-04-12 10:08:51
Size: 3085
Editor: ip-201-159
Comment: Technical considerations
Revision 4 as of 2013-05-31 11:36:47
Size: 3787
Editor: a88-114-100-24
Comment: Added questions
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:
=== Open questions ===
 * https://lists.launchpad.net/ubuntu-phone/msg01674.html
 * Design needed for flows where the user needs to invoke the account setup/configuration from an application. Examples:
   1. A facebook application started when no facebook account exists
   1. A facebook application started when a facebook account exists but is disabled
   1. E-mail application started when none of the existing accounts provide the e-mail service
   1. E-mail application started when there is an account supporting e-mail, but it's disabled
   1. E-mail application started when there is an enabled account supporting e-mail, but the e-mail service within that account is disabled

   

Phone

Initial setup

Settings

phone-accounts-top-none.png

phone-accounts-top-some.png

phone-accounts-add.png

The contents of the System Settings “Online Accounts” panel should differ depending on whether you currently have any accounts set up. If you have none, the list of accounts should have “No accounts” placeholder text, and “Add account:” should be a section listing the account types. (This saves going to a separate screen for your most likely action.) If you have at least one account set up, each should be listed with its ID, and “Add Account…” should be a button navigating to a separate “Add Account” screen. Why should it be a button?

phone-accounts-add-facebook.png

Either way, choosing to add an account of a particular type should navigate to a screen with that account type as its heading. Between “Authorize your account:” and the “Cancel” button should be a Web frame showing the relevant page. Completing the authorization should automatically navigate back to the top level “Accounts” screen, and temporarily highlight the newly-added account in the list (scrolling to it first, if necessary).

phone-accounts-account.png

Choose from the list of already-set-up accounts should navigate to a screen showing the ID for the account, and a list of all the installed apps that have ever requested “Access to this account:”, with a switch reflecting whether each app is currently allowed access. Finally, a “Remove Account…” button should open an alert with the text: “The {name of service} account will be removed only from your phone. You can add it again later.”, and “Remove” and “Cancel” buttons.

Open questions

  • https://lists.launchpad.net/ubuntu-phone/msg01674.html

  • Design needed for flows where the user needs to invoke the account setup/configuration from an application. Examples:
    1. A facebook application started when no facebook account exists
    2. A facebook application started when a facebook account exists but is disabled
    3. E-mail application started when none of the existing accounts provide the e-mail service
    4. E-mail application started when there is an account supporting e-mail, but it's disabled
    5. E-mail application started when there is an enabled account supporting e-mail, but the e-mail service within that account is disabled

Technical considerations and requirements

On the desktop, a similar design is implemented. There, the web view for the authentication is hosted by a different process (signon-ui) than the system settings applet, which is embedding it using the XEMBED protocol. This is made for security reasons and to simplify the handling of security-sensitive data, which always happens in the same process (signon-ui); this in turn leads to the possibility (should we want to use it) of decorating the windows presented by signon-ui in a special way to inform the user that he's entering data into a trusted component, and applying the strictest security confinement possible to signon-ui. To keep a similar architecture on the phone we need the windowing system to support some kind of XEMBED-like protocol; a reasonable fallback would be supporting only setting the transiency of the signon-ui window to the client application -- this, however, might have some effect on the design.

OnlineAccounts (last edited 2016-03-21 16:10:51 by mpt)