FlowFuse
Immersive Node-RED experience; merge interface into FlowFuse
Original Issue
Description
FlowForge manages Node-RED already, though when interacting with Node-RED, it's a button to go to its editor. That removes all things FlowForge from view except for a theme.
Value added to Node-RED through FlowForge is now at least multiple clicks away. It would be great if the added value was closer to Node-RED.
The proposal for this epic is to include the Node-RED editor as tab into the sidebar.
Edited
The core objective of this Epic centers around enhancing user experience by creating a seamless integration between FlowFuse and the Node-RED Editor. Currently, users face a noticeable disconnect due to the need for navigating through multiple browser tabs or windows to switch between these two environments. This not only hampers the fluidity of the user journey but also makes the interaction with FlowFuse and its features less intuitive when operating within the Editor.
By reducing the number of clicks required to access the Editor from within FlowFuse, we aim to bring these two environments closer together, making the transition smoother and more intuitive. Conversely, by enabling easier access to FlowFuse's diverse functionalities directly from the Editor, we aim to enhance the visibility and usage of FlowFuse features, thereby enriching the overall user experience.
This Epic seeks to bridge the gap between FlowFuse and the Node-RED Editor, eliminating the UX barriers that currently exist due to the separation into different browser interfaces. The ultimate goal is to create a cohesive, integrated experience where users can effortlessly navigate between the Editor and various FlowFuse menus, thereby promoting a more engaging and efficient workflow.
### User Stories
- [ ] https://github.com/FlowFuse/flowfuse/issues/3646
- [ ] https://github.com/FlowFuse/flowfuse/issues/3655
- [ ] https://github.com/FlowFuse/flowfuse/issues/3647
- [ ] https://github.com/FlowFuse/flowfuse/issues/3648
Was very cautious of this when it was first proposed due to restricted real-estate, but put this together quickly (more thoughts/iterations) on the way:
The left size bar (including FF Logo) would be at the FlowForge-level. Everything to the right of that would be the embedded Node-RED editor
Additional consequence of this type of embedding also means floating UI options for things like Node-RED logs. Not sure yet how to differentiate between a "click this to open a floating side version" vs. "click this to navigate away from the editor and see this in full screen"
Just need to be aware of what gets iframed from Node-RED and what is from the FF platform. The proposed screenshots have the two overlapping in a way that isn't possible.
The proposed screenshots have the two overlapping in a way that isn't possible.
@knolleary it is possible - see my comment here: https://github.com/flowforge/flowforge/issues/2246#issuecomment-1580253712
The FF logo would be part of FlowForge. Within Node-RED, no icon, just the text.
Ah sorry - missed the comment below the big screenshot 😉
Something to consider - a user can still point their browser straight at the url of the instance and get the editor without the wrapping. If we change the theme to not have the logo in the top right corner, then it won't be there when accessed directly.
If we change the theme to not have the logo in the top right corner, then it won't be there when accessed directly.
yeah, had considered this. I'm guessing (as no reason why this would be a thing) that we can't modify theme based on url params? e.g. ?theme= as a param of the UI for NR Editor
I can see the appeal when you work with FF and NR on a daily basis, but to add some counterbalance I'm not overly excited about an "Immersive Node-RED experience". I for one want to hide everything related to Ops stuff away as my audience thinks that "Instances" refers to points in time. "Devices" means smartphones and fitbits, "Snapshots" has to do with cameras, and Environment Variables are carbon emissions and smog warnings. Here, Dev and Ops are different target groups, and to a new user Node Red is challenge enough.
Moreover I don't see it making sense from a UX perspective. What I need to accomplish in FF and NR respectively are often separate tasks, at separate layers of a tech stack with separate goals and audiences. Of course there are occasions when they touch – picking up environment variables, troubleshooting palette issues or creating a custom stack that plays with Arduino's serial interface, but in those cases you'll never be able to beat two separate tabs in terms of speed, or two windows side-by-side in terms of flexibility.
The FF interface is super fast and a breeze to work with – everything is light-weight and loads instantly. In comparison Node Red is a bit on the chubby side and thrives in its own, separate tab.
@lgrkvst Thank you for your thoughtful feedback. I appreciate the nuanced perspective you bring to the table, especially considering the differences in user experience between FlowFuse (FF) and Node-RED (NR). We'll certainly take your comments into account as we continue to improve and evolve our product. The user experience is essential to us, and input like yours is invaluable for making sure we get it right.
Thanks again for taking the time
Hi @joepavitt, not yet. I had planned to start working on it today 😉 I'll share something as soon as I have it.
Building upon the proposal from @joepavitt:
I thought we could bring back the levels in the sidebar. In the overview, since there are different sections, I added a chevron and made these sub-sections an accordion, so everything is not visible at once, which can be overwhelming in such a small space. I also added a visual cue next to the expanded list, so it's easier to see the beginning and the end of it.
For devices, I'm not displaying all the info, just a basic list of devices and status. I added a link to /instance/devices for more details.
And settings would take you to /settings/general.
So, there would be more than one link to the instance overview with all the tabs. This means that a user could click on one instance on the list /team/instances and go straight to the editor.
Here's an interactive prototype. It's not perfect, and only the overview, devices, and settings are interactive. I just wanted to share it as soon as possible to get feedback and check if you think this is the right approach.
My concern here is the amount of screen real estate lost from the Node-RED Editor to that sidebar now, given that 98% of the work a user will do on this screen, is in the editor
That sidebar would be collapsed by default and only expanded if the user clicks on one of the list items. Clicking again on the same icon collapses it back, so it will only be taking space when the user is using it.
Maybe we could hide it entirely? and leave only a small button to expand it again? Something like this:
Default:
Collapsed:
The challenge we have to consider is from a structural perspective too when building this out. The Node_RED Editor and top navigation bar will be inside an <iframe />, so we need a single line cut off with the designs.
We could circumvent this a little by having a relative positioned sidebar with the icons, lined up to the FF icon top-left (which would render at the FF-level). Then, on hover (or with expand button to be clicked) expand the menu options as you've shared? That expanded content would then be absolute positioned above the Editor, rather than squashing the whole editor in the x-axis?
I see your point, and I think that could work. Interacting with the sidebar options shouldn't have a visual impact on the editor, correct? Users wouldn't expect clicking on something in that bar to immediately reflect a change in the editor, so it should be fine if it's covered up momentarily.
Interacting with the sidebar options shouldn't have a visual impact on the editor, correct?
Not necessarily, but we need to have it be useful. If I want to see Snapshots, or create a snapshot, I should have easy access to do so. Similarly for the underlying Node-RED Logs (see the floating Logs approach above).
Maybe our approach here isn't a side navigation menu, but in fact a "quick view" of each of the tabs, e.g. a small window opens on hover (or click) which gives me quick FF-based actions and information?
Sorry for the branch in the conversation, but if I click an option in the menu does it ask me to deploy first to persist the changes?
Ninja edit: I assume that real time editing would resolve this as it must save all changes for users.
but if I click an option in the menu does it ask me to deploy first to persist the changes?
I think we should toy with the idea of not navigating away at all at the moment, and offer a "small" view of those tabs so you can stay in the context of the Editor, whilst also getting FF value. If you're navigated away, then there is no value in having a nested Editor.
Ninja edit: I assume that real time editing would resolve this as it must save all changes for users.
That'll be for @knolleary to work out
For me, it is currently hard to imagine how this design, with the navigation as a sidebar, can be integrated into the current structure where the navigation bar is at the top. Switching the navigation bar's positioning feels weird to me at the moment, but maybe I am missing something.
You'd almost want to think about immersive the other way around. How can we make NR more FF oriented.
What a user wants to do
- Create snapshots
- Access the logs (STDOUT STdERR)
- Theming (seems broken in demos lately)
- ...?
Is there a way to make FlowFuse a first class citizen?
Note: I still believe embedding NodeRED into FF is a better move as it's easier to maintain and be Node-RED version independent.
What a user wants to do
- Create snapshots
- Access the logs (STDOUT STdERR)
- Theming (seems broken in demos lately)
- ...?
my points here exactly.
Sorry @joepavitt , didn't mean to pass it off as my idea. It wasn't clear to me in your linked note where the integration would live.
It wasn't clear to me in your linked note where the integration would live.
No problem at all. My proposal would be as per @Yndira-E's layout and idea of having the information to hand, but rather than the options being in a nested sidebar, they float in small windows above the editor, pinned to the sidebar by default, but could then be floating windows as per here.
An example of the "Snapshots" view for example:
Structurally, everything in red here would be the iframe, everything else would live at the FF-level.
I'd probably even change the FF logo to be an explicit "<-" back button, and keep the logo next to the "Development" text as we have it at the moment, within the NR Editor.
Ninja edit: I assume that real time editing would resolve this as it must save all changes for users.
My current thinking (but is open to discussion once I have a design proposal in https://github.com/FlowFuse/node-red/issues/7) is that real-time editing does not mean the flows are constantly being saved in the runtime - it means other user's changes are shown in real-time within your editor. The deploy button still needs to be clicked by someone in order to save and deploy those changes. This is where the Google Docs analogy breaks down - we aren't making changes to the running flows in real-time.
As this comment is off-topic of this issue, I will post it then hide it - we can follow up in the linked issue once we have a firmer proposal in place.
Considering @MarianRaphael's comment:
For me, it is currently hard to imagine how this design, with the navigation as a sidebar, can be integrated into the current structure where the navigation bar is at the top. Switching the navigation bar's positioning feels weird to me at the moment, but maybe I am missing something.
Would something like this be too much?
- It would offer the same view in the same position as in the platform, and same options.
- It would be above editor (like Joe suggested).
- It should be scrollable and there's a "drag button" at the top of it, so it can be expanded as much as needed.
- It can be hidden entirely, leaving a button to open it again at the bottom, next to the search icon:
Would something like this be too much?
I like the idea. This would also be a fairly small iteration for features like Snapshots available in the editor.@joepavitt what do you think?
(a) Not sure we have access to modifying that part of the NR Editor without a plugin (cc @Steve-Mcl )
(b) What does this then offer that wouldn't already be available in the NR Tools Plugin sidebar, where you can create Snapshots?
(c) I don't think that's obvious enough for a user to see, so even if we added it, I don't think users would actually utilise it?
(a) Not sure we have access to modifying that part of the NR Editor without a plugin (cc @Steve-Mcl ) (c) I don't think that's obvious enough for a user to see, so even if we added it, I don't think users would actually utilise it?
@joepavitt the UX/UI isn't entirely figured out, I'm sorry I didn't mention that. I was just presenting the general idea and checking if it was welcome, didn't want to spend too much time working on it if it wasn't.
It could work in the same way as the editor's right sidebar:
- It's expanded by default (maybe only the first time in our case? So the user becomes aware of its existence)
- You can drag the left side of the bar to enlarge it
- You can also hide it entirely
And when it's hidden:
- There's a button that appears when hovering the right side of the viewport to bring it back.
That space is already taken up by the Node-RED "tray" that opens when you double click any nodes to edit them.
We ideally constrain this to the borders of editor.
I recommend considering UX-first, it's better practice for Product Design to focus on UX, even if block diagram layouts, then worry about the aesthetics after.