| Thread Previous • Date Previous • Date Next • Thread Next |
W dniu 30.08.2014 o 22:00, Sam Bull pisze:
On mer, 2014-08-20 at 09:06 +0100, Matthew Paul Thomas wrote:Having account setup in Online Accounts, instead of inside an app, makes the app harder to use. People have to learn and understand that there's a separate place on the system listing a separate "online account" that an app may or may not have permission to access.What I'd like, is to be able to simply add an ownCloud account to sync contacts and calendars, much like the Google account already does. I've no interest in installing a dedicated ownCloud app. Note this has been available in GOA for atleast a couple of years now.
Here, too, I'm afraid this goes into the "why isn't $my_favourite_service included by default" problem. Adding it to the default set would mean we need to commit to maintaining it in there, supporting it etc. Doing this for all of the services available out there is not something we'll be able to do. And then it becomes locked down to framework versions. Your app depending on a certain framework version (of which the account plugin would have to be part of) could not progress as quickly as it could if you had control of it all.
I'd have no problem installing "ownCloud sync support" from the store to get it. As for whether it's integrated with the accounts system or not, the engineer in me obviously votes for that. But not all people are engineers and I agree with that, if there's only one app that would ever use the ownCloud account, having to go through the accounts system has some experience disadvantages. And then there are technical advantages to having it *in* the accounts system.
The accounts UI became a trusted prompt recently so the process of configuring an account is much smoother now, so I'm not sure that the user experience of having to go through it is so much worse these days than having it built into the app.
So it's worthwhile only if it saves a lot of time -- only if multiple apps use the same kind of account.I'd also like to add notes syncing to the notes app using ownCloud. I've already done this in my gnome-shell extension, by retrieving the credentials from GOA. I'd like to do the same on the phone, the code is Javascript, so I should be able to reuse it mostly unchanged.
I think we need a more generic system here, the notes app shouldn't have to know what ownCloud (or any other service, for that matter) is. It just needs to be a source for a destination (I'm thinking content hub, of course, I'm sure we can engineer something that will make sense and be agnostic to what kind of data is being sent through it, from and to where).
It occurs to me now that even contact/calendar syncing should maybe become part of the content hub experience, these days it's all just file exchange anyway.
=====Now, we've had a chat recently about what to do with multiple apps wanting to use the same account, one that isn't part of the default set of supported services. The simplest approach, albeit not too user friendly, is just saying in your app's description that it's a requirement to install a separate support package. It's not an unheard of approach. The app, if realized that the account type is not available, could even link to the store to point directly at the required package. Another approach I was thinking of is allowing multiple plugins of the same account type exist (so every app would ship their own copy) and deduplicating based on type and compatibility version. This has some technical difficulties like allowing multiple packages of potentially different compatibility versions to co-exist (you'd have two accounts of the same type in that case, again not a great user experience, but should be rare). We'd also need a place to share the account plugins, or at least their interfaces so that different implementations can talk the same language. This could potentially have security implications if not done right. The more I think of this way the more it feels like overengineering for a quite rare a problem.
HTH, -- Michał (Saviq) Sawicz <michal.sawicz@xxxxxxxxxxxxx> Canonical Services Ltd.
| Thread Previous • Date Previous • Date Next • Thread Next |
