1

I am implementing an infinite scroll on a table which parent element (aka container element) can be non-scrollable (since its container element's child content does not exceed its height) on init, like so:

enter image description here

I run into a problem when the viewport happens to be taller than the initially loaded 15 rows.

Is it better UX to always keep the number of rows the same and increase the height of each row or initially load a different number of rows depending on the overall height?

  • Welcome to the forum. This question is about implementation and needs to be rephrased to be about User Experience. -- I'll try and edit the question for you. – DaveAlger Feb 20 '15 at 14:42
1

There are very few cases where infinite scrolling is better than paging

There are a number of reasons why paging through long lists of data is a better user experience than infinite scrolling. Infinite scrolling is okay when the data you are presenting to the user is virtually endless and also being selected for the user by the application like on Twitter, Facebook, Pinterest, etc.

Read more on this topic in the following thread: Regular pagination vs. infinite scroll

Dynamically fill the vertical space

One of the downsides to infinite scrolling is that it isn't always clear to the user what they are currently looking at or if they can even scroll at all. I would prefer to load the entire list of items if possible and see the native scrollbar / scroll thumb to indicate how many things there are and how far down the list I am.

In your example, I don't think showing the same number of items at all times should be a requirement and instead would show as many items as I could fit on the page plus a few more. Also it is a good idea to add some sort of item after the end of the list as an indication when more items are loading.

  • In our case, our clients hated pagination. Let me explain a bit. We have a lot of filters (the input fields) wherein they could just type in more information (if they have any) if they cannot find a certain person, and paging makes them lose what they were doing. There is also a feature where you can arrow down or up and a row would be selected (then trigger a modal). – srph Feb 21 '15 at 1:06
  • If the user is relying on filters then it might make sense to simply say "over 1,000 results" with instructions on how to filter until there is less than 1000 and show them all with a normal scroll bar and result total that keeps shrinking as they type. Relying on infinite scrolling here might seem like a good idea to the user until they realizes their lack of control -- especially in a system where the data is constantly changing. – DaveAlger Feb 21 '15 at 2:31
0

Definitely keep the size of the rows consistent -- don't adjust them for the viewport. That's what zoom+in and zoom-out are for.

You can explicitly ask the user how many rows to draw -- which is nice, because some people might only want to see 10 or 15, some might want to have a table with 1000 rows.

Infinite scroll becomes problematic because if you keep loading records, the scroll bar will keep getting smaller, and there is no way to "undo" the addition of elements in a predictable way.

So try and think about "how do I make a consistent train of states for my users?" ... because when people hit the back and forward buttons they want them to work, not lead to a pandora's black box.

Seems like a cool idea. If you end up implementing it let me know how it goes. I'd be interested to see what you come up with.

  • They won't mind for the hit and forward buttons here since they would be more inclined to use the filters if they cannot find what they are finding for or just scroll down if there are more results. There should be only rows tables if they fill more filters (as they suggest). We kept the rows to 15 at max per scroll due to performance issues. – srph Feb 21 '15 at 1:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.