I have so much in my “favorite stories” section, is it possible to bump up the entries limit to like 100? Even 500 would be awesome. Right now, it’s only up till 50 and it’s just a bit of a hassle to have to keep clicking next page instead of just continuously scrolling for a longer while. It’s just a small request though, no need to feel pressured about this.
I like that you have so many favorite stories
The problem is that a longer list on one page also causes a higher load on the site. 100 could be doable, but more would be a problem. But as with all feature requests: People who like to see that should click the heart icon on the request posting.
Would unending scroll/lazy loading help with the server load?
Of course, “unending scrolling” has been introduced because it’s both responsive and easy on the server load.
I had the plan to use that technology everywhere on the site, but when I suggested that, I got some heavy flack, as some people seem to prefer the traditional paging…
I hate continuous, infinite scrolling myself. It makes it impossible to jump around quickly past a ton of results.
I didn’t realize it, but I’ve got about 150 favorites myself. I actually have a fair idea of what ones are on the third page of results, so if I’m looking for those, I jump right to page 3.
Phew. I almost offended GSS’ “Éminence grise” …
To me, paging is always inferior. But otoh, I rarely use a phone. On a smartphone, scrolling is more of a nuisance I guess. Anyway, keeping the old paging for practically everything but the main page seems to be a good compromise.
Another option might be to add the ability (even if just in the URL) to start the listing from a specific offset. Then, you could keep the continuous scrolling, but still allow skipping past an arbitrary number of entries.
I’ll try to come up with something. I’m pretty sure that I’ll never convert the paging-fans though
I hate to be a negative nancy, but I do think feedback is important.
I also have come to dislike the infinite scrolling. I initially defended the change, despite my skepticism, assuming it was one of those things that people - myself included - simply needed to ‘get used to’. Turns out, apparently, that I was wrong. It just doesn’t work for how I like to use the site. So actually at this point I pretty much never read new stories, which is a shame.
Rather than pointlessly insist that endless scrolling be abolished, however, I will make two suggestions that I think would make the new format significantly easier to use.
Limit the number of tags on a story. It is not uncommon to see stories with upwards of 20 to 30 tags, sometimes more. This consumes a great deal of real estate on the homescreen, and in my opinion offers nothing. Tags should be used to summarize the main themes of the story. I don’t know why anyone needs more than 10 tags. It’s just BLOAT and makes it more difficult to wade through the list of submissions.
This one is probably more controversial. I do see the benefits of it, but for me, having both the series and the chapter descriptions appear together - essentially doubling the size of the story entry - also contributes to the bloat.
To put it another way, these days it seems like each story entry is taking up waaaaayyy too much space. It’s basically just sensory overload. There’s just too many damn words on the screen!
I am acutely aware from my experiences as a writer that you definitely can’t please everyone, and I am not expecting or even requesting that things should be changed based on this one post. I figure it doesn’t hurt to throw out my thoughts, though, and continue the dialogue on this.
Your points are valid, but they’re not really related to infinite scrolling.
I’ll probably make the series display and/or tag display optional. I.e. they’re “collapsed” by default, but you can “expand” them either automatically, all at once or individually.
This actually does make a lot of sense on mobile devices.
I’ve put some work into the list displays on smart phones. Details under Site updates.
Let me know if you like the changes, your posting made me look into this. I’m rarely using a phone to browse the site, so I tend to miss shortcomings there,
I’m not sure how much the AJAXy-ness of “unending scrolling” helps, but I twas also thinking that perhaps you could get the same effect with a paginated system that instead of reloading the whole HTML page, just requests the next batch of stories on the list? I believe you can also iterate the URL with an anchor so that the browser’s back and forward works correctly… Although I’ven’t fiddled with that stuff in years…
Actually, I’ve put loads of work into the browser’s history handling (i.e. back-button) to make sure it works properly for the endless scrolling on the homepage.
Try it: If you scroll way down, click a story, and then use browser back to return to the home page (NOT clicking “Home”!). It should bring you to the exact spot you left the page. It will restore everything that had been dynamically loaded to that point.
If you have a slower device, you might have to wait a second or two, don’t scroll too fast manually.
Let me know if that doesn’t work for you…
(and yes, I had to fiddle for a couple of days to get that right - and I’ve learned quite a lot doing this!)
I’m generally fine with navigating through the site… I was thinking that a paginated page driven through AJAX would give guys their paginated site preference, but also meet the needs of lower server load…
Well, as I’ve already said, you can always use the paginated page here, it has the exact same content as the main page, just paginated (and with additional sorting options). This button will also lead to that page, so a single touch or click and you get the paginated view:
Of course, you can always bookmark it, too.
The reason that using AJAX is better in general:
All annotations (rating badges, no. of comments, word counter, and the “bookmarked”, “like”, “have rated” icons) are loaded separately and asynchronously so you get the actual stories listed before all of this has been calculated and retrieved from the server.
Way better cache hit ratio as each of these things can be cached individually
All of the above also applies for the “old” paginated view, as this also uses Ajax for all of this.
But the added bonus for the “endless” main page is that the loading block size is fixed at 10 (on the pagination pages, you can choose a list size, and using 50, for example, is a huge strain on the server for each page).
At the same time, endless scrolling is easier and more natural to use, as we know from experience, that many people don’t even care about flipping the page and just look at the first page (the Google phenomenon… if you’re not on the first page, you’re basically invisible).
Stories on the subsequent pages suddenly become way less attention and hits. Limiting the page size 10 makes it even worse, of course. But allowing the page size to be increased put a very notable additional strain on the server.
So the endless scrolling was the best compromise: No fixed page size, easy handling for the user, and the stories don’t become less visible by falling back to the subsequence pages.
Also, you get way better response times for the user because the interface becomes usable right away, without having to wait for any stories and series to be loaded in the backend.
I’ve increased the limit on all lists to 200 in the update that will go live later today.
Sorry that this took so long.