OnlineAccounts

Differences between revisions 1 and 18 (spanning 17 versions)
Revision 1 as of 2012-07-20 10:55:25
Size: 18
Editor: alobbs
Comment:
Revision 18 as of 2013-12-12 14:08:16
Size: 6664
Editor: mpt
Comment: fixes formatting
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Placeholder page <<TableOfContents()>>

== 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 ===

<<Anchor(phone-settings)>>
=== Settings ===

The contents of the [[SystemSettings#Phone|System Settings]] “Online Accounts” panel should differ depending on whether you currently have any accounts set up.

||<^ tablestyle="float:left;margin:0 1em 1em 0" style="border:none">{{attachment:phone-accounts-top-none.png}}||<^ style="border:none">{{attachment:phone-accounts-top-none.mockup.jpg}}<<BR>>''Erratum: “let apps” should be “lets apps”.''||

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.)

||<tablestyle="clear:both" style="border:none">||

||<^ tablestyle="float:left;margin:0 1em 1em 0" style="border:none">{{attachment:phone-accounts-top-some.png}}||<^ style="border:none">{{attachment:phone-accounts-add.png}}||

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.

||<tablestyle="clear:both" style="border:none">||

||<^ tablestyle="float:left;margin:0 1em 1em 0" style="border:none">{{attachment:phone-accounts-add-facebook.png}}||<^ style="border:none">{{attachment:phone-accounts-add-facebook.mockup.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).

||<tablestyle="clear:both" style="border:none">||

||<^ tablestyle="float:left;margin:0 1em 1em 0" style="border:none;width:310px">{{attachment:phone-accounts-account.png}}<<BR>>''Erratum: “Remove Account…” should be “Remove This Account…”.''||<^ style="border:none;width:310px">{{attachment:phone-accounts-account.mockup.png}}<<BR>>''Erratum: “Remove this account” should be “Remove This Account…”.''||

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 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.

||<tablestyle="clear:both" style="border:none">||

<<Anchor(phone-access)>>
=== App access ===

For App access, see the Online Accounts spec: https://docs.google.com/a/canonical.com/document/d/1UwAQTXgEyZSD3di6fAUS0W18rKxh8TXb1TwsmkgbGG0/edit#heading=h.2s0rnc8nwg9k

=== Open questions ===

 * 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.

=== 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.

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.

phone-accounts-top-none.png

phone-accounts-top-none.mockup.jpg
Erratum: “let apps” should be “lets apps”.

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.)

phone-accounts-top-some.png

phone-accounts-add.png

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.

phone-accounts-add-facebook.png

phone-accounts-add-facebook.mockup.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
Erratum: “Remove Account…” should be “Remove This Account…”.

phone-accounts-account.mockup.png
Erratum: “Remove this account” should be “Remove This Account…”.

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 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.

App access

For App access, see the Online Accounts spec: https://docs.google.com/a/canonical.com/document/d/1UwAQTXgEyZSD3di6fAUS0W18rKxh8TXb1TwsmkgbGG0/edit#heading=h.2s0rnc8nwg9k

Open questions

  • 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. Smile :-)

        • 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.

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)