1205824 - Support import of bookmark structure from Samsung S4

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Barbara Bermes [:barbara] - NI please!]

I noticed that when importing bookmarks from another browser into Fennec, it does not preserve the folder structure from the source browser.

Can we please figure out if it's possible to retrieve the bookmark tree from the source browser and replicate that in Fennec.

Comment 1

[Chenxia Liu [:liuche]]

We could do this because folder data should be stored by the browser database.

The current code supports pre-Honeycomb bookmarks (with content://browser/bookmarks).
We'd have to change the following:
1. Add support for "content://com.android.browser/bookmarks", which is the post-Honeycomb, and add code to handle folders
2. Do something different for the S4, which has a different database content provider, and would handle folders differently
3. Do something different for other Samsung devices (possibly S4+) although this might be the same as 1.

as well as continue supporting the existing import code, so we'd probably need to have 2 or 3 code paths for importing, depending on the manufacturer and probably the specific device.

https://code.google.com/p/android/issues/detail?id=15635#c4

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

How reliable is this? Can we guarantee that this would work?

Just trying to gauge how to reflect this in the UX.

Comment 3

[Chenxia Liu [:liuche]]

I haven't looked at any schema, but I'd guess that if we were to do this, we'd just copy the hierarchy into our own folder structure. iirc, we already kind of do this when we sync from a desktop profile that has folders.

I think assuming we can do this at all *and* that we don't guess wrong (which we might), this should be pretty "reliable". e.g., if we know how the other browser does parent-folder/child-file/child-folder, we'd probably be able to reproduce the hierarchy.

However, before we start digging into the details, I think we should talk about whether we should do this at all.

Basically, I'm against adding support for creating/managing bookmark folders in Fennec. That's what the awesomebar is for - so that you can just start typing, and Fennec will find the best result (history, bookmark, search suggestion) for you. If you want more control, you can tag things with keywords. Folder management sounds awful on a mobile device (deleting folders with children, *moving folders*, creating folders, renaming folders) - all that creates more UI and complexity, and then we have support all of that.

My question would be (assuming we don't want to add bookmark folder management) how worthwhile is adding bookmark folder importing? Will this lead to users feeling dissatisfied with our lack of bookmark folder creation/management UI? We'll have to support that UI long-term if we add it.

Comment 4

[Richard Newman [:rnewman]]

On the other hand: organizing bookmarks is one of the most frequent and ardent pieces of feedback we get from users. Some people like to search, some people like to tag, and some people use folders. One size does not fit all.

See the activity in Bug 972193 and friends.

Thus far we haven't implemented that, but the general consensus I've picked up is that we want to… eventually.

In this particular case, my feeling is that if we're importing structured data, and we can get the structure, we should preserve it.

We do already support folders for desktop bookmarks, so this would not be a huge stretch. The question in my mind is whether to put those imported bookmarks inside Mobile Bookmarks, or into a new root.

Two things to consider when thinking about the last two paragraphs:

* Where does desktop put your Chrome bookmarks when it imports them?
* What will Sync do if we don't import the structure for synced Chrome bookmarks? My sneaking suspicion is that it will really fuck things up.

To me that means "do what desktop does" -- put it in the same place, and under the same root, with folders.

Comment 5

[Barbara Bermes [:barbara] - NI please!]

How long lasting are bookmarks on mobile if we enable the connected reading list with pocket at some point? People might start using this rather than bookmarks. We don't know that yet.

The original idea/request for this bug came out of the finding of unstructured data we'd have after enticing users to switch browser and bring their structured bookmarks with them. 
I still don't think that's what the user would expect and we would leave them frustrated.

As mfinkle suggested in C68 (https://bugzilla.mozilla.org/show_bug.cgi?id=1199859#c68), it's not part of the onboarding scope but I think it might negatively influence the A/B test.

So, I think we all agree that we need look into this for sure but the question is when.

Comment 6

[Richard Newman [:rnewman]]

(In reply to Barbara Bermes [:barbara] from comment #5)
> How long lasting are bookmarks on mobile if we enable the connected reading
> list with pocket at some point? People might start using this rather than
> bookmarks. We don't know that yet.

On a bit of a tangent:

I'd be surprised if there was much overlap, to be honest. From my hazy recollection of user research, ad hoc read-it-later tends towards print/email self/screenshot/leave tab open/…, with bookmarks appearing somewhere on that list but not high.

It's quite possible that bookmark-read-later users will continue to do that: lots of the task continuity patterns indicate lack of trust, not absence of a feature.

From a few years of interacting with users who've had their bookmarks trashed by Sync, there seems to be a very strong curation and reference component. Half our users pile crap on their desks and rely on search; the other half put things on the shelf to refer to later. Bookmarks are their shelves. Some of those users have up to fifty thousand bookmarks, carefully arranged in folders over years. Others have a 'control center' in their bookmarks toolbar, arranged to match muscle memory.


> I still don't think that's what the user would expect and we would leave
> them frustrated.

I agree. If you have a tree of bookmarks for whatever purpose, flattening it on import leaves you with a mess that you need to clean up, and is hardly a source of user delight :)

The 'cupcake theory' says that if we import bookmarks at all, then we should do it right.

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Richard Newman [:rnewman] from comment #6)

> The 'cupcake theory' says that if we import bookmarks at all, then we should
> do it right.

I don't think "cupcake" means what you think it means.

Comment 8

[Richard Newman [:rnewman]]

Importing your bookmarks flattened, if you're a user who uses folders, is a giant mouthful of dry cake mix.

Comment 9

[Barbara Bermes [:barbara] - NI please!]

Alright friends, after today's funnel meeting, we've agreed that we should ship this as part of the First Run on- boarding experience, as rnewman mentioned this should be faster than getting the string changes to inform the user that we don't support folder structure yet. 

Chenxia, if you need help with the list of stock browser we should make this work with, please let me know.
But most Samsung series probably will have to work.

(in order)
Samsung Galaxy S3
Samsung Galaxy S2
Google Nexus 7
Samsung Galaxy S5
Samsung Galaxy Tab 2.0
etc.

So I'll flag this as a blocker for https://bugzilla.mozilla.org/show_bug.cgi?id=1199859 and hopefully we can uplift this to 43 (main bug remains tracking 43 at this point).

Thanks

Comment 10

[Richard Newman [:rnewman]]

Morphing this bug: as we touched on yesterday, the old CP we import from doesn't expose structure, so we need to do what Chenxia suggests in comment 1.

Comment 11

[Chenxia Liu [:liuche]]

FYI, I'll be taking care of bug 1185002 first because it's needed to signal progress through the first run.

Anthony, let me know what the UI for bookmark structure should be, e.g., under some kind of Imported Bookmarks folder, or at the top level.

One thing that I'd still like addressed is, if our goal is to get long-term retention, what is the value of supporting structured bookmark importing without bookmark management in-product for new bookmarks? Supporting one without the other makes the product inconsistent because we imply that we provide support for bookmark structure in first run, when we don't; I really, really doubt that this situation will actually retain power users who are heavy bookmark users.

Comment 12

[Barbara Bermes [:barbara] - NI please!]

Chenxia, good point and I think we should look next to adding this: https://mozilla.aha.io/features/FENN-223 and this https://bugzilla.mozilla.org/show_bug.cgi?id=972193

Comment 13

[Chenxia Liu [:liuche]]

Hey Barbara, I'll be working from Boston for the next two weeks, and I won't have access to many devices, so the work I do for this will be specifically for the two types of databases used by the Samsung S4 (which are the two schemas that we currently support in code), for Chrome and the Stock browser. (This will probably work for most of the relevant devices.)

I'll upload builds and someone can test these on other devices, and we can file follow-ups for them if the import functions don't work on certain devices.

Morphing this bug to reflect that, and need-info-ing you.

Comment 14

[Barbara Bermes [:barbara] - NI please!]

thanks for the heads-up, any patch you got, I can test with some of the devices here.

Comment 15

[Chenxia Liu [:liuche]]

Barbara, have you been able to import bookmarks with structure between the S4 stock browser and Chrome? I've tried a bunch of things on a few devices and I haven't been able to get any folder metadata - I don't think this is actually possible because despite what BrowserContract seems to support [1], I'm not able to see any folders accessible through the content provider. Iterating through all the columns does not return any "folder" columns, and trying a few different content provider uris didn't get me anywhere.

This thread [2] (albeit from 2013) also seems to indicate that people haven't been able to import from the stock browser (or Chrome, in more recent versions).

I tried importing on both a N5 and an S4 running Kitkat, and wasn't able to import any folder structure at all. Chrome seems to auto-import from Samusung, but it doesn't include any folder structure (and in fact their help pages suggest that you export your bookmarks or just log into your Google account).

Let me know what you think, otherwise I think this might be a WONTFIX.

[1] http://androidxref.com/4.4.4_r1/xref/frameworks/base/core/java/android/provider/BrowserContract.java#351
[2] https://code.google.com/p/chromium/issues/detail?id=138755

Comment 16

[Barbara Bermes [:barbara] - NI please!]

Thanks for doing this research, Chenxia.

I believe none of the competitors have an "import from other browser" as a feature, and maybe now I know why?!?!

I'd like to discuss this further in our first run meeting tomorrow next steps etc.

Comment 17

[Mark Finkle (:mfinkle) (use needinfo?)]

Let's look for ways to determine if a flat import is good enough for people.

Comment 18

[:Margaret Leibovic]

(In reply to Mark Finkle (:mfinkle) from comment #17)
> Let's look for ways to determine if a flat import is good enough for people.

I agree. It seems like we just might not be able to do much here.

A somewhat awful workaround could be for users to import their bookmarks from another desktop browser to Firefox, then sync them with mobile. And as it is, we don't really do a good job supporting bookmark folders on Fennec, so we might be setting these users up for disappointment anyway if they can't continue to manage their bookmark folders after importing.

Comment 19

[Chenxia Liu [:liuche]]

Chrome does what Margaret suggested, which is to export their bookmarks to an html file, import that into Chrome and then sync.

Since this isn't possible I'm going to WONTFIX it.