You are reading a single comment by @Thuekr and its replies.
Click here to read the full conversation.
-
Consistent between mobile & desktop version isn't a good goal - benefit from both systems specialties is.
Thuekr-
Consistent between mobile & desktop version isn't a good goal - benefit from both systems specialties is.
Would mobile users be fine with not being able to jump to any page of choice?
I could certainly solve this by removing that altogether.
But if I want to offer mobile users the means to get to any page in a paginated set, then I'm going to have to combine that functionality with the nav buttons somehow.
Velocio
The exact opposite is going to happen.
Currently pagination on mobile has to take up two rows as there isn't the space in one row for the full options:
Page [x] of Y [First|n-1|n|n+1|Last]Just showing "First", "Prev", "Next", "Last" without context and information as to how many pages remain, how to get to another page outside of that sequence, is pretty bad. Not least because what on earth is "Prev"? Maybe it should be "Prior" or "Back", but "Back" has meaning within web browsers, "Prior" implies "Back", ugh.
So I've been thinking of moving the pagination form into the pagination control on mobile:
[First|n-1|[x]|n+1|Last]It's tight, shows the current page, allows you to jump to another, is more consistent between desktop and tablet and mobile. It doesn't communicate how many pages there are if you're not at the end, but it does give you info about which page you are on and you can still binary chop your way backwards.
This looks good in testing, so may go live today.