I'd like to see us try option #3, which honestly should be the normal way we handle any service: Use it if it's working, or fallback to a safe mode when it's not.
On Wed, Mar 30, 2016 at 4:27 PM, Stefan Arentz <[email protected]> wrote: > (Long email, but please read, we need to make decisions to enable > Bidirectional Bookmark Sync in Firefox for iOS) > > > BACKGROUND > > We have landed bidirectional bookmark sync in Firefox for iOS. This lets > people sync their bookmarks both ways. Changes you make on your iOS device > will go to the cloud where other devices can pick it up. Changes pushed to > the cloud by other devices will appear on your iOS device. > > This feature is currently not fully enabled. Instead, we shipped 3.0 with > bidirectional bookmark sync running in read-only mode. We show all your > bookmarks that we took from the cloud but you cannot change them. This is > pretty much the same thing we have been shipping in previous releases. > Users will not notice any difference or anything new. > > The reason we decided to disable the bidirectional sync code is as follows: > > The iOS sync client is currently the most correct sync client we have. But > part of that is that the code expects the cloud to contain correctly formed > bookmark data. Simplified example: a bookmark must have a unique id and > must have a correct parent folder. And the parent folder must know about > the items in it. If there are inconsistencies in that structure then the > bookmarks we take from the cloud cannot be merged in the iOS database and > the bookmark code automatically falls back to a read-only mode. > > Inconsistent data happens because our other products that are part of the > sync eco-system are not perfect. Because of design decisions that go back > many years or simply due to bugs or incomplete implementations, our other > sync-enabled products, the server-side included, can cause your bookmark > data in the cloud to get in a bad state. As a user you don’t have to do > anything specifically bad. It just happens. > > When your bookmark data in the cloud is in a bad state, iOS gives up. > Other clients like Desktop and Android try to make the best of the > situation, but the results of that varies greatly. Sometimes you will not > see bookmarks that should be there. Or your folders get re-organized. Or > things get dumped in Unsorted. Sometimes things are merged in some way and > then synced back to the cloud which results in even more data loss in your > other devices. We have seen complaints and bugs about this behavior for > many years. > > Some early metrics show that it is very likely that at least 50% of our > (iOS) users will have this problem. If we look beyond iOS, the percentage > may be higher. These people thus cannot reliably use bidirectional bookmark > sync on iOS. > > > > THE GOOD > > A number of the underlying problems have been identified and as a result a > number of bugs have been filed to improve the situation on desktop, android > and the server-side to improve sync data quality. These fixes are not just > good for iOS, this is good for the complete sync ecosystem. This is not an > iOS specific problem. It happens everywhere, we have just ignored it for a > very long time since things seemed to work. Everyone will benefit from > this. The quality of sync services will improve in general, for all > products. Which is something we all want. > > On iOS we can detect if someone’s data is bad. And we use telemetry (on > our TestFlight builds) to collect this. So iOS is currently the canary. We > can look at our telemetry and we can monitor sync data quality. This means > that we have great insight and we can actually see if changes we make in > other places will result in the data quality improvements that we are > looking for. > > There is also a recovery mechanism. You can reset your synced data via > Desktop. (And maybe Android?) You can tell it to replace your data in the > cloud with the current copy you have in Desktop. This will fix things. > Sometimes permanently. Sometimes temporary until you hit behavior or bugs > that causes bad data again. Nevertheless, this is an escape hatch. > > > > THE BAD > > The problem is, and this is what this discussion is really about, it may > take a while before changes to the other participants in the sync ecosystem > are landed and in user’s hands. > > Things can be unpredictable. Even if your data is good now, it can get in > a bad state when you use Firefox on another device. > > > > SO … > > The core of this discussion is this: for iOS we don’t want to wait to roll > out this feature. We have our code ready and it is a highly requested > feature. So, what I want to discuss is some options on how we can enable > bidirectional bookmark sync on iOS. The options below are a discussion > starter. Lets talk about it and see what we can do. > > > > OPTIONS > > Keep the following in mind: > > * Bookmark Sync may work or not for an idividual user. > * After initially downloading your bookmark data on an iOS device we will > actually know if it is in a good shape or not. > * If the data is not in a good shape, your bookmarks will appear in > fallback, read-only, mode. > * Even if the initial download looks good, your data may get inconsistent > at some later stage at which point the bookmarks will become read-only. > > > Options that require little or no code: > > 1. Just enable it > > We know it will not work for everyone. But with the right messaging we can > tell people this is experimental or may not always work. We can also add > feedback in the application to explain to people why their bookmarks are > read-only. We can provide instructions (SUMO article) on how to re-upload > your sync data with Desktop. > > > 2. Let users enable it > > Building on option 1, we create an option in Settings to ‘Enable > experimental bookmark sync’. It defaults to off. People can decide if they > want to participate or not. We can message this as experimental or beta or > just explain what the result can be. We can provide instructions (SUMO > article) on how to re-upload your sync data with Desktop. > > > 3. We automatically enable it when we discover your data is in good shape > > After we do the initial bookmark sync, we actually know if your data is > bad or not. If it is good then we can enable bi-directional bookmark sync. > If it is bad then we fall back to read-only. However, since data can also > become corrupt at a later time, we still need to deal with that. But, we > can explain to the user why this happened. We can provide instructions > (SUMO article) on how to re-upload your sync data with Desktop. > > > 4. Need more options! > > > > TOPPINGS > > Things we can do on top of all the options above: > > 1. We can make the iOS client more lenient > > There are some cases where the iOS client can ignore certain cases of bad > data. It is not a solution, but this could make the success rate higher. > > > 2. We make the iOS client self-healing > > If we detect data inconsistencies we may be able to fix them, and then > give the user to re-upload their data back the server. Lots of complexity > here. > > > > What do you think? What is a good path forward. > > > Speaking for the iOS team, > > S. > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
