Rather like the forward/back for search, it would be great to have a similar feature that navigates between visited flow tabs.
This would be very similar to how a browser works in general. In other words, the Editor would note which tabs had been visited in a history log and the forward/back buttons would move through that history, changing tabs accordingly.
I find that I now have rather a lot of tabs both on my live and dev systems and I commonly want to switch back and forth between a few tabs as I am updating things.
So this would be a massive time saver and productivity boost.
2 Likes
100%
In my prior role I used several different PLC programming tools. One of them had EXCELLENT fwd/back navigation, the others did not. In the departments using the tools without this feature I really struggled to maintain my flow of thought (sic) and often had to stop and go back to the start of the debugging process to find out where I was or how I got there
I cannot stress strongly enough how massively this helps with cognitive load. Once you have it, you dont want to go back. I used to joke and ask my collegues if they would like me to remove the BACK/FWD buttons off their browsers 
In a production environment this is very often the difference between a minor stoppage and a major breakdown.
I have raised this before (but I cannot for the life of me remember where!)
In order for Feature Request to be even considered, we will need a clear set of requirements / expectations laid out (and even then, it is not a dead cert, but its certainly not gonna happen without it) For example:
- How is the feature surfaced? Buttons in the toolbar? Shortcuts?
- On Shortcuts, I would strongly suggest they should have default key bindings set (should be simple and common e.g. Alt+Left/Right)
- What actions push a location onto the navigation stack (e.g. double clicking a node, switching tab, selecting a node, changing sidebar panel, scrolling, page up/down etc.)
- Whether the navigation stack should include taking you back into node edit panels or not.
- etc.
OK, so a first attempt at a requirements set:
- Node-RED must maintain an internal navigation stack variable for the Editor browser display that keeps track of the id of any flow tab selected in sequential order.
- The navigation stack should be an array as a first-in/first-out stack to prevent unlimited size. Suggest a minimum of 20 entries.
- The navigation stack must allow duplicate tab id's - to facilitate user navigation.
- The navigation stack must be updated when a user selects a tab manually (via mouse or keyboard). Must also be updated if an action changes the tab.
- The navigation stack would Ideally be updated on ANY action or event that changed the tab. (Though recognising that this may be complex. MVP is any user interaction).
- The navigation stack should NOT take you to any other navigation other than tab changes. (e.g. ignores previously open edit panels, etc.) It is purely for navigating tabs only. KISS.
- The navigation stack should be implemented as an action to facilitate the use of keyboard shortcuts.
- Ideally, it would also have a visible UI in the Editor as browser-style fwd/back buttons. Perhaps on the left-hand side of the tab row (since the RHS already has other widgets). The visible widgets could be made optional if enough people think that it would clutter the display too much.
- Fwd/Back should also be listed in the tab menu on the RHS of the tab bar (maybe also on the right-click menu for tabs? Not sure about that though).
1 Like
My additions to this (based on prior use case in production env) would be:
- Upon fwd/back navigation, scroll position would be maintained/restored
- Upon fwd/back navigation, highlighted element would be maintained/restored
- Jump points would be added to the stack (e.g. jumping from a link node, jumping from a hyperlink)
- Include node selections to the location stack (optionally disabled if not desired)
- sometimes it is a large flow you need to navigate it to understand where something is going wrong and you need to go forwards/backwards while you figure it out. And more often than not, that flow is not your own or you are not in a position to refactor or "improve it" across multiple tabs as much as you might want to!
- a larger stack size would be better (50 or more) (your browser is not limited )
2 Likes
Absolutely agree. I was trying to be conservative. 
I figured 20 would be a useable absolute minimum but more is better. I just didn't want us accidentally crashing the browser by using up all memory! 
Your other requirements - just my personal opinion - would be nice-to-have but possibly not MVP if they add to the development time - or worse, stall development completely due to lack of available resources.
#3 is interesting though and that would certainly fall under my point #5.
