One thing that comes up time and time again is that once you start navigating in a topic stream, jumping down to later replies, jumping back up to earlier replies…
… you lose track of where you were in the stream. You “lose your place”.
But Twitter has this great new feature which lets you jump to the top with a visible button (this is an implied shortcut on iOS, which has the “tap to jump to top” feature, but Android does not and getting to the top after scrolling down a lot is excruciating, or at least it was until this feature was introduced)
So what if, when you jumped in a topic, we kept track of your previous scroll position before you jumped and showed it above the progress bar like so:
Now, in this case “back” could be up or down, but it’s the place you were before you jumped.
(There is a far more complex discussion we could have about what “where I was” actually means, but I want to keep it simple, meaning your last position before you jumped anywhere. Jumping over and over does not change your original position you started from. Each jump does not track the previous jump position, only the original, first place you started before jumping at all.)
I can’t say I’ve ever encountered the need for a dynamic “back button” while using Discourse, and I consume 3-4 Discourse forums daily. You don’t have an x-to-y post-position in Twitter. In Discourse you do, and it’s hard not to pay some attention to it.
Say I’m reading a book. On page 34 it says “remember that thing we discussed on page 12?” or “see glossary on page 202”; I won’t have a hard time juggling those two different positions.
Discourse even has read/unread callouts, so if you have to retrace your steps a bit just “follow the blue dots until you’re back where you started”.
All of the above can be further reinforced with a custom scrollbar, which seems like a very likely addition at this point (though not necessarily as mocked up in my post).
I think a pop-up button is a much better idea @mcwumbly but I also agree with @erlend_sh that we can probably bundle this behavior with right gutter progress bar later, too.
The better example is jumping to the footnotes while reading a book. You always want to go back to your original read position, even if you visit several footnotes on that page.
I think these are both useful features. I personally like the idea of a shortcut to go back to the first unread post, and I think I wouldn’t have much use for “take me back to where I just was” if I had it.
“Take me back to where I just was” is very similar to features common in IDEs or in some ways can just be thought of as re-implementing the back button (because we want the back button to always jump you out of the topic?). I can see it being useful, but I’m not sure its much more useful than just the “take me to the first unread” post.
If one were much easier than the other to implement / maintain, I might just start there, and then see whether the next one really still feels necessary.
Or if both seem like distractions from the larger goal of a fancier scroll bar, maybe the effort is best focused there?
99.9% of the time “take me back to where I was” would be your last read position.
Probably we will defer all this to 1.5 before we change the right gutter. Right now it is just tossing around ideas. As a long term Twitter user I was shocked how useful the pop-up jump to top Twitter feature I described is. Do you use Twitter? And it makes something that is virtually invisible (tap the title bar to move to top in all iOS apps, but does not work at all on Android) both radically easier to find and discover, and available to Android users. That is a very clever trick.
We have no concept of the back button doing anything within a topic. So the pop up “go back” button appearing as needed, when it made sense to appear, and drawing attention to itself when it pops up, would be additive.
We should probably have the browser back button do the same job when the button is active (maybe even triggering its click animation), if we can manage that. (Might require significant programmering gymnastics.)
Am I misunderstanding what you’re suggesting here? It sounds as if you’re proposing changing the normal functioning of the back button, which seems to me like a Bad Thing.
So I think that fact that this could be handled best with the custom scroll bar has already been identified, but I was using the Kindle app last night and the way they handled jumping around a book I thought was pretty intuitive. Essentially if you click on a footnote on the Kindle app, it jumps you to the location like so:
I think this should definitely be covered by the timeline we’re going to move into the right gutter in 1.6. There should always be a clear marker of “the lowest point I have read” exactly as @rewphus illustrated, except rotated so it is vertical and more like a scrollbar
I also remember early experiments @riking did showing a complete map (by color) where the “unread holes” are in a topic but I think this is Too Much Information.
Not sure that is super useful, I think “back to my prior scroll position” might be a better way of stating it, rather than tracking more read holes in topics?
Clicked the Activity field on a topic I’ve never opened to get to the last post
Went back to the topic list
Clicked the topic title.
It took me to the last post again.
I would prefer it to take me to the first post in that case, since I’ve never read it. I guess my point is to only track one thing. In all the places where we currently track “last read post”, just replace it with “first unread post”.
Topics that you read for a while, replied to, or created will be automatically tracked for you. Don’t worry about reading an entire topic in one sitting – we’ll always save your place.
I’m trying to make a case that when:
I want to “read an entire topic”
It is too long to read “in one sitting”
Then:
If I am jumped ahead by someone’s link, “my place” being remembered for me would better be defined as the first unread position vs. the last read position.
They are usually the same thing.
But when they are not, what I really want in order to achieve this primary goal of discourse is what I’m describing, not what exists today.
I understand what you’re getting at. My use case may be different in that I usually do not postpone reading (well, at least scanning) posts in a topic once I enter it.
But I have noticed that on rare occasion there is either a new topic or a topic with unread posts where someone @ mentioned me. If I go to that post via the Notification I need to scroll back to read any previous posts in the topic I hadn’t read.
Again, in my case this is usually not that big of a problem, I Watch a lot of categories, I visit very often, and it doesn’t happen all that often. Perhaps because I am in the habit of using Notifications after I have read all the New and Unread. Exception being Message notifications which I read right away.
I wouldn’t think having Discourse keep track of what posts I’ve seen would be viable. TBH I think having Discourse keep track of what topics I have seen probably incurs a big resource hit as it is.
Maybe a more sane approach would be some type of “if entered because of a @ mention don’t alter the topic’s last post read value”?
Even then, there’s likely to be some “Huh, I read that, why is it saying I didn’t?” confusion.
