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?
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.