Better scroll position management

[davidben]

Managing your scroll position is a problem right now. The recent positions was an experiment to automagic multiple head positions, but it seems to not work well. This bug will serve as a dumping ground for random thoughts.

Some use cases that should be served, ideally:

1. Narrow to a conversation, scroll around a bit. Unnarrow to the state you were at before narrowing
2. Having two tabs to Roost should do something... vaguely sane?
3. I have a work filter (okay, ignoring the part where our filter system sucks right now) and a normal filter. I want to keep track of both scroll positions. Read through the work filter during work, when I get home I want to read the normal filter from where I was then.
4. Read messages on another device. Going back to your first device should offer to jump you ahead.
5. Press home/end to jump to top or bottom. Return to where you were previously.

One thought: several operations should push the scroll position into the back/forward history. Or something more explicit in the UI so you don't accidentally go back past Roost. That would honestly handle a lot of use cases.

The current scheme tried to make having multiple saved scroll positions do some auto-fork thing. It doesn't seem to work well. Specifically, it makes 4 up there hard and doesn't make much sense. For reference, this is how it works:

• Store the last 5 scroll positions. Scroll position includes current filter.
• You start from some scroll position. When you scroll, you replace the previous scroll position with the new one.
• When syncing with the server, if there's a conflict and, when you update to most recent scroll state, the position you branched off of is gone, you still insert your new position. This way devices naturally fork the position history if you open two tabs and scroll independently. And we keep track of the most recent 5 heads.

[davidben]

Other things: it would be good for everything to treat mouse/touchpad/touchscreen-based interaction and keyboard interaction similarly. Also things should work reasonable if you switch from keyboard interaction to pointer interaction and back. That's why it currently syncs based on your scroll position, and not your selected message (though there's no reason to not sync the selected message...). On a phone, you don't have as much of a selected message.

The direction I'm playing with right now is that the selected message is a more-or-less ephemeral thing. Its intent is act more like a replacement for keyboard pointing device than being persistent user state. Granted, this does run counter to BarnOwl works, so maybe this isn't the right direction. This is why, if you press up/down when the current selection is off-screen, the selection warps to the scroll and not the other way around.

[davidben]

Yeah, I think we want something like a back button. It's pretty natural and handles what I think are probably the most common use cases for narrowing.

[cesium12]

(1) is hard because sometimes when I unnarrow I want to go back to my previous state and sometimes I want to stay at my selected point in time, and there's nothing distinguishing the two except my intention. Maybe if I could press back to get to the unnarrowed previous state, or just unnarrow to stay where I am, that would work.

On Thu, Aug 15, 2013 at 10:37 PM, David Benjamin notifications@github.comwrote:

Yeah, I think we want something like a back button. It's pretty natural and handles what I think are probably the most common use cases for narrowing.

— Reply to this email directly or view it on GitHubhttps://github.com/davidben/roost-client/issues/30#issuecomment-22744500 .

~132.905~

[davidben]

Yeah, that's what I was thinking.

[dovej]

==cesium, but to be honest, I never had an issue with this behavior in Humbug. Reason being: I think I mainly used the BarnOwl behavior to find certain zephyrs and conversations easier (by thinking about other things that happened near them) or to scroll really quick (switch to personals, move backwards, switch back to default view). In Humbug, I never found that I missed this, and I think it was because of a combination of very good navigation and search tools. For one, you had a pretty decent search bar, two, when you search for a term and then narrow on a result, you narrow to the location of that message in that class/instance, not the most recent spot in that class/instance.

Throwing in both is probably best if it can be done without becoming messy, and I think that should be doable.

Also, there should probably be a user controllable "mark" ala BarnOwl. Should be easy to implement, not interfere with anything, and would make BarnOwl users and certain power users very happy. If we have the back button behavior, I don't think we'll need/want the Emacs "set mark at beginning of search", but it could be worth thinking about. It might also be good to one-up BarnOwl by keeping a list of the last few marks set. I mean, it's already doing that with the automark, so just switch the auto mark to a manual one.

[cesium12]

I feel like there were nonobvious technical issues with implementing decent search, but ask David.

On Friday, August 16, 2013, Justin Dove wrote:

==cesium, but to be honest, I never had an issue with this behavior in Humbug. Reason being: I think I mainly used the BarnOwl behavior to find certain zephyrs and conversations easier (by thinking about other things that happened near them) or to scroll really quick (switch to personals, move backwards, switch back to default view). In Humbug, I never found that I missed this, and I think it was because of a combination of very good navigation and search tools. For one, you had a pretty decent search bar, two, when you search for a term and then narrow on a result, you narrow to the location of that message in that class/instance, not the most recent spot in that class/instance.

Throwing in both is probably best if it can be done without becoming messy, and I think that should be doable.

Also, there should probably be a user controllable "mark" ala BarnOwl. Should be easy to implement, not interfere with anything, and would make BarnOwl users and certain power users very happy. If we have the back button behavior, I don't think we'll need/want the Emacs "set mark at beginning of search", but it could be worth thinking about. It might also be good to one-up BarnOwl by keeping a list of the last few marks set. I mean, it's already doing that with the automark, so just switch the auto mark to a manual one.

— Reply to this email directly or view it on GitHubhttps://github.com/davidben/roost-client/issues/30#issuecomment-22764816 .

~132.905~

[davidben]

I mean, mostly that supposedly MySQL isn't very good at full-text search and that apparently you're supposed to use a separate thingy? Definitely worth doing one way or another though; search is a pretty basic feature.

[davidben]

(Secretly I don't actually know how to write database applications. :-P Been making stuff up (and consulting Victor) here.)

[davidben]

I'm not super-familiar with Humbug... what's their behavior?

[dovej]

If you narrow, scroll around, then hit one of the buttons to go back to the main view, it brings you back to where you were before you narrowed. Not sure if there is a keyboard shortcut to go back "home" and if that changes the behavior, but I doubt it.

If you click on a class or instance name in the header of a zephyr, it narrows to that class with that message focused (so you see the conversation that happened around that).

They have a search with special syntax for class and instance matching. Combined with the behavior above, it is easy to find old conversations by searching, then narrowing on one of the results. Narrowing on a search result just brings up the conversation in that class or instance around the time of the result.