Add Back button when navigating between notes

[laurent22]

There is already a button to go back to the previous note when clicking on a note link:

We'd like this behaviour when navigating between notes too, so for example, if I open "note 1", then "note 2", clicking on the Back button will go back to "note 1". If there is no note to go back to, the button should be grayed out.

There should also be a "forward" button.

The history would be in memory only (doesn't need to be persisted to disk).

[tessus]

Hmm, what's the history limit? After having Joplin open for a few days, the back history will be in the hundreds/thousands.

What should happen to the sidebar? Should the notebook the note was in expanded? Wouldn't we need a forward button as well? (when moving away from the note the folders have to be collapsed, otherwise you'll end up with a huge tree.)
Sorry for all these questions, but for a good firat issue the specs should be clearer.

[miciasto]

Would you also want a "forward" button?

[tessus]

It depends. I just think that the specs need an overhaul. As mentioned in my previous comment, there are a few items that are not clear. e.g. we can't just let the history keep growing ad infinitum....

[thearchivalone]

@tessus, I think that if there was a forward and backward button, the history limit should only exist during a session and then be cleared once the user is done and has exited the app. That's how buffers work in Vim. Of course, maybe add the option to save a possible note group that opens automatically if the user needs to frequently edit specific notes.

Just spitballing ideas here. I hope these make sense.

[laurent22]

Would you also want a "forward" button?

That would indeed make sense and would probably be expected by users.

[laurent22]

The history should indeed be in memory and not persisted to disk.

[thearchivalone]

Would this fully replace the current implementation when going between linked notes to include when the user opens multiple notes in a row or be an extension of that?

[bensoibj]

Good idea! Not only a button, but additionally shortcuts would be nice, like ALT+left and ALT+right.

See also feature request #716

[laurent22]

For shortcuts, let's keep that for a separate issue as this one is a "good first issue" so it needs to be kept relatively simple.

[laurent22]

Would this fully replace the current implementation when going between linked notes to include when the user opens multiple notes in a row or be an extension of that?

Yes, I would thought that was implied? Like there wouldn't be two back buttons - one for the linked note handling, and one for regular navigation, it's just one back button, which handles both behaviours. If the description needs to be clarified please let me know what should be changed.

[tessus]

the history limit should only exist during a session and then be cleared once the user is done and has exited the app

This is exactly my point. I start the app and it runs until a new update is available. Thus usually a few weeks. So if you created a history worth a few weeks it would be a total overkill and memory hog. This is why I mentioned a limit on the history. Pick a number or a timeframe and use a FIFO queue.

When it comes to persistence I think this is debatable. I really hate it when I restart the app that all notes that were selected in the different folders and their positions are gone.

[wbswbs]

Is it possible to access that history in the menu, like for instance the list of the last used documents in Libre Office?

I know this is gonna extend the feature, but think of that possibility, before implementing the back button.

[naviji]

I'll work on this.

[shreyaspapi]

Hey, Are you still working on it?

[HirenMadhu]

Is this issue still open? @laurent22
If yes, then can I work on it?

[naviji]

Working on it. Here is my initial work. #2563

[HirenMadhu]

OK! I'll work of some other issue!

[hetanthakkar]

@na are u working on this currently?

[miciasto]

In a browser, when you go back some steps, and then navigate somewhere new, you lose some of your recent history. Is this what we want in Joplin?

In Joplin, this means that when stepping backwards, you need to be very careful not to view any other note, because as soon as you do, all your forward history from that point immediately discarded.

In a browser, the forward/backward navigation is complemented by recent-history-list and full-history-lists in the History menu. We don't have this in Joplin, so it makes traversing the history feel like walking on a tightrope.

So, just to confirm, does the browser model of backwards/forwards satisfy Joplin use-cases? Or should we be considering for a different model?

[naviji]

I understand your concerns but I haven't seen forward/backward navigation implemented any other way. Not only browsers but also file explorers do it this way. I worry that if we do it in any other way it will feel alien to users.

Can you point me to some applications that implement it differently?

[miciasto]

@naviji yes, I acknowledge those points.

The model they use is simple to implement and simple to understand. It also has limited usefulness in a single tab application.

After trying it, I realise what I need, as a Joplin user, is a history menu. The menu contains a list of the titles of last notes visited, in order, with the most recent at the top. Clicking on any of them takes you to the note (and moves it to the top of the history). Exactly like my browser has. This is the alternate model.

I fear the buttons may not be so useful, and so may be unnecessarily cluttering the toolbar. Based on my own user experience with other apps, I know the back/forward buttons are only useful on some occasions, and only for very recent history, maybe up to max 10 steps, usually just one or two!

Note this is about the use case and spec of the feature, not about anything in your PR implementation. Wrt implementation, there would actually be a lot of similiarity, the differences being the UI element, and appending history to the end rather than splicing.

[laurent22]

I gave a try to the current implementation and it works well as far as I can see, although I'm not a big user of back/forward buttons in most apps (except browsers), but I know some users are. I will merge the pull request as it is, as the code is clean and can be refactored if we want to add more features such as a list of previous notes.

However I feel this is a separate issue - for example, I thought before of creating a smart filter that would display the last viewed or last modified notes, and that would be independent of back/forward buttons, as it is in browsers.