Is there some sort of shortage of CPU time?
Why not all me to see 500 or 1000 rows per page so I can scroll through the things you’re trying to sell me without needing to press “next” every 5 seconds?
Developers please, there’s no shortage of “rows”. Give us more.
Only thing worse than pagination is infinite scrolling.
In the case of Twitter, ctrl-f would allow me to search through my bookmarks, my feed or the replies of the tweet I am looking at. Can the Twitter search do these things? If it can, it's really not obvious, and if not, that sucks because a lot of usability is going out the window with no replacement.
EDIT: Guess you guys have no humor on this page
I actually use a UI like that, and this particular one is not fun to use. You have to wait 2-3 seconds and experience unresponsive UI untill all the 10k rows are loaded
Having said that, I think this approach ("put about 10k rows into the browser") could still work, it just needs more love.
Part of the problem is the lack of filtering (or even sorting) on the client side to reduce the information overload to something you're willing to wade through, which would trade off results returned for query complexity (of course, this also assumes its been programmed correctly...).
We lose a lot using the 'search box only' query interface that google popularised.
If there is filtering, sometimes you can see how poor the integrity and/or quality of the data is due to some weird-ass categorisations, typing mistakes etc. etc.
Attempting to limit searches on laptops to a specific screen resolution did my head in on pretty much all of the major manufacturers sites.
Also, with smaller pages, site owners can track whether many users need page 2, 3, etc. and change page size or reload the next page’s data accordingly.
We could make very, very long scrolls of text in real life, but books are more practical.
Similar thing here, not everyone uses "Ctrl-F". Heck, many users don't know how to search (try to ask non technical people, you'd be surprised) and on mobile browsers for example, frequently there's no way to search (or no easy/easily discoverable way to search).
Infinite scrolling is crap, but 10K rows in a result is going to feel a lot like infinite scroll.
The initial query of all rows might be slow, but once I have a snapshot speed is not the issue. I regularly do ctrl+a ctrl+c alt+tab to Excel and ctrl+j to run a program that gives me the result I am looking for.
Where I have control over the back-end, I like to provide static dated snapshots of queries.
I can be stingy but I would look at: Time to run the query vs. Value of having all the data.
When the user add filters on columns or sets sort order it's added in the where or order by clause respectively of the outer query.
This way we can easily show 100k+ rows (like, all their invoices or orders), the user can scroll and filter to their delight etc, all super-responsive.
Surely it shouldn't be much harder to support on the web if one wanted?
100-1000 elements for example could be accommodated on the same page. 10k make me think about data grids which may be improved by filtering on multiple columns for example.
For your question specifically, the following explain it well I think:
..locating a previously found item on an extremely long page is inefficient, especially if that item is placed many scrolling segments down. It’s much easier for people to remember that the item is on page 3 than it is to gauge where the item is positioned on an extremely long page.
I believe it shows how close the nodes for “web” and the number 3 have got in our heads.
how much time do you have to browse a bad search hit?
From UX perspective I hate pagination and I think in 2021 it’s an anti pattern.
From database and server load perspective, I understand it.
Latency is not an issue, and neither is displaying complex information. You can pull and display 400 dummy items no problem.
Loading time for the first "page" is extra valuable - you'd want that in 200 ms or so ideally. So one trick is load 3 items, then 30 or so.
Also you have to look at actual cost. Perhaps loading an extra 15 queries on the home screen costs $0.0004, but when you have 1m daily active home page uses, that's an extra $400 per day. In unoptimized pieces of code, the cost could well be 20x higher.
If you have a very high average user value like Jira, that's fine. But for say, a free manga site or something like imdb, you want to shave off costs wherever possible.
There’s also the fact that the best UI gives you want you want, not what you say you want.
They could have tested this, and have seen that even users who say they want 1000 rows never look past the 100th or often turn away before the longer page is loaded (That’s the kind of analysis that can lead to lazily loading more data/infinite scroll)
They also may think they already have site functionality that is better for the use case users say they need 1000 rows for, such as an advanced search facility.
10 is just stingy, as OP said.
This all changed with the advent of infinite scrolling enabled via the whole ajax revolution, but this was (is still? I haven’t written front end code in a decade or so) difficult to get right.
In sum, this happened because of technical difficulties on the front end side (browser limitations or code complexity), and probably just stuck as convention. Perhaps some nice analyst then A/B tested the arrangement and found that it was happily optimal.
The big sites have definitely AB tested changing the results per page and have stuck with 10 for some user metric driven reason.
- Payload size: 1000 rows makes the payload huge which adds even more latency
- Frontend performance: More modest machines will struggle to render very large dynamic tables of rich content.
I recently built a feature at BigCo. Like all our stuff, we have the default page size be a meager 10 rows, so as not to upset anyone. Because everything is always 10 rows. However, the frontend is hard coded to always request page sizes of 1000, which results in a payload of less than 100kb. Or at least, that was the plan until an "architect" spotted it and got upset because 1000 rows is clearly beyond the pale. SMH
1000 rows of json is not huge
It’s typically maybe 300k which compresses down to under 50k
- Presenting your bread-and-butter data shouldn't require complex joins or expensive queries. If it does, you are doing something wrong.
- You can serve the text of a thousand page book in just a few hundred Kb. If your payload size is large, then I guarantee it's not the text on the page that's at fault.
- Likewise, no computer (not even one from 1996) will struggle rendering plain HTML. Any performance problems your website has are problems you've added yourself.
I have one with 6K rows, 300ms to insert into page on paper (console.time(1); console.timeEnd(1)), but in reality browser freezes for 3 seconds (1.8s style, 900ms layout, 300ms update tree). Freezing goes away with position: absolute, but it still takes 3 seconds to show up after .appendChild. I tried replacing Table with Flex divs, even worse speed.
table { table-layout: fixed; }Just a <table>, virtualized - here’s an example with 2 billion rows https://bl.ocks.org/texodus/483a42e7b877043714e18bea6872b039
The worst i ve seen is in Bluehost's domain management pages. An unsorted list of domains with infinite scroll where you have to scroll, scroll and scroll hoping that your domain will be in the next block that pops up (because, of course they keep all your long abandoned domains in the list). And they do it again in their DNS Zone file editor. It will only show you the first 10 or so lines of each section, so naturally you think lines are missing and try to re-enter them. The comparison with the plain old CPanel interface is mind boggling. I have complained, they don't listen
Progress!
I wonder how i can start a campaign to legally ban infinite scrolling
Their philosophy is to show less initially but as you start paging through additional pages it'll show more results per page until you hit a maximum amount. For example you could get 25 results on page 1, 50 on page 2, 100 on page 3, etc..
It's a happy medium. Keep your initial result minimal and focused but if a user wants more then keep giving them more in an efficient way (less clicking).
I intentionally put all of my Elixir screencasts on a single page without much whitespace on Alchemist Camp (https://alchemist.camp/episodes). I can't think of a single employer who would have been cool with that design choice, but I frequently get emails and comments from people thanking me for it.
There is no meaningful implementation difference between providing 20/50/100 options and 20/50/100/500 options, with 20 as the default in either case.
I would be very surprised if this decision is even discussed for more than 1 minute on most projects, let alone if any user research is done. But I'm happy to be proved wrong!
Source: I spend a couple years wrestling constantly with these sorts of problems in a React-based toolset we were developing.
One strategy I've used before to improve the user experience and help people miss Ctrl+F less is to load the full data set into memory, even if only a small slice of it is actually rendered at a time, and then do all paging/searching/sorting/filtering client-side. JavaScript has no issue handling six digits of items this way, and it keeps things really snappy.
> if you're, for example, re-rendering your entire VDOM tree on every keystroke in an input field
> This part can be optimized around fairly easily if you know how
The framework can render them, just not update them in the naive way (so in some sense, yes, it is possible you're "programming it wrong").
> the next barrier is number of DOM nodes
The other problem is the browser itself, not any particular framework.
I hate how so many websites manages to break the back button.
I would not assume most users want a lot of choices. Perhaps choosing from a list of 5-10 options is much less intimidating than choosing from 100. If someone clicks next page, then maybe the calculus changes.
If we pull, say, 1000 rows in the foreground, you have to keep in mind when designing UI that you have to wait for data. E.g. you have to design some sort of indication that data is not yet 100% loaded if user tries to search something in page.
Another point is that (maybe, I have no experience in UI design) that users favor fast loading page, even if it only has 10 rows..
It often is needed when you have a set with a million rows. You have to show the end user what the data will look like, give them a sampling, then help them filter and sort it down to what they really want.
That being said, if you show 20 rows when there are only 85 in the set, that is just a silly UX decision. Add a scrollable grid if needed, but the performance difference in returning a couple dozen vs. a hundred is fairly meaningless these days.
Additionally, depending on how your backend is designed and your choice of ORM, sometimes requests can be slow. In those cases it probably makes sense to design a UI that encourages users to rely on search and filter controls vs giving them a large list.
That’s not true it’s dead simple to display 1,000 rows can you explain what the hard bit is?
So, a lot of the time, developers will just limit the page size, in order to guarantee performance on majority of devices...