> Almost all of them suffer from the same problem. If you click on something in the feed that brings you to a new page, when you hit the back button or try to return to that original feed, your place is lost.
Does everyone else see this also? I don't remember the last time it happened to me.
Ha yep! Before our snapback cache, what you're saying was the solution we kept recommending to folks. We use javascript to make the whole note a clickable target area, not just the hyperlink. And so we had to listen for the ctrl+click events too just to make sure that all worked too.
I just realized that I do this by habit so maybe that's why I never see the problem. I'd just as well see all clicks go to new tabs. It's just as easy to hit ctrl-W as it is to hit backspace.
That's really interesting. It's like we've all been conditioned to just have unconscious clicking patterns to deal with this headache.
Opening up new tabs for things was definitely an easy solution on the table. But that's a pretty uncommon design pattern, and one that would probably drive our users nuts. Back button basically goes away as a habit, and then they'd have to learn that just for this app they need new muscle memory of ctrl+w. But yeah, definitely a design choice one could make.
Really depends on what you click on. Twitter and Facebook both have most clicks keep you in the context of the feed with modals or in place expansions. But every now and then some action they haven't fully accounted for takes you to a different page and then bam you've lost your scroll history.
But regardless of what they do, a lot of our content in our feeds doesn't lend itself well all the time to modals and expansions. People want to click into something and check out their contacts history, do some kind of work, etc. and still get back to the feed at the right place.
I just use real URLs that resolve when you navigate back to them... https://www.zadieheimlich.com (terrible use case as clicking a heading takes you to the same thing you see currently on the homepage but you get the idea.)
I pondered doing something like that, however there's a performance impact with that version right? So if I want to let a user scroll for 5 pages (30 records each), click on something, and then go back to a URL that "resolves". That url is going to have to render all 5 pages of stuff to get the look right. That might not be that big of a deal for a bunch of apps, but for us had a cost I didn't want to pay. So keeping it all cached on the client and just picking up scrolling where the user had left off seemed like a good solution right now.
I've never figured out what the problem was that infinite-scroll was supposed to fix. Unfucking the Back button is nice, but it feels kind of like expecting praise because you've decided to stop beating your wife.
Paging is an implementation detail that's forced on users, like flipping the cassette to side B. It's really great for reading a stream of content without having to think about previous or next, especially when referencing items that would otherwise be on a previous page. DuckDuckGo is a good example.
Anyone who has encountered a book is familiar with the concept of pages. I doubt that people would prefer their books printed on a single strip of paper. Why do the same for websites. Not to mention that bookmarks are broken in both scenarios (single sheet books and infinite scrolling webpages).
Couldn't agree with this more. Infinite scroll and expandable sub-lists on index pages make it impossible to use those pages in a meaningful way. If there is ever any value to looking back to previous stuff in the list you need it broken into smaller chunks like pages so that you can find the thing you wanted. And if there isn't any value then why make it available at all?
21 comments
[ 0.23 ms ] story [ 49.9 ms ] threadDoes everyone else see this also? I don't remember the last time it happened to me.
Opening up new tabs for things was definitely an easy solution on the table. But that's a pretty uncommon design pattern, and one that would probably drive our users nuts. Back button basically goes away as a habit, and then they'd have to learn that just for this app they need new muscle memory of ctrl+w. But yeah, definitely a design choice one could make.
But regardless of what they do, a lot of our content in our feeds doesn't lend itself well all the time to modals and expansions. People want to click into something and check out their contacts history, do some kind of work, etc. and still get back to the feed at the right place.
But for something like Highrise, where it's dark to google and crawlers, your solution makes sense.
That said, it's also abused a lot...