Lose the infinite scroll and show me number of items

[angrybrad]

Created by: Ryan Masuga ([email protected]) on 2016/09/16 16:15:29 +0000
Votes at time of UserVoice import: 83

---

I'm not a fan of infinite scrolling. I don't think it adds anything to the Craft CP other than more JS. I would at least like the option to select "standard" pagination in the control panel. When I'm looking at members, Assets sources, or channel entries, there are no counts anywhere. I have no idea if our current site has 500 or 5000 members, I have no idea if there are 50 or 500 blog posts, and I have no idea how many images are in Assets source X - and neither does the client. Without pagination, we can't even guess at these numbers. I'm just scrolling, scrolling, and eventually give up.

This would apply to (at least): Asset Sources, Users, and channel entries - anything I would normally have to scroll through infinitely.

[angrybrad]

Posted by Ryan Masuga ([email protected]) on 2016/09/16 16:15:29 +0000

---

We ended up installing Zenbu. In addition to giving us many more column options for the client, it shows pagination and counts. As a (temp?) solution, this might work for you as well.

Here's a pic in action: http://cloud.gomasuga.com/0X2r2z0o2F3c Paginated results, and now we're certain that we have 72 entries in this channel.

[angrybrad]

Posted by Matt Wilcox ([email protected]) on 2015/11/12 11:03:22 +0000

---

The infinite scroll breaks the search ability in all those cases too. If the items aren't already loaded, the search filter doesn't work to find them.

[angrybrad]

Posted by Ryan Masuga ([email protected]) on 2016/09/16 16:15:29 +0000

---

Mats - Thanks for the comment. There are actually two issues here:

1. There are no element indexes. This is a content management system, and yet you can't get a feel for how much content you have, particularly on a build with lots of entries. Imagine having a membership-heavy site, with 50-100 signups a day. As it stands, unless you write a custom widget or something, you would have a hard time knowing how many members you have.

2. The infinite scroll doesn't help with counts. At least with traditional pagination, if I knew it was showing 100 per page, and there were 3 pages, we could guess that there are 201-300 entries/members/etc, and I could easily page through them, rather than scrolling for who knows how long.

One other issue with infinite scroll. You do a search and whittle the list down to 10 entries (out of how many? Who knows!) and you need to look at each. If you click one and go back, you have to search all over again to get the same 10 to come up again. Otherwise you have to open each of the results in tabs.

[angrybrad]

Posted by Mats Mikkel Rummelhoff ([email protected]) on 2015/03/09 00:12:31 +0000

---

The crucial part of this FR is adding more info/stats to element indexes (i.e. displaying the total number of entries). More filtering options (e.g. entry type, author) would also be very welcome (and there should probably be a defineAdditionalFilteringOptions hook for plugins...)

As for navigation, a more traditional, paginated view would definitely be way more usable for indexes with a lot of content. If pagination could be achieved as an additional view (i.e. keeping the infinite scroll around), I'd be all for it. If not, I'd opt for pagination across the board (naturally with a "Number of items per page" option).

[angrybrad]

Posted by Visiluna ([email protected]) on 2015/06/16 22:04:13 +0000

---

I, too, would like this, but as a selectable option.

[angrybrad]

Posted by Anonymous ([email protected]) on 2015/04/13 10:56:21 +0000

---

If there would be pagination I would prefer to be able to set the number of items per page.

[angrybrad]

Posted by Ben Parizek ([email protected]) on 2015/03/12 23:19:32 +0000

---

The infinite scrolling also feels a bit funny for larger amounts of hierarchical content like Structures.

[masugadesign]

Noting that I'm the one who put this request in - and I thought I'd comment here so Brad isn't so lonely.

[bcartier]

Yes! Please drop infinite scroll! It's out of place in an otherwise thoughtfully designed admin panel.

[JasonEtco]

What would happen when you click the checkbox to select all? Currently it selects all items that are loaded in, then when you "infinite scroll" downwards the newly loaded in items will not be selected.

[benjaminkohl]

This feature request had far more upvotes when it was on that other User Voice platform. I feel that it has gotten lost among github repo issues. Is the github "Issues" area the best place to collect this kind of feedback?

[brandonkelly]

@benjaminkohl We haven’t forgotten the issue. We just don’t care much for it, and have other ideas that will improve these pages when managing large sets of content, that don’t completely do away with infinite scrolling.

[benjaminkohl]

Okay, thanks.

[ryanmasuga]

https://medium.com/simple-human/7-reasons-why-infinite-scrolling-is-probably-a-bad-idea-a0139e13c96b

Some points (and good questions in #7) to ponder in that post. We have clients with 10's of thousands of assets and entries, and using Craft becomes tougher (for them AND us...we have to use the CP too), which makes considering it for a site that we know will have zillions of elements a less viable option.

[brandonkelly]

(FTR I wouldn’t recommend Craft if you have zillions of elements, regardless.)

[timkelty]

FTR I wouldn’t recommend Craft if you have zillions of elements, regardless.

Don't mean to derail the thread but as someone who has employed Craft for apps with zillions of elements, that answer is somewhat alarming to me.

If so, what's the tipping point, and why? Are we just talking about UI decisions or larger scalability concerns?

I say alarming because given my experience with Craft, I wouldn't discourage a client from choosing it simply because of the sheer size of a data-set. Your statement makes me wonder if I should reconsider that, and wonder where the edges are.

[brandonkelly]

@timkelty I was taking the “zillions” literally 🙃

[brandonkelly]

Realistically Craft 2 works pretty well up to the hundreds of thousands of elements; Craft 3 can go significantly higher.

[timkelty]

@timkelty I was taking the “zillions” literally

That's fair, didn't mean to get all heated. 🐲
I probably would have felt better if you said "eleventy billion". :)

FWIW, my Craft 2 experience is the mid-hundreds-of-thousands range and the biggest issues I've battled with are:

• CP – UI/searching/speed issues
• Tasks – e.g. long running/resource-hogging (re)saving tasks

…neither of which seem all that foundational/architectural to Craft. We've really taken to using Craft as an API data-source for apps with large/rolling data sets, so I could easily see projects approaching the millions of elements.

[j-greig]

What about adding an entry count at the top of the page as an interim addition?

This is started to really bug me

[ryanmasuga]

@j-greig Make sure to check out this new Craft 3 plugin to add counts: https://github.com/aelvan/craft-cp-element-count

Works well:

[jkorff]

I recently imported 450+ entries which I had to manually polish.

Imagine the frustration when segmenting this work and starting again at letter "P", or "W".

Infinite scroll = infinite frustration.

[sjelfull]

Some good research over at Smashing Magazine: Infinite Scrolling, Pagination Or “Load More” Buttons? Usability Findings In eCommerce

[johnwbaxter]

It's certainly hard work with a large structure. I have a very large category structure with 3 levels deep and about 2000 nodes in total and it's not much fun trying to use it in the backend.

[j-greig]

In the meantime even just an entry count at the top of the listing would be helpful.

[timbertens]

Yes agreed, CraftCMS is super but managing a lot of entries is hard and infinite scroll is the major reason. Especially since the search in incomplete if not all entries are loaded which make the search useless in those cases

[brandonkelly]

It's certainly hard work with a large structure. I have a very large category structure with 3 levels deep and about 2000 nodes in total and it's not much fun trying to use it in the backend.

The difficulty of the entries infinite scroll has been the single most commented on frustration of our clients; especially, for structured sections.

Structure views are one of the main reasons we needed infinite scroll to begin with. Does anyone have an example of a paginated and sortable tree structure? How would you drag an element down a few notches if it’s the last one on the current page? Or drag an element up, if it’s the first one on the page?

[sjcallender]

Does anyone have an example of a paginated and sortable tree structure?

No. But would it be possible for tree structures to have a unique view where either:

1. Everything loads (like, dare I say, Structure for EE), or
2. Just show top level parents with ability to toggle children into view (saving initial load times)

I'm not sure that tree structures need the paging and sorting features, since it's a tree. Just searching and toggling children. Maybe I'm alone in this though, which is totally fine. :)

[tjdraper]

That was my thinking to @sjcallender

[narration-sd]

Find myself wondering about a splittable page with drag-drop between, for the long move problem.

You'd probably want search the follow pane in use, the help find the positions, and I don't minimize the effort to make a solid indenting control drag-drop.

[johnwbaxter]

Yep, i agree with @sjcallender on that one. If you get just the top level elements and then you can load in the children dynamically on expand of the parent, that would be ideal. Maybe you could also add a count for total nodes or count of children per top level node which would be useful to the user.

[brandonkelly]

@sjcallender We’ve seen sites with hundreds of thousands of entries in a single Structure section, so loading them all up front isn’t going to work.

The plan we have is sort of a hybrid approach though. We will still lazy load the elements, but the height of the index view will be equal to the final height, if everything were already loaded. Then you can scroll the whole list at once, possibly even jumping to specific points with an iOS-style alphabet list down the right, and Craft will just lazy-load the elements as their position comes into view (without needing to load every single element leading up to that point).

[sjcallender]

@brandonkelly I think that sounds like a reasonable approach for structures given the competing challenges.

For singles and channels, is pagination on the table? or is it some similar lazy-load hybrid?

[brandonkelly]

I’d like to start with the full list idea. You don’t see normal apps like Mail adding pagination, and no one seems to mind that, so I’m guessing it’s going to be an elegant solution everywhere.

[ryanmasuga]

I do think, related to this topic in a general "how much content is there" way, that an entry count at the top of any list, whether paginated or "ghost height", would be useful (mentioned by @j-greig above).

For example, today we had to confirm whether all 5,500 entries were in a channel into which we imported entries. We had to pop open a MySQL app and look at the table to determine there were 4,835 entries. Would have been nice if the client could have seen that entry count in the CP for themselves, so they could have saved time and skipped directly to yelling at us for missing entries!

[brandonkelly]

Agree an entry count would be nice. I think there’s a plugin that will give it to you for now, and we will add it eventually.

[rynpsc]

@brandonkelly Will your proposed solution fix the issue where you loose position after opening an entry and then hitting the back button, finding yourself back at the start.

[brandonkelly]

@rynpsc that could be part of it; at that point we could start storing the scroll position in the browser history.

[guyinpv]

Is there any progress on this issue?
My site has 600+ entries, certainly not huge by any measure, but I have to make edits to all of them and now infinite scrolling to page 4,5,6 is getting old. So after reading this thread it seems like these are the points being recommended:

1. Ability to paginate listings for purposes of direct linking to specific pages, use of back-button when entering/exiting edit page, viewing number of items per-page can be set by user.

2. Ability to have a grand total of listings. I would further add some way to count by status as well. Total published and total unpublished, total with future publish dates, expiration dates, etc. A "at a glace" type thing.

3. Switch between paginated view or infinite scroll on a per-section and per-user basis.

4. For structures, some way to handle drag/drop operations while dealing with pages.

My thoughts:

On my little blog the biggest pain point is simply not having a way to get back to the infinite scroll position I was at when I finish editing a page. If I click on a page, edit it, click save, it should go back to where I was, essentially, right where I left off, if possible.
But even if that's not possible, being able to link deep into the listing would be very helpful. For now though, I just have to leave my listing open in its own tab, and then open the edit pages in a new tab to not lose my place.

As for number 2, doesn't MySQL keep row counts as a normal piece of updated meta data? It should have very little cost to grab those counts and show them somewhere, I would think.

As for number 4, I kind of think that it's a bit unreasonable to need a way to drag and drop for miles down a list. Dragging is for short operations. Instead if you need to move an item "far away" there should be an easy "move" menu where you can select the new location in some kind of popup selector.

But if we must drag for miles, you could easily have a hot spot at the bottom of the listing, like a draggable area which triggers the next page to load into view. Whether using infinite scroll or paginated pages, this hot spot could change the page out from under them. This is no different than dragging an app icon on your phone, when you reach the edge it just slides to the next screen. Whether doing infinite scroll or paginated results, dragging across pages should be easy as long as there is a draggable hot spot that triggers the next loading.

Hopefully there is some movement on these issues soon! It's nearly 2 year old conversation!

[jkorff]

@guyinpv Good points you make, I support your view.
I am using the separate tab workaround all the time.
Being able to link to sub pages (your point 1) is also good if more than one person works on entries.

[j-greig]

CMS's were invented before infinite scroll. I don't understand why we are having to fight for this.

[CreateSean]

I have 1000+ entries I need to open individually, how am I going to open all of them without pagination. For the love of god get rid of the infinite scroll.

This has been a feature request for almost 2 years now.

[brandonkelly]

Non-structure views are now paginated for Craft 3.2.

If you want to help test, change your craftcms/cms requirement in composer.json to:

"require": {
  "craftcms/cms": "3.2.x-dev as 3.2.0-alpha.1",
  "...": "..."
}

Then run composer update.

[jalendport]

Happy April Fools everybody! 😂

[benjaminkohl]

I created a Craft 3.2 local environment fully expecting this to be an April Fools joke but it turned out to be real and I love it.