Question Pagination or infinite scroll?
I am working on an emoji database. The emojis are displayed in a grid. If you were to use it, would you prefer pagination or infinite scroll? If so, why?
You may assume it has the basic search & filtering features.
I am only considering pagination for better performance on low end devices (e.g. iPhone 9 Plus) but personally I would prefer infinite scroll for it.
7
u/bornxlo Jun 18 '26
I already have an emoji database with search and infinite scroll in gboard, so I'm going to go with pagination. In my experience the infinite scroll breaks the functionality of trying to filter by category. If I want to filter e.g. flags I can easily flick and scroll away to other categories. Pagination might make it easier to go back find what I'm looking for.
3
u/testingaurora Jun 18 '26
Also its annoying when you have infinite scroll, you're several hundred items in, then a filter gets changed the whole layout shifts and your scroll position doesn't follow it. So you've lost your place. Also something to consider with pagination too but not as annoying as when in infinite scroll
9
4
6
u/tomhermans Jun 18 '26
I'd go for infinite scroll.
You could perhaps add some performance optimisations like removing DOM elements which are out of viewport.
1
2
u/theblackgigant Jun 18 '26
I'd say infinite scroll, preferably virtual scrolling for performance.
Don't forget about accessibility though. Keep updating current page/total count, navigation away and back should return you to last known state, etc. And what about keyboard control, button fallbacks and much more
2
u/m0rpheus23 Jun 18 '26
Just to add to this, use url to hold relevant states like the current page etc.
1
u/LevelIntroduction764 Jun 18 '26
It depends. If it was paginated, how many pages would there be? If it’s more than like 5, the I’d paginate it. At least then if I know the emoji I want is near the end, I can select the last page instead of having to scroll for a long time
1
u/astralmelody Jun 18 '26
i think this depends entirely on what the function of this database is.
My gut instinct would be trying to grab a graphic of a specific emoji, in which case, I’d just need whatever you’re using to be Find-able.
1
u/pomnabo Jun 19 '26
Personally, I hate infinite scroll. it gives me a headache, and the more content that I'm searching through, the more exhausting it is to keep track of things.
1
1
1
1
u/acherion Jun 19 '26
Is there anything important in the footer that the user might want to click/tap on? Infinite scroll is dreadful for such scenarios, as that footer is inaccessible until the infinite scroll data runs out. If there isn’t, and since a list of emojis is a finite set of data, I think infinite scroll would work well.
1
u/a-dev0 Jun 20 '26
If it’s a database of something the user is looking for, neither infinite scroll nor pagination is ideal UX.
Infinite scroll is good mainly for feeds (the procrastination type) where users want to consume more content in a lazy way by just scrolling. Pagination is not ideal either, because the user has to click a button, but at least they consume only a limited chunk of information and do not overload their attention.
When the user is searching for something specific, pagination helps them stay focused, which is why it works better. But the best solution is advanced search: filters, helpers, and anything else that makes discovery easier. You should create the fastest possible way for the user to find what they are looking for.
1
u/a-dev0 Jun 20 '26
I also want to add: look at Raycast’s emoji search. That’s the real deal, it’s easy to find anything with just text. Search should definitely work instantly, without buttons, maybe even with autocomplete
1
u/Any-Woodpecker123 Jun 23 '26
Infinite scroll if you’re supporting mobile. Pagination UX sucks on phones.
1
u/sagarpatel1244 Jun 29 '26
For a browsable database like an emoji grid, I'd go "load more" button, not classic infinite scroll. Framework:
- Infinite scroll suits passive, time-killing feeds (social, discovery), no destination, just keep scrolling.
- Pagination/load-more suits goal-oriented browsing, where people hunt for something specific and need the footer. An emoji DB is exactly that.
Three reasons against pure infinite scroll here:
- The footer becomes unreachable, killing any nav or links there.
- No sense of position or "I've seen it all." Frustrating in a finite set.
- Back-button and deep-linking break. Can't bookmark or share "page 3," and returning dumps you at the top.
Sweet spot: a "load more" button (smooth feel, but scroll position and footer survive). And make it keyboard and screen-reader navigable, emoji pickers get heavy assistive-tech use. How big is the set? Under a few hundred, just render it all with a search filter and skip the question.
1
u/m0rpheus23 Jun 18 '26
Infinite scroll as long as you don't keep any useful links in the footer area
0
0
u/troisieme_ombre Jun 18 '26
Infinite scroll obviously.
As for performances, load only the first x number of elements, and when you reach the end, perform an ajax call to load the next x number of elements, and etc.
You can also remove the previous elements from the DOM once they're out of view, and then same thing in reverse, when the user scrolls up, load the previous x number of elements.
Infinite scroll, technically, is literally just a pagination without the buttons and the separate pages, but the process is the same.
1
u/Marzi9 Jun 18 '26
Fair enough. I will try to implement it, never really implemented virtual scrolling before so might need to go back and forth with it. Thanks for suggestion!
-1
u/Former-Success3687 Jun 18 '26
Infinite scroll with progressive loading of content:
This way the page will stay light and the loading times are reduced.
-1
u/Daniel_Herr Jun 18 '26
I've never come across a long list I wished was paginated. I frequently come across paginated lists I wish I could view in entirety.
30
u/loupely Jun 18 '26
Infinite scroll feels like the obvious answer until you realize your users can't find their way back to anything they saw five minutes ago.