Improve widget for multi-backend usage

[raucao]

Currently the widget is not very usable when enabling Dropbox and/or Google Drive.

[raucao]

Just found this on my hard drive, taken from a Web app I don't remember:

I think this makes a lot of sense. In the app you should just direct the user to "sync" or "store" something in general, and then the dialog can tell you the options. No need to show logos in a corner all the time.

[raucao]

FYI: 5apps is sponsoring work on the widget. I already created a pull request here: opensourcedesign/jobs#16

[michielbdejong]

Yes, good point! Especially if we add more and more logos (Hoodie can already be added, and maybe ownCloud in the future). The first click can then just by an icon that means 'sync', and could use generic offline-first sync icons

[raucao]

Hoodie can already be added

There's a remoteStorage interface to Hoodie now?!

The first click can then just by an icon that means 'sync', and could use generic offline-first sync icons

Yes, or whatever fits best in the app, based on the use case. It may want to ask you directly, it may want to have a button in the settings, it might want to always show the icon somewhere (hard especially on mobile e.g.), etc.

[michielbdejong]

No, but Hoodie is a cross-origin protocol. So the widget could say 'GoogleDrive, Dropbox, your remoteStorage, your Hoodie, local filesystem, zipfile-download, etc'

if apps have their own 'connect' icon then they also need their own 'busy syncing' icon

[raucao]

No, but Hoodie is a cross-origin protocol. So the widget could say 'GoogleDrive, Dropbox, your remoteStorage, your Hoodie, local filesystem, zipfile-download, etc'

I don't believe that makes a lot of sense. It would mean the widget includes code for other libraries that aren't included in rs.js, and including 2 different sync libraries. You'd have to hot-load and cache the sync library code then, if you don't want your dependencies to both grow considerably in size as well as potentially conflict with each other.

Anyway, that's a topic for another day I guess. I agree that the design should support potential new options from the start, although I personally would rather see options disappear and end up with only remoteStorage in the end, of course. :)

[raucao]

if apps have their own 'connect' icon then they also need their own 'busy syncing' icon

Remember, this is optional! You should always be able to just throw the widget in there I think. No?

But yes, the goal should be to separate the whole widget from the core library asap, and make it entirely optional, so that app developers can implement their own UI for everything, and the widget is just a consumer of events, same as an app with custom sync UI is.

[michielbdejong]

I agree we should split the widget from the rest, even if it's just in the interest of code maintainability, and maybe also remotestorage.js is not the right name for a user data sync client that supports ever more backends.

We should remember what the initial thoughts were in creating both the widget and the logo: the user should have a standard way to connect their remoteStorage, which the end-user recognizes. That same line of thought can apply to a multi-backend widget.

But now, since it will be a multi-backend widget, it would be a generic "sync widget", not a specific "remoteStorage widget", so it could even make sense to move it out of the remotestorage org - maybe move it into the offlinefirst org? or to its own org? I think such things influence how we think about where we want the web app platform to go, and it's a useful evolution.

Btw, I hope one day this widget will become a device-level thing. I will try to help Firefox OS and other platforms to one day have a very similar "connect your storage" dialog from the device settings, and/or from the device first-use wizard. So then apps don't need to display the widget (the device will take care of everything). The widget is then for platforms where such device-level sync is unavailable.

[michielbdejong]

Or to the 5apps org actually - if 5apps are sponsoring its redesign, and it is a generic sync widget for client-side apps (not specific to remoteStorage), then that might also make sense. The only repos that should really stay in this org are spec, remotestorage.io, design, modules, and maybe starter-kit.