I would love the ability to give some of my triggers a name or a custom label, much like you can name a layer. It should be an optional thing, since I don’t want to name ‘every’ trigger.
This would be particularly helpful when XP’s become complex with lots of conditional logic. Sometimes I’ll have a very large list of conditional triggers and it’s a real pain to click through each one and examine the triggers to determine the one I need to edit. Programmers can do this with comments in their code…we can’t really do this in Intuiface.
If I could name the trigger, or even have a little text on-hover, that’d be great. For example, I’d use it to label which triggers are Day 1 pass, Day 1 fail, Submit info IF xxx, Submit info If yyy.
It would certainly save a lot of time! Anyone else agree?
I agree with you, although on the experiences I have been working on (which are not always “real-life XPs” like yours), if I’m in a situation where I need to do X times the same thing (similar scene content, similar action, similar trigger, …), X depending on the complexity of the “thing” and the available time I have to work on that XP, I try to:
See if X is small enough that I should go with the “manual” method and duplicate my “thing” (scene, trigger, action…). X = 2 or 3, then I’m ok without notes to see which does what, using the trigger&action panel is fast enough to toggle between this triggers, for example.
See if X is large enough (3+), or if I don’t know how big it can grow (based on customer new inputs), and if I should try to make that mechanism more generic and work with a real X value, using Excel, H-CMS, Global variables or any other Interface Asset (even a custom coded one if needed, like for the Memory-game). Then I have only 1 “thing” and no need for notes.
It’s not always possible to make this generic, or sometimes it “costs” too much (over-engineering) and it’s not worth it.
It’s also a very programmatic approach, not a designer one, that was engraved by one of my teachers:
“If you have more than one else in your if statement, you’re doing it wrong”
For the mode designer approach, having notes / labels / comments fields would definitely help, so +1 from me too on this suggestion
But without thinking too much into it, it’s just a label to help identify my triggers
Some types of experiences are data driven or logic-based and therefore can require a lot of conditions.
Also consider that composer can slow down in these instances too, and I’ve seen 5+ seconds go by with a very strong pc before the action menu opens. Multiple that by hundreds of iterations and there’s a lot of time/frustration.
The label doesn’t need to be anything too complex. Even the design accelerators have a little notes field that shows hover text.
Alex, that’s actually exactly my point: the more the experience is “data-driven” or “logic-based”, the less “manual” conditions it should have, the less triggers it should have, the less “if then else if, else if, else if, else” it should have, to avoid having this performance issue in Composer, or just this complexity.
Let me take an example
A non-interactive QSR Menu board needs to change scene based on time of the day. The scheduling can be changed by the Composer user, and the original specs of the XP were:
It works, but it’s tedious to set and maintain, and indeed need to go over all triggers to find the right one if you need to edit it. I’d love to have labels in this case!
Second approach: data driven.
Using an Excel sheet (or H-CMS, Airtable, Knack, …)
On the same button, filter the Excel based on clock time to get “the proper scene” to navigate to, and bing the go to scene action on that filter result
Hey Seb, thanks for the example. I’ve built menu schedulers before and agree with you 100%.
But showing a single method of data triggers, in my humble opinion, doesn’t negate the idea that labels for triggers can be very helpful.
I’ve recorded a video for you to show you what I’m talking about. In these examples, using filtering doesn’t apply to the scenario. Conditional logic is needed.
Hey @Seb ,
I’m trying to think of another feature that could accomplish this and more. What if you could “Group” actions? Therefore, you could name the group with a label, set a delay for the whole group, and move it up/down the list as a single unit…and even duplicate the entire group.
This way, complex sets of actions can be organized nicely, labeled for their function, and moved as a single unit.
Ok, I guess I’ll throw in the towel on this idea. I’ll do my best to find another solution for this situation, it’s probably not that common to be honest anyways. Thanks for you assistance!
Thanks!
FYI, after looking again at this, I suppose the Label text input box could go below, or near the Trigger item at the top left. It’s a little easier to see up there.
Since I have a short memory, I like to bind my triggers to buttons when possible. I then label the button to reminder what it is about. I did mention, only where and when possible.
This is a customer experience so unfortunately, I can’t share it here.
It’s quite similar to our QSR Menu Board, based on Airtable (created quite before we released H-CMS), but uses a Scheduler to regularly “simulate a tap” on a button to check these conditions. The customer actually used the 1st approach with conditional triggers.
Thanks for the vote, I appreciate it. Though this thread seemed to have gotten off the rails a little bit, I understand it may be a little hard to see what I’m getting at.
I use buttons to label my triggers all the time; if you were to re-watch my video you will see this is not a solution for many scenarios, especially involving conditional triggers. For instance, separate buttons is not a solution for conditional actions based on 1) data coming in from an API and 2) When conditional logic is needed for things like quizzes, survey’s, matching, etc. Again, see my video.
My screenshot illustrates a simple hover-label that can make all of our lives easier. I didn’t think I was asking for so much lol.
Not only will my solution make conditional logic 10x’s easier for anyone to follow, even if they didn’t design the XP, it will also help designers like me tell a story with all their actions without needing to OPEN.EVERY.SINGLE.ACTION.MENU.
