1124153 - [ReadingList] Make the list of items in the Reading List sidebar scale well

Status: RESOLVED INCOMPLETE

(Firefox Graveyard :: Reading List, defect, P2)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

We need a solution that solves the inevitable issues around scaling a large list of ReadingList items. Just generating DOM elements for hundreds of items isn't going to perform the best.

As an additional problem, as the list grows large it will become less useful. Having a list of 10 items is useful, having a list of 1000 items makes the scrollbar useless and you're not going to find the 743rd item very easily.


Options:
* Ignore problem, always display all items
* Display X items. When scrolling reaches end, auto-add X more items
* Only make it appear as if all items are displayed (out of view, we just have blank space - when we scroll, items are dynamically generated)
* "Show more" button at end, which adds X more items to the end of the list
* Paged display
* Only allow showing first X items

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Michael: Thoughts on the options here?

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

If possible, breaking things up by relative date might be an option here.  Yesterday, This Week, Last Week, etc.

Comment 3

[Michael Maslaney [:mmaslaney] ([e-mail])]

I like the idea of chunking/labeling the list based on time added.

Moreover, there's work that Philipp and I completed for the TabCenter concept that I find beneficial regarding the Reading List sidebar.

http://invis.io/GT22ZN6QW

On pages three and four you'll find interactions for tab scaling (thumbnail to favicon) and column scaling.

I believe we could adopt the thumbnail to favicon scaling for users who have more than 10+ items in their Reading List.

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Chunking by time added helps with finding by time, but doesn't really help with scaling - especially given the time scales would presumably be increasing the further back you go (today, yesterday, last week, last month, last year).

But we need a way to cope with the worst-case scenario here: Initial import. Potentially we could have a thousand items imported on day one.

(If we do want to do time-based chunking, we'll need a separate bug. And TBH, I'm not sure it fits into v1)

Comment 5

[Bryan Clark (DevTools PM) [:clarkbw]]

Blair just so I know, besides the first option, what would you consider to be the simpler option to implement in the v1 time frame. 

> (from comment #0)
> Options:
> * Ignore problem, always display all items
> * Display X items. When scrolling reaches end, auto-add X more items
> * Only make it appear as if all items are displayed (out of view, we just
> have blank space - when we scroll, items are dynamically generated)
> * "Show more" button at end, which adds X more items to the end of the list
> * Paged display
> * Only allow showing first X items

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Bryan Clark (Firefox PM) [:clarkbw] from comment #5)
> what would you consider to
> be the simpler option to implement in the v1 time frame. 

Only allow showing X items is the easiest, but also leads to a shitty experience, so I think we should avoid that if we can :)

In order or easiest to most difficult/regression-prone:
* "Show more" button at end, which adds X more items to the end of the list
* Display X items. When scrolling reaches end, auto-add X more items
* Paged display
* Only make it appear as if all items are displayed (out of view, we just have blank space - when we scroll, items are dynamically generated)

Comment 7

[Michael Maslaney [:mmaslaney] ([e-mail])]

For V1 let's move forward with the first option of adding a "Show more" button that will load the next (10) articles.

Comment 8

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Sorting out strings... Micheal, can you confirm?

Button label: "Show more"
Button tooltip: "Show 10 more items"

Comment 9

[Michael Maslaney [:mmaslaney] ([e-mail])]

+1

Comment 10

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Mass change of ReadingList bugs, moving to their own component. Filter bugspam on the following quote:

“Reading is to the mind what exercise is to the body.”
― Joseph Addison

Comment 11

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to Blair McBride [:Unfocused] (I don't read bugmail - needinfo? me!) from comment #8)
> Sorting out strings... Micheal, can you confirm?
> 
> Button label: "Show more"
> Button tooltip: "Show 10 more items"

I just panicked thinking this didn't make it but bug 1133673 does actually include these strings so we're good to go from that angle.

Comment 12

[Justin Dolske [:Dolske]]

P2 to investigate that this isn't a terrible terrible issue with a modest number of items. Assuming so, it's actually a P3 we can fix later on.

Comment 13

[Marco Mucci [:MarcoM]]

Deprioritized during backlog review.  Removed from IT 39.2 priority backlog and not part of the initial Q2 campaign release.

Comment 14

[Drew Willcoxon :adw]

FYI Blair, bug 1147554 is fixing a Talos regression in startup IO by lazily creating the DB connection.  It's not 100% clear yet if that fix will work, since even if ReadingList internally lazily creates its connection, it's for naught if some consumer forces it to create its connection on startup.  But assuming it does work, you'll probably want to move your _prepopulate call from the ctor to some new method that the store would call when it creates its connection.

(I see your bugzilla name says you don't read bugmail so I'm needinfo'ing so you see this.  I don't actually need a response.)

Comment 15

[Blair McBride [:Unfocused] (UNAVAILABLE)]

I assume you mean this for bug 1136570 :) Will comment there to avoid future confusion.

Comment 16

[Drew Willcoxon :adw]

Oops, tab fail, yeah. :embarrassed: