1386831 - the "Pocket" menu entry in the library should expand to a list of recent entries

Status: NEW

(Firefox :: Pocket, enhancement, P5)

Description

[Alexandre Folle de Menezes]

I believe the "Pocket" menu entry should expand to a list of recent entries like the history menu.  This is how the pocket plugin works, and it is way more practical than opening a new tab every time.

Comment 1

[:Gijs (he/him)]

Bryan, did the Pocket team still want to look into this, and did you talk any more with them about it?

Comment 2

[bbell]

This is for sure the ideal. The Pocket list should reveal a short list of 15-20 of a users most recent saves. With a "Show all Pocket Save" link at the bottom that brings the user to the website.

Comment 3

[bbell]

Is there a handy Pocket API that would make this possible?

Comment 4

[Kuba Niewiarowski]

> Is there a handy Pocket API that would make this possible?

Based on AFAIK still functional (in corresponding Fx version) old Read it Later extension, guessing: yes, it is.

Comment 5

[Justin Rochell]

The Pocket API documentation is available here: http://getpocket.com/developer/

I think authentication might be tricky, but if we can use the same approach as we currently have with the Pocket integration, then I believe it'll be relatively simple to retrieve the most recent items from a user's list. 

Also, we'll want to make sure and whitelist the consumer key so it's treated as an official app and doesn't get rate limited after a large volume of requests.

Comment 6

[Nate Weiner]

Hey gang - Some thoughts here:

1) Getting a list of the most recent items from a user's list is very straight-forward through our API and the Firefox integration already has code in there that can make this request. (And no changes to the API key would need to happen)

You'd want to look here:
https://github.com/mozilla-partners/pocket/blob/master/content/pktApi.jsm#L228

Essentially that would just be:
>pktApi.apiRequest({
>  path: '/get', 
>  count:10, // how many recent items get
>  success:function(data, xhr){
>     // data.list = the list of items
>     // do something here to display the items
>  },
>  error:function(errorThrown, xhr){
>    // do something here on error
>  }
> });

Here are docs on that /get endpoint and what format the items come in:
https://getpocket.com/developer/docs/v3/retrieve


2) While getting the items is straight-forward, the experience around this is more complex and important to get right. The tricky part here to get right is making sure this list is up-to-date and in sync at all times. (This is a core principle of our product, the user should never see an out-of-sync state).

A user's list can change in many ways:
- A user saves an item in Firefox. Goes to the list. That list needs to show that most recent save.
- A user opens their list and archives an item. The user opens that native list, that archived item cannot be there.
- A user saves an item on their Android phone. They click open the list in Firefox. That new item needs to be there.

So for example the following implementations won't work:
- Polling on some interval. If a user changes their list in between intervals, they may see an out-of-date list.
- Refreshing the list when a user saves locally. This won't work on it's own because they can make a change outside of Firefox.

The way we handle this within Pocket to-date is:
- All of the clients support Push. If a user makes a change anywhere on the platform, pushes go out to all of their devices to trigger them to update.
- When the list is opened the list immediately syncs

So given that, a few implementations that I think would be acceptable would be:

1) When a user opens the native Pocket menu, we show a loading state and fetch the list synchronously at that moment. This guarantees in all cases that they only ever see an accurate view of their list. But comes at the cost of requiring a little bit of loading time. This is also the simplest solution as we already have the plumbing in place to hit the list API (noted above).

2) We implement Pocket's list syncing engine and connect it to Firefox's push APIs. (I spoke briefly with some folks on the Sync team and they indicated there was support for push that we could leverage). This would allow us to keep a local up-to-date list in the browser which would have the benefits of: A) Instantly showing the list when opened and B) Allow us to keep the Pocket icon state up-to-date. (ie if you visit a page you have already saved, it would be coral instead of gray).

3) We up-date the list whenever the user saves in Firefox and on some interval and instantly show whatever state we have when they open the list, but immediately trigger a clear loading state (ie "Looking to for updates") and then refresh the local list when completed. (This is my least favorite option as it feels kind of janky).

Comment 7

[:Gijs (he/him)]

Nate, I don't think the core photon structure team is likely to have time to implement this before 57 ships. We can mentor people to work on this to help with the integration into Firefox here, but I suspect that the intricacies of the APIs and syncing on your side are much better dealt with by people more familiar with that side of things. Generating a bunch of DOM nodes (which is all the Firefox bit needs to do) is, in my mind at least, ultimately unlikely to be the harder part here, given your comment. Are there folks who know the Pocket APIs who have time to take this on in that timeframe? Mike, Drew and I (and the rest of the Fx frontend folks, I'm sure) would be happy to help with any teething issues in terms of getting a Firefox build env set up and so on.

Comment 8

[Nate Weiner]

:thumbsup: Got'cha, thanks - I think I was unclear on if this request was coming up because someone wanted it/had time to do it or if it was just an idea. Agree it sounds like it'd be better for someone on our end to hook up.

I can connect with Hugo next week when he's back from on-boarding to see if we think someone on our end could pick this up in time. 

The questions I would have are:
1) When would this code have to be complete in order to land for 57?
2) Is there anyone on the Firefox side that we should have weigh in on the UX (for example the 3 options I laid out above)?

Thanks!

Comment 9

[:Gijs (he/him)]

(In reply to Nate Weiner from comment #8)
> The questions I would have are:
> 1) When would this code have to be complete in order to land for 57?

Based on https://groups.google.com/forum/?fromgroups=&hl=en#!topic/firefox-dev/Y4p2gjYSFuI , I believe in an ideal world, Tuesday 22/8. I don't know how easy it is to do the push hookup stuff, so if we decide to go that way, to me it seems like it would be reasonable for it to not be fully finished before some of the later milestones listed there, but I don't really have great insights into which one would be more or less appropriate. September 19 is go/nogo, so that would be the very latest. I expect localizable strings would normally need to be in at least a week before that, though I dunno if that's different in the pocket case because it's a system add-on. The earlier the better, really, given stability and so on. I believe Jean Gong and Jeff Griffiths might be good people to talk to about this.

> 2) Is there anyone on the Firefox side that we should have weigh in on the
> UX (for example the 3 options I laid out above)?

Bryan Bell is probably best UX-wise. From an implementation perspective:

(In reply to Nate Weiner from comment #6)
> 1) When a user opens the native Pocket menu, we show a loading state and
> fetch the list synchronously at that moment. This guarantees in all cases

Just so we're on the same page, I hope you don't actually mean blocking the UI thread synchronously here. :-)

> that they only ever see an accurate view of their list. But comes at the
> cost of requiring a little bit of loading time. This is also the simplest
> solution as we already have the plumbing in place to hit the list API (noted
> above).

Right. So, the panelmultiview (basically, the sliding panels implementation) provides a "blocker" API that lets you pass it a promise, so that it'll wait with showing the next view until the promise resolves. We already use this internally for views created by add-ons. We could use that to avoid displaying the loading state, but obviously if the network is slow it wouldn't be OK for the click on the "View pocket list" item to then cause a delay of 5 seconds every time. We might be able to use something like:

// start loading data, select 'loading' state in the subview first, then:
let blockerPromise = Promise.race([new Promise(r => setTimeout(r, 300)), actualPromiseForWhenWeHaveData]);

which would mean we would slide in the subview when we have the data, or after 300ms (in which case the 'loading' state would be visible), whichever comes first.

I definitely think this is the simplest implementation and the easiest to make happen for 57. We can of course always refine it afterwards.

> 2) We implement Pocket's list syncing engine and connect it to Firefox's
> push APIs. (I spoke briefly with some folks on the Sync team and they
> indicated there was support for push that we could leverage). This would
> allow us to keep a local up-to-date list in the browser which would have the
> benefits of: A) Instantly showing the list when opened and B) Allow us to
> keep the Pocket icon state up-to-date. (ie if you visit a page you have
> already saved, it would be coral instead of gray).

Yeah, this would be better, but potentially harder. Kit Cambridge, Mark Hammond and the other folks who know about sync would have a better idea than me as to how difficult this would be to implement and whether doing it for 57 is realistic or not.

> 3) We up-date the list whenever the user saves in Firefox and on some
> interval and instantly show whatever state we have when they open the list,
> but immediately trigger a clear loading state (ie "Looking to for updates")
> and then refresh the local list when completed. (This is my least favorite
> option as it feels kind of janky).

Yep, this would be my least-favourite option too, also because changing the list from under the user is prone to leading to people clicking the "wrong" thing, and just generally looking suboptimal.

Bryan, do you have further thoughts from a more UX-y perspective?

Comment 10

[bbell]

It's certainly not something we can resolve before 57, and it deserves a couple rounds of iterative design with Pocket. So let's table this for now, and return to it for 58.

Comment 11

[Alexandre Folle de Menezes]

Please note that the Pocket plugin stops working with 57, so there will be no way to see the list on the toolbar.

Comment 12

[Hugo Romano]

Alexandre, could you please elaborate on your comment? 


How will the plugin stop working exactly? Wouldn't users still be able to access their list from the Library in the toolbar?

Comment 13

[Hugo Romano]

(In reply to Hugo Romano from comment #12)
> Alexandre, could you please elaborate on your comment? 
> 
> 
> How will the plugin stop working exactly? Wouldn't users still be able to
> access their list from the Library in the toolbar?

Actually just realized you are talking about the old Pocket Extension. Sounds good thanks!

Comment 14

[Alexandre Folle de Menezes]

Yep, sorry for calling it wrong.  I am still using the old extension because it is the only way to get the list of saved bookmarks (and search) directly from the toolbar.  The current built-in button opens a new page with screenshots, as does the item in the new library button.  This issue is about replicating the classic functionality in the library button (or maybe a dedicated extra button as the bookmarks button is now).

Comment 15

[Alexandre Folle de Menezes]

Found an extension that does almost everything the old one did:
https://bitbucket.org/pabuisson/in-my-pocket

The layout is different though.