Change number of messages displayed per page?

Apologies if this has already been raised. A quick search revealed nothing.

I strongly prefer seeing a large number of messages per page, so that I don't have to constantly hit the "next page" button/link at the top or bottom. The old forum software made it possible to change the number of messages displayed on a page in the user's preferences. I haven't been able to find an equivalent setting with the new forum.

Does such a setting exist somewhere? If so, where?

If not, then please consider this a plea for the implementation of this feature in AMASS. Its absence is by far the biggest annoyance to me with respect to the new forum.


Thanks!

kcbrown wrote in post #17350903
Apologies if this has already been raised. A quick search revealed nothing.

I strongly prefer seeing a large number of messages per page, so that I don't have to constantly hit the "next page" button/link at the top or bottom. The old forum software made it possible to change the number of messages displayed on a page in the user's preferences. I haven't been able to find an equivalent setting with the new forum.

Does such a setting exist somewhere? If so, where?

If not, then please consider this a plea for the implementation of this feature in AMASS. Its absence is by far the biggest annoyance to me with respect to the new forum.


Thanks!

This has been mentioned in many topics already. It is being considered for version 1.1

Ah, good. Thanks. I didn't see mention of it in any of the version 1.1 discussion I'd looked at. Glad it's being considered.

I could not find the discussion where it was mentioned that increasing the posts per page option would be considered, but I did find the post where Pekka explained why he made it 15 per page.

Pekka wrote in post #16070423
With vBulletin going to next page is a pain. With AMASS you have a very clear NEXT button, and I can even make a keyboard shortcut and a swipe detection to help you out.

Point with 15 posts per page is about reserving resources of server (a little), saving RAM on browser (mobile), DOM handling might slow down on very large pages, preventing large transfers of images and data to one client who might not even read it all (15 posts may have 120 photos to download, 50 pages 400), and it does save server RAM because there are less variants for caching to cope with.

We can think of more ways to browse threads later, now I did not want to work on those (I do have couple of ideas) because it would delay the whole thing and one design rule is to keep it familiar.