Scenario Toolbar Descriptions

Hey Makers! :wave:

I’m Ella, and I work as a Product Documentation Manager at Make. My team and I are on a mission to make our tools, such as Flow Control, Tools, and Text Parser, more user-friendly. We have brainstormed new names and descriptions that could make it easier for you to understand and use them. But before finalizing any changes, we would like to hear from you! Do you think our options help clarify how the tools work?

Feel free to vote for your favorite options or share your own descriptions in the comments.

Iterator

  • a. Splits a list of items (an array) into separate bundles that can be processed one by one.
  • b. Splits an array into separate bundles that can be processed one at a time.
  • c. Splits an array into separate bundles.
0 voters

Commit

  • a. Stops the scenario and commits changes where possible. Next modules are not run.
  • b. Stops scenario and commits changes. Subsequent modules are not run.
0 voters

Increment Function > Bundle counter

  • a. Counts bundles from the previous module. Increases the count by 1 with each scenario run.
  • b. Returns 1 after the very first run. Then increments value each execution. Resets count according to its configuration.
0 voters

Thank you so much for your help! :star2:

2 Likes

@EllaD – I’m not sure the Iterator descriptions are that great unfortunately.

A few notes:

Iterators can work not just arrays but also collections (surprisingly enough). They don’t split a collection of course unless you wrap it in a toArray() function in which case they become arrays.

Iterators must execute all subsequent modules the number of bundles generated.

So a better description could be

Converts an array into bundles and creates a loop processing each bundle as input to any subsequent module(s)

For commit, since it is an error handler it should be described as such. And the commit part is related to use of ACID/database apps like MySQL or the Data Store.

A better description could be:

An error handler that will stop a scenario when an error is encountered, complete and save changes made by any apps that use a database like Data Store or MySQL

1 Like

@alex.newpath – Thank you for sharing your ideas on how to improve the descriptions. It’s definitely something I’d like to bring up with the Team.

1 Like

That’s great to hear. It really is difficult sometimes to describe a complex tool in Make. It’s probably easier to describe the Set Variable or Set Multiple Variables module, but things like iterators and routers are really hard to describe in one short succinct sentence where every single word and the order of the words matter (alot).

1 Like

@alex.newpath Yeah, it’s definitely a challenge, which is why we’re reaching out to our awesome Make Community for help. We have to keep in mind the limitations of the user interface - the description can’t be too long or too technical. We want to make sure every user, even those without much experience, can understand the purpose of the tool.

And since you mentioned Set Variable or Set Multiple Variables, I’m curious how you would describe it? :slight_smile:

1 Like

Oh you are looking for phrases in the User Interface to use? Honestly I think a phrase of any length is too long. Iterator is good enough in the UI. I would focus on leaving phrases out of the UI and rather create useful context sensitive help that can readily be popped up that brings up the appropriate help doc which can provide examples and the like.

The approach taken with the hovers on the Make functions work reasonably well although sometimes they are too short and sometimes factually not totally correct or accurate.

As for Set Variable I would describe it as

“A module which creates a reusable piece of data which can be referenced by name in a scenario”

and Set Multiple Variables

“A module which creates multiple reusable pieces of data which can be referenced by name in a scenario”

I think consisent use of Make terminology should not be avoided at all – apps, modules, paths, filters, module configuration etc should all be used widely and consistently. I think they are all in the Glossary. Although I think the connection between modules is not defined there (route I think is the best name!)

1 Like

@alex.newpath Yes, as of now, the first step is to find short, good descriptions to use in the UI. And of course, updating the Glossary is something that we are doing along the way. So, all of your suggestions will be considered and not wasted :slight_smile:

We’re using context sensitive help in certain areas of the product and we’re looking into how we can use it more effectively. I really appreciate your descriptions for Set Variable(s) - they’re helpful. I think we could simplify it to say: “Creates a single variable with a set value” and “Creates multiple variables with set values.” I’ll discuss this with the team to figure out the best option. Thanks for your input!