Add pagination to library

[txau]

No description provided.

[danicatalan]

@txau I remember that we discussed about this some time ago, and I'm rescuing a post about Infinite Scrolling vs. Pagination vs. Load more button that can help us to decide which approach is better.

https://www.smashingmagazine.com/2016/03/pagination-infinite-scrolling-load-more-buttons/

I'm not a huge fan of Infinite Scrolling because it's annoying to get changes on the UI if you have not requested it. And Pagination breaks the user flow when it's looking for a list of document, because the user loses the references inside other pages.

I think Load more button is the better approach to solve our pagination problem. Also if we want to make a "clear state" of pages inside the app, I found an example that can be combined with Load more button: http://codepen.io/SitePoint/pen/XXLrbE

What do you think?

[txau]

I haven't read the article but I totally agree with the "load more" button strategy. I wouldn't add a clear results button for now.

[danicatalan]

I used the loader that we are designing for #30, I think it's useful as a feedback for the user in this context (inside a button): now he knows that something is happening inside the app.

@txau you can see the overall flow here: https://github.com/huridocs/uwazi-assets/tree/master/7_load_more_button

[danicatalan]

More info about it: https://uxplanet.org/infinite-scrolling-best-practices-c7f24c9af1d#.4mi8w4lik

[txau]

A couple of missing pieces:

• What is the behaviour of the upper left feedback "1-12 or 39..."
• How many documents we show by default? How many on every new request?
• Shall we use a global loader?

[danicatalan]

What is the behaviour of the upper left feedback "1-12 or 39..."

This is inherited from the old design. We can maintain this and just change the second value (1-x) with the number of displayed documents.

PD: now you mention it, maybe it's interesting to fix it on the top to don't lose the reference about what are you looking for and how many documents are you reviewing.

How many documents we show by default? How many on every new request?

I always play with this number because of flexibility when we design columns:

• 1 column > 12 rows.
• 2 columns > 6 rows.
• 3 columns > 4 rows.
• 4 columns > 3 rows.

With 12 (or multiple of him) we asure always have the rows with full content, no matter what viewport size we are targeting. This doesn't happen with other numbers (10, 16...)

Shall we use a global loader?

I think so. I don't mind if it's the dotted icons, a spinner or other loader, but if we use a global loader we give consistency in our interface around de app. We can change it later, because it's an encapsulated component reusable in different context.

[txau]

All great @danicatalan , except you just said at #30 that you don't want to introduce the global loader quite yet. And now you are saying that is a good idea. Make up your mind!! =D

[danicatalan]

Oh, I havent explained well. I want it right now xD

[danicatalan]

I have uploaded the video with all the path for #7 and #30.

It's the same loader for both issues, attached at the end of .content block, next to .float-btn. If the content is empty, it will render at the top of the page. If there is content and we need to load more inside it, it will render below them, as you can see in the library list.

This is the video with the example: https://github.com/huridocs/uwazi-assets/tree/master/30_loading_document

[danieldesposito]

Am a bit old fashioned, but I like pagination with the option to display
20-40-60 items so I can create long lists to accelerate through content if
I want to.

On Friday, June 10, 2016, Dani Catalan notifications@github.com wrote:

I have uploaded the video with all the path for #7
#7 and #30
#30.

It's the same loader for both issues, attached at the end of .content
block, next to .float-btn. If the content is empty, it will render at the
top of the page. If there is content and we need to load more inside it, it
will render below them, as you can see in the library list.

This is the video with the example:
https://github.com/huridocs/uwazi-assets/tree/master/30_loading_document

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AEONgp_yPJ8VCdoEG4cJWw_6YOAOOCx7ks5qKVCGgaJpZM4Iporz
.

Daniel D'Esposito
Executive Director
https://www.huridocs.org/
Geneva Office
3, rue de Varembé
1202 Geneva, Switzerland
+41227555252
PGP: 7C04D782
https://pgp.mit.edu/pks/lookup?op=get&search=0xAF3C91D57C04D782
website http://huridocs.org/ | facebook http://facebook.com/huridocs |
twitter http://twitter.com/huridocs | linkedin
https://www.linkedin.com/company/huridocs | newsletter
http://eepurl.com/raFyP

[danicatalan]

@danieldesposito that would be great, as long as we can add a selector at the top of the list and we can make it work without pagination. Also, we can add a "Load all documents" button just in case someone wants to view them all.

I think we can add this in further sprints as a new story.

[danicatalan]

• Add 12 of 39 documents for "keyword" below the item list, with load more button.
• Add qty of documents that we will load inside the button (Load 12 more).

[danicatalan]

Updated at https://github.com/huridocs/uwazi-assets/tree/master/7_load_more_button

[txau]

LGTM. Moving it to dev.