Possible "take me back to where I was" button on progress bar

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

A similar idea for consideration that covers an overlapping, but different number of the use cases:

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.

1 Like

I think the bigger pain point that you can have reading holes and have no way to track them (simply by clicking on a link)

Regardless, I think the last read point can be calculated as:

  • largest contiguous set of read posts
  • prioritizing the set that includes first post

This gets weird though, better to think of it as “take me back where I was before I started jumping to footnotes”

1 Like

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?

1 Like
  1. 99.9% of the time “take me back to where I was” would be your last read position.

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

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

1 Like

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

1 Like

not too many if we stopped mucking with the URL as you navigate through a topic :slight_smile:

1 Like

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.

1 Like

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:

And then when you click on the little dot to back to your original location, it keeps track of where you came from like so:

Seems to be a pretty easy way to handle this when the custom scroll bar is available.


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 :wink:

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.

Lowest Point I have Read is the most valuable bit of information to show on the timeline.


One slightly different idea (which apparently I brought up before) would be to just show the “highest place I have not read”

The use case I have in mind is this:

  1. I have read the first 10 posts of a 100 post topic
  2. Another topic later links to post 90, and I click that to check out the reference
  3. Now I want to pick up where I left off to catch up on the conversation
    I want to jump to post 11 - the first post I have not read.

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?

Hmm… I just tried this out:

  1. Clicked the Activity field on a topic I’ve never opened to get to the last post
  2. Went back to the topic list
  3. 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”.

Just my 98 cents.

Not following, if you jump to the end of a topic, the end of the topic is now your last read position.

There is no concept of entering a topic at anywhere other than

  1. Top (never read before, or tapping on post number)
  2. Last read position (tapping on topic title)
  3. Bottom (tapping on last post date)

From the main page of the Discourse website:

Remembers your place

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:

  1. I want to “read an entire topic”
  2. It is too long to read “in one sitting”


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.

1 Like

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.

Pretty sure they already do keep track given the little blue dot next to each unread post.