webapps team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

Hi all!
  besides sending this message to Calum (our UI designer), I'm sending
it to the public mailing list in the hope to gather more feedback (and
have more eyes spot any inconsistencies or problems which might arise).


As announced at UDS, our main goals for 13.04 are:

1) Give the user more fine-grained control over which applications are
   allowed to use a given account;

2) Pass-through authentication: allow applications to authenticate with
   their own OAuth application key and define their own usage scopes
   (as opposed to the current implementation, where we have an Ubuntu
   "umbrella" application which acts on behalf of all applications).


Both of these features lead to some UI design questions. Here follows my
view on them, but please keep in mind that I might be missing some,
and/or you might have better ideas on how to implement them; so, you are
very welcome to share them. :-)


=== 1) FINE-GRAINED CONTROL ON APPLICATIONS ===

Add enable/disable switches next to each application. Another option is
to group applications by functionality and put the switch on the group
(for example, have an "e-mail" group with the enable/disable switch, and
list both Evolution and Thunderbird under the group -- with no switch
next to each of them).
This decision (whether granularity is per application or per service
type) does have a decisive impact on how the services are defined, so
it's important to have it settled as soon as possible.


=== 2) PASS-THROUGH AUTHENTICATION ===

The problem with having third party applications use their own
application key is that generally the user will have to authorize each
of them, at least the first time that they are taken into use. We have
the feature already mostly implemented at the framework level, but
UI-wise the experience is non optimal; here's an example of what would
happen when creating a Google account:

a) The OAuth web window opens, the user enters his username and password
b) The web page asks to authorize Ubuntu
c) The account is created, the user is taken back to the Online Accounts
panel (with the newly-created account selected)
d) Empathy and Evolution (and add here any Unity lenses or other
background processes) see that the a new account has been created and
start using it
e) The account is marked as "need authentication", and the "Grant
access..." bar appears on top of it
f) The user clicks on the "Grant access" button
g) The web page opens, and the user is asked to authorize Empathy
h) The user authorizes Empathy
i) The web page re-opens (or stays open, but with changed contents), and
the user is asked to authorize Evolution
j) The user authorizes Evolution
...the above will repeat for any background application...
z) The account finally turns to normal state

I imagine that users would be puzzled by all these authorization
requests, especially because they come out of the blue; when seeing the
"need authorization" bar the user will probably think that the account
creation somehow failed, or that our application is buggy.

Unfortunately there is nothing we can do about avoiding the multiple
authorizations: they come from the web service OAuth pages, and they
need to be done, sooner or later. All we can do is try to make they
happen one after another, in sequence, at a time that is most
comfortable to the user -- and that they not happen as a surprise.
That is, the account plugin could request the authorizations on behalf
of the applications, before completing the account creation; so that
when the account creation is completed, the applications don't need to
be authorized again.

Then the question is: should the account plugin attempt to authorize all
applications, or wait till the user has chosen which applications it
intends to enable (feature #1) and then just authorize the enabled
applications?
In the latter case, what should happen when the user, later on, will
want to enable an application which was previously disabled (or a couple
of applications)?

In order to group the sequence of authorizations, we might need a
confirmation button, in the page with the enabling/disabling of
applications: because if the enabling/disabling is applied instantly,
then we have no way to group the authorizations.

The other option is to perform the authorization immediately after
enabling an application: so, as the user toggles the enable switch on an
application, the OAuth authorization web page might appear right away,
just for that application.
This would probably require some explanation on the "Enable" switch
(something like "you might be asked to authorize this application to use
the account") and definitely would require that all applications are
initially disabled when the account is created (otherwise we are back to
the original problem, when the "Grant access" button appears as soon as
the account is created, because the applications have not been
authorized yet).


That's all from me. I'm looking forward for other points of view! :-)

Ciao,
  Alberto