Unlike the phone (unity8) interface, in the desktop (unity7) when a Google account is created in "System Settings" -> "Online Accounts", all applications which can use it get automatically enabled.
Some of these applications, such as Shotwell, have their own UI and use the account only when the user is actively using them, while others (such as Empathy and Evolution) provide background services which start synchronizing the user calendar or contacts as soon as the account is created, but without showing any UI on screen.
Now, the problem is that the first time that these processes start using the newly created account, they need to be authorized by the user: this is not something that we can control, as it's a requirement from the remote server (Google's, in this example). This means that until we show a UI containing the Google's authorization page, these application won't work. The solution we implemented (and that we are currently using) is that when these applications try to authenticate, we refuse their request and instead emit an OSD notification, saying
Applications can no longer access your Google Online Account
Choose <b>Online Accounts</b> from the user
menu to reinstate access to this account.
If the user is clever enough, he'll open "System Settings" -> "Online Accounts" and after clicking on the Google account they'll be prompted to authorize the applications that previously requested access to it. Until the user has done that, these applications won't be able to interact with the account.
Some users (actually, Canonical developers) have been left confused by this message, thinking that it was the symptom of an error that had to be fixed.
I would like to propose a couple of simple suggestions to fix this bug:
1) Reword the notification message a bit, maybe by saying "Some applications cannot access..." (note that I removed "no longer")
2) Some releases ago, the system settings indicator on the top right corner of the screen would become red in this situation, and also the "Online Accounts" menu item inside that menu would appear in red: that helped a lot our users in finding their way. However, this no longer happens.
"the first time that these processes start using the newly created account, they need to be authorized by the user: this is not something that we can control, as it's a requirement from the remote server"
Is this true on the phone as well? If not, how does the phone avoid this? And if so, the phone Online Accounts design needs changing too.
"Choose <b>Online Accounts</b> from the user menu to reinstate access to this account"
Consider the huge variety of ways people can fail at this task. They might:
* Not see the notification bubble before it disappears.
* Not see anything that looks like a "user menu", since there is no such thing. The user menu hasn't existed since Ubuntu 12.04. (And even then, it wasn't referred to by name anywhere except Ubuntu's help pages.)
* Choose the wrong menu item inside the menu by mistake.
* Get bored and switch to some other app before System Settings opens.
* Close or minimize System Settings by mistake.
* Navigate to a different System Settings panel by mistake.
* Fail to find the account in the list, especially if they have many accounts.
* Choose the wrong account by accident, especially if they have more than one account of the same type.
And so on.
The general design guideline: Don't tell me how to do something if it won't make me faster later. Instead, Just Do It, or else give me a button to do it.
In this case we can't Just Do It. So, we should provide a button to do it. What should that button look like? We're allowing the service to access a particular account, so let's label the button "Allow". To make the alternative obvious, we should have another button for that, "Don't Allow". And of course we should identify the service and the account it wants to access, so let's use text for that, above the two buttons.
By now this should be sounding very familiar ... It's the standard Online Accounts dialog! The only difference here is that we have to show the Web UI afterwards, so "Allow" should be "Allow…". That's all.
Now, I guess you're going to tell me that reimplementing that in Unity 7 would be far too invasive. If so, let me know how much you're comfortable implementing, and we'll see how close we can get.