Revisit item paging mechanism

[taylortom]

Affects

• Projects (dashboard)
• Assets

Current Behaviour

Think we need to improve the way we load up new pages. Currently, we load a single page at a time (a page is the number of items that the user can see at once without scrolling), and do a fetch when the user's near the bottom. The disadvantage to this method for users with a slow connection is that you can get a hang while items are fetched when you're at the bottom of the page. As a user, you also have no idea how many items there are.

Alternative approaches

Improved infinite scrolling

To make this more of a background operation, we should probably load up at least two pages at the beginning, and fetch a new one when we get to the end of the first.

e.g.
=> load pg1, load pg2
=> All pg1 items viewed, load pg3
=> All pg2 items viewed, load pg4
=> etc...

Old-fashioned paging

Show numbered pages, with nav buttons to switch between them.

[lc-thomasberger]

How do you guys feel about an old-school paging approach rather than infinite scrolling?

Infinite scrolling is fine from an UX point of view. However, paging with numbered pages gives you more control and you get a better understanding about the "size" of your (filtered) collection.

https://uxplanet.org/ux-infinite-scrolling-vs-pagination-1030d29376f1

[taylortom]

This is definitely something that should be solved by the refactor in a consistent way (i.e. using common REST practises if we decide to stay RESTful).

[taylortom]

Closing due to inactivity