Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Comments on Sorting answers without a page reload
Parent
Sorting answers without a page reload
Below a question are buttons for sorting the answers:
Pressing one of these buttons results in a page reload, with the answers now sorted according to the chosen criterion.
For cases where all of the answers fit on a single page (no pagination links), could these buttons instead sort the answers in place, rather than the user having to wait for a page reload?
Benefits
To someone on a fast internet connection, this change may seem of trivial benefit. However, many users have a slow internet connection and to them this could make a difference of several seconds, or more in the case of an intermittent connection.
Some users may be in parts of the world where fast internet is unavailable, or unaffordable. Some users may have fast internet access at home, but only slow or intermittent access when away from home.
For example, if I am travelling by train my internet connection speed will vary widely from very fast to very slow, and often has several minutes with no connection at all. I've had occasions where I open a page and then go into a railway tunnel. This means several minutes of being able to read the page I'm on, but not being able to reload the page (and therefore not being able to sort the results).
Browsers without JavaScript
For users who have disabled JavaScript in their browser, the buttons could fall back to being links that perform the page reload that we have currently, so there is no loss of functionality for these users.
Affected questions
Currently, pagination is added for questions with more than 20 answers, which is rare in most communities, so the majority of questions would benefit from this change. Questions with large numbers of answers are usually only seen in contest categories. For example:
- Challenges in Writing
- Photo Contest in Outdoors
- Contests,Critique in Photography
- Challenges in Cooking
- Challenges in Judaism
- Challenges in Code Golf
Even there, questions with more than 20 answers are very rare. The only current examples are 6 posts in Challenges in Code Golf.
The only other examples are from communities that imported questions from Stack Exchange:
The highest example, Scientific Speculation, still only has around 10% of its questions having more than 20 answers.
Post
From a comment "You haven't explained why that's supposed to be bad." I agree that feature requests should motivate a bit why they are posted because that information is needed to judge the requests anyway.
In this case the advantage would probably be a little more convenience by being faster and no scrolling back to the beginning of the page (although that might also be possible with an anchored link when reloading). The inconvenience by a reload however isn't that big in most cases.
On the other hand, there would be additional logic required to differentiate between both modes (in-place and with additional reload) and duplicated effort in once sorting on the server side and another time on the client side. It would increase complexity and maintenance effort of the code base (especially the duplication of the sorting).
Taking both together this feature should not be implemented because very likely there are more than enough features that deliver a higher return with lower effort.
Sidenotes:
Still, when doing the page reload, an anchor should be used to avoid scrolling back to the beginning of the page.
A more general discussion about which features should/could be done in-place (unfolding/folding of comments for example) and which rather should not would be interesting.
1 comment thread