Ubuntu Wiki

Rationale

The purpose of Online Accounts in Ubuntu is to simplify the overall experience, by reducing your need to enter sign-in details for an online service in multiple apps.

This time saving comes at a cost: the mental complexity of dealing with a separate thing, “Online Accounts”. Therefore, Online Accounts should be involved only where it is reasonably likely to save time. So it should not be used to handle special-purpose accounts that are only ever used for one app; that would make the overall experience more complex for no gain.

Online Accounts also should not allow apps automatic access to every stored account. For example, you may want to use work e-mail entirely on the Web so that there are no stored messages on your computer. So you don’t want a mail app to access that account automatically.

Phone

Initial setup

Settings

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 all the account types that currently-installed apps and scopes can use. (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 the items for adding a new account should be demoted to a separate “Add account” screen.

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.

If there is a networking or HTTP error in loading the page, or in submitting the form, the contents of the Web frame should be replaced by the text “This service is not available right now. Try again later.” and a “Try Again” button (bug 1349975).

Completing the authorization successfully 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).

Choosing 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 and scopes that have ever requested “Access to this account:”, either directly or indirectly (for example via pay-ui) (bug 1544033). Each app or scope should have a switch reflecting whether it 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.

App access

An app should not know which kinds of Online Account you have. This is so the app can’t misbehave if it detects that you are registered with a competing service.

Therefore, an app should not try to do different things depending on whether you have an account of a particular type.

Instead, an app should just ask for access to an account of a particular type, and Online Accounts should do the appropriate thing depending on how many accounts you have registered of that type:

• If none, an authorization dialog with a Web frame for setting up an account with that service.
• If one, a permission dialog for allowing/denying the app access to that account, or (if allowed) registering a new account.
• If more than one, a permission dialog for choosing which one to allow access to, denying access, or registering a new account.

If the account type requires granting permission separately for each app, an equivalent dialog should appear for allowing/denying the app access to that account (or delaying the decision) (bug 1522360).

Apart from the extra text or menu for specifying/choosing the account, all the permission dialogs should follow the same layout as trust store permission prompts: app icon, app name ellipsized if necessary, app ID, text of the form “wants to access your {type} account” or “needs permission to access your {type} account”, and text or a radio menu with the account ID. And they should have the same behavior too: if a window of the associated app is focused, that window should be the dialog’s parent (so that you don’t accidentally cover the dialog with the app, then wonder why nothing is happening). If not, the dialog should be parentless (so that it may appear above other windows, if you aren’t interacting with any right now).

As with other permissions, an app should send you to “Online Accounts” only as a last resort, if you have previously denied it access to an account, so that you can manually change your decision.

When you allow an app access to an account, that access should persist to all future versions of the app.

Open questions

• Perhaps an app could ask for not just one account type, but multiple account types at once. (For example, a mail client.) Would this make the overall flow simpler?

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

  • “Click on the newly created account to see what it can be used for, and disable/enable the account services” not only can’t be mandatory, most of the time it would be a no-op. Most of the time you’ll set up an account at the suggestion of the first app that wants to use it. Later apps that use that account will rarely even be installed yet.

    • So, suppose that the first app suggesting me to create a google account is the sharing app, because I want to upload some pictures to Picasa; creating the Google account will cause logging into gtalk, synchronizing his gmail, calendar and what not, all without me even noticing it. It doesn't sound very nice to me.

      • I don’t know what “the sharing app” is. But unless that single app does everything — picture sharing and chatting and e-mail and calendar and whatnot — then no, that won’t happen. Ubuntu will ask you to give Google account access to the gallery app when it asks for access, to the chat app when it asks for access, to the mail app when it asks for access, and so on. And if any of those requests aren’t the direct result of you tapping a button in the app, you’re likely to decline.
• There is no way to disable an account. Is it intended?
  • How does “disable” differ from both revoking access to the account, and removing the account altogether?
    • It's exactly like disabling all of the account's services, except that it remembers which services were enabled and which weren't, in case you re-enable the account later. It's not a critical feature, but we have it on the desktop -- I'm just making sure that it wasn't forgotten by accident.