Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider renaming "Instances" to "Flows" #5284

Open
joepavitt opened this issue Mar 10, 2025 · 6 comments
Open

Consider renaming "Instances" to "Flows" #5284

joepavitt opened this issue Mar 10, 2025 · 6 comments
Labels
consideration A potential feature or improvement that is under review for possible development and implementation epic A significant feature or piece of work that doesn't easily fit into a single release

Comments

@joepavitt
Copy link
Contributor

Description

This is going to generate a lot of heat/discussion, but it comes from a good place...

In a call today with @MichaelBDavis and some prospects, there was regular confusion over "Instance" as a term, because it was used both in discussion of the number of FlowFuse Instances they wanted to spin up as well as the number of "Node-RED Instances" they wanted running in each.

We recently had feedback in @knolleary's webinar that the switch to Hosted/Remote terminology was a good one, and from the sales conversations I've seen that is also consistent feedback there too.

Michael and I discussed the option for "Flows" and it does fit nicely - "Hosted Flows" and "Remote Flows". It also helps bridge the gap for those less familiar with Node-RED, all they care about really is the flow-based interface.

Considering the views available for a given Instance, we have:

Image

All of these options make viable sense under the guise of a "Hosted Flow". Flows can still have multiple tabs (in the context of the NR Editor).

The main confusion could be around the term flow.json, but that is very niché/specific to those with Node-RED experience

Anyway, opening for consideration/discussion

Which customers would this be available to

None

@joepavitt joepavitt added epic A significant feature or piece of work that doesn't easily fit into a single release consideration A potential feature or improvement that is under review for possible development and implementation labels Mar 10, 2025
@knolleary
Copy link
Member

The main confusion could be around the term flow.json, but that is very niché/specific to those with Node-RED experience

I disagree here. The term 'flow' is already very well-established in Node-RED as how we refer to the individual tabs in the editor. It is also used to mean any single group of connected nodes. Each instance of Node-RED runs multiple flows. This would introduce a third possible meaning. At which point there's far more possibility for confusion.

the pipeline copies the flows from one flow to another flow.

I have two flows hosted in FlowFuse. One is made up of multiple flows and the other has a single flow

@hardillb
Copy link
Contributor

Flows is already too overloaded, this will only add to confustion

@joepavitt
Copy link
Contributor Author

What do you both propose as alternatives? Our customers are confused by the "Instances" terminology. "Runtimes" was also mentioned, but I feel like it's too technical.

As for the two statements you've shared Nick, I actually disagree with your terminology there, it's:

the pipeline copies the Snapshot from one flow to another flow.

I have two flows hosted in FlowFuse. One is made up of multiple tabs and the other has a single tab

@joepavitt
Copy link
Contributor Author

We need to consider the FlowFuse Experience, "Flow" in the context of a user of FlowFuse, makes sense. Node-RED is a tool by which we provide the low-code interface and you can build said flows.

I feel like we're risking harming the UX of FlowFuse for "protecting" something that is Node-RED specific.

@knolleary
Copy link
Member

At an abstract level, I can see merit in the proposal, but I think it is dismissing the fact the term 'flow' already has a well-established meaning within Node-RED a bit too readily.

Our ICP today is someone already familiar with Node-RED. 'Flow' is the terminology used through-out the editor to refer to the individual tabs. All documentation and online material will refer to flows in that way.

If we start saying our pricing is based on how many flows are managed by the platform, it is no longer clear that means Node-RED runtimes, rather than the flows within the runtime. To me, that feels like a much larger source of confusion.

Our customers are confused by the "Instances" terminology.

Do we have evidence of this beyond the one call you had? The recent feedback on the renaming of Devices to Remote Instances was positive - it didn't raise any flags over the term 'instance'.

because it was used both in discussion of the number of FlowFuse Instances they wanted to spin up as well as the number of "Node-RED Instances" they wanted running in each.

An alternative is to not use the term 'instance' when referring to the platform as a whole. "How many FlowFuse platforms they wanted to spin up, and how many instances they would want to run in each".

@joepavitt
Copy link
Contributor Author

Do we have evidence of this beyond the one call you had?

@MichaelBDavis mentioned this has been raised more than once in his sales calls.

Our ICP today is someone already familiar with Node-RED. 'Flow' is the terminology used through-out the editor to refer to the individual tabs. All documentation and online material will refer to flows in that way.

The challenge we have is scaling beyond those familiar with Node-RED. Yesterday, for example, the advocate was fine with it, but was trying to persuade a colleague of the value, and it just ended in confusion over the term "Instance".

When I spoke with the Electric car manufacturer a little while back, that was a similar experience over terminology (albeit, we;'ve since made the Device > Instance switch since then)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consideration A potential feature or improvement that is under review for possible development and implementation epic A significant feature or piece of work that doesn't easily fit into a single release
Projects
Status: No status
Development

No branches or pull requests

3 participants