-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Number of search results per page should be dynamic #14
Comments
Making it dynamic - instead of always 500 per page - is not a bad idea; but 100 results per page seems way too small. Isn't it easier to keep scrolling down after 100, instead of going to a new page? |
The results are sorted alphabetically, I wanted to see something that starts with 'S' so I had to scroll and scroll (I had to scroll too much). However, I looked up online for 'scrolling vs click' and it seems people prefer scrolling these days. I think its just a matter of balance between the two; not sure if 500 is right. The story didn't end here :) |
It does make sense to have the page numbers be at both the bottom the top, yes. And perhaps, instead of calling the pages "1", "2", "3" etc., it makes more sense to link to them as "$-E", "F-P", etc.? That's something I thought about before, but never really looked into. |
Having an option to do both would be better I guess. |
I'm not a big fan of options, just for the sake of having options. If one approach is better in some cases, why wouldn't it always be better? |
Thinking more about it, I don't think an alphabetical-range option is doable, at least with the current setup. The problem is that entries aren't necessarily listed in alphabetical order. Miga currently simply shows entries in the order they appear in the CSV. That's not something that would necessarily be easy to fix - besides needing handling for multiple languages and alphabets, there are cases when data sets shouldn't be sorted by a straight alphabetical sorting - a simple case would be a group of people sorted by last name instead of first. You could add more handling for that kind of thing - like a new "Sort by" field type - but it would be more work. Adding the set of page numbers to the bottom of each screen does seem like an easy improvement, though. Reducing the number of entries per page would be easy too (or the default number, if that becomes more dynamic), but I don't know if there's a better number. |
I just the page numbers to the bottom of the screen as well - thanks for the idea! |
I am not sure if this is possible now, but there should be a way to switch the display of search results to be dynamic. If there are 651 results we shouldn't show 500 on first page and only 151 on second page but spread them out a little.
651 is relatively a small result set and 500/page is relatively too much. I would have preferred if it were displaying a max 100/page for results set of this size.
The text was updated successfully, but these errors were encountered: