Would "endless scroll" work with things that are editable?

Question

I'm working on this application that's sort of like a blog. I'm thinking about doing a thing where the user can scroll through all their posts using an "endless scroll" functionality like Google Reader has.

Here's the problem I'm anticipating... if the user clicks on a post to edit it, that will take him/her to a new page. Soon enough they're going to want to go back to the scrolling view and they'll probably want to return to the same place they were at when they clicked "edit."

I imagine they'll be startled if they don't see the same collection of posts that was there when they clicked "edit." They aren't going to want to go back to the beginning of the scroll-while-progressively-loading-posts process and have to do it all over again.

I had the thought of storing the IDs of the accumulated posts and the scroll position in the session and reconstructing everything when the user returned. But what if they had scrolled through dozens or hundreds of posts before they clicked "edit?" That could be too much data to load in a reasonable amount of time.

Then there's the idea of using a dialog instead of going to a new page for editing, but that introduces a whole other set of problems. E.g., what's supposed to happen if the user tries to open the dialog in a new tab?

So maybe this isn't a great setting for "endless scroll." Maybe conventional paging is way to go.

Has anyone implemented something like this? Any thoughts?

Answer 1

I've done something with dynamic data sort of like this. I output an anchor tag that was the ID of the post and passed it through POST or GET, or within the post based on what the user was clicking so that when they navigated to the page again my code would put in the anchor.

something like:

header("location:http://www.myDomain.com/posts.php" . "#" . $post_id);

Answer 2

Beware: I find 'endless scroll' annoying. It messes up the scroll-thumb as an indicator of position, with surprise changes and pauses. At some point it will become unwieldy -- the 'hundreds of posts' scenario you mention -- unless there's even more complexity (discarding items off the top when you're deep, offering random access).

But, consider how Google Reader, the example you cite, deals with the problem: you rarely navigate away from the endless-scroll window. Some per-item operations (tagging) happen inline, but most links open in another window to sidestep the issue entirely. If you go off to change settings, then 'return to google reader' your scroll-position returns to the top -- so maybe it's not that big of a deal. (Though notably: when you return, the extent of the list is all the previously-loaded items -- not the original just-top-loaded. More on this below.)

I would consider non-modal in-place editing -- the edit box inserts in the scroll area, atop or adjacent to the item being edited.

Or, if the one key bit of continuity is you want to send people back to view exactly the item they just edited, make sure the 'return to list' link includes a pointer to the one place the view should auto-roll-to (for example, in the #fragment anchor).

Further, if either your code or the browser have effectively cached the hundreds to preceding items (as I noted above Google Reader appears to do), the roll-forward should be instantaneous, with no reloading necessary.

Answer 3

Endless scroll UIs are known to have a learning curve on them - depending on your user-base, they may be rather unfamiliar territory and confuse more than help. This is likely to change in the coming years or months, so it all depends...

As always, if in doubt, find out from your users themselves. Ideally you should run an observational study where you watch them using similar endless scroll UIs. Are they completely flummoxed? or do they quicky 'get it' and see it as speedier solution than conventional pagination?

Remember that people like us (who use twitter and google reader) are ahead of the curve, and our needs, goals and expectations are likely to be different to your target user-base.

So, in a nutshell, you should really start by finding out whether an endless scroll UI is appropriate. It's entirely possible that it isn't - thus neatly sidestepping your question above.

Answer 4

Endless/long scrolls are bad usability practice. Even if you manage to re-direct the user to the correct post after an edit, they may have forgotten where they were during making the edit. They will then page up to confirm which page they are on.

Maybe just keep it simple and limit the posts per page & provide paging functionality. This is familiar UI functionality to users & they shouldn't get lost.

Or just provide each posts heading, which can be expanded/contracted on a click to see and hide the full post respectively. This will allow alot more posts per page without excessive scrolling.