"No Condition" as a type of Screen/Trigger Condition

[vibhor1102]

As we know, if an event has No Condition, it's subject to being repeatedly triggering, and if a typical user is accidentally able to save scenarios that way, that's going to lead to frustrating user experience.

However, certain advanced users would appreciate having events without conditions, when they already control the flow tightly via enabling/disabling events, use counters for incrementing, reloading of events, etc. And, this suggestion aims to satisfy their use cases, while keeping the condition-less events gated from any typical users.

The core idea

The "You need to add a screen condition to be able to save an event" restriction stays in place. However, a new condition type along with the current four would be provided called "No Condition". It will be a 5th option to the choice of condition. Similarly, there'll be one shown within triggers' conditions as well. It satisfies the "You need to add a screen condition to be able to save event" rule.

A few minor design decisions:

• if a user adds any other condition, the "No Condition" automatically gets removed (and their newly selected condition gets added).

User-Gating mechanisms

Even though the user has to deliberately select the "No Condition" option out of conditions menu, i propose more restrictions in place to help the user prevent accidental events creation by uninformed users that may loop around aggressively. I suggest 2 different approaches below:

1. The settings-gated model

There will be a new setting within the global settings page of Klick'r where users need to enable events with "No Condition". From that point onwards, users can select "No Condition" as a condition type within events/triggers.

Drawbacks:

• A little harder to discover for users on their own
• Even after enabling it, some users may not understand the risks of No Condition events and may create looping scenarios and run looping events.

2. The dynamic checker model

When selecting a "No Condition", a special type of checks gets enabled in the backend of the app. Those sets of checks occur at the time of saving the event/trigger. The checks are primarily for the fact that the event with no condition is handled neatly or not. It can involve multiple checks: (any one satisfied is sufficient)

• whether the event/trigger with no condition later disables itself through state toggle
• whether it has reloading enabled with minimum 1 second of delay
• whether it increments a counter that's monitored by a trigger event which disables the "no condition" event upon hitting certain level. however, this one is much harder to enforce or detect because of dependence on external events.

If a "no condition" event/trigger is found to be "unsafe" as per these conditions, a warning is shown to the user and (optionally, depends upon implementation), he can be prevented from saving such event/scenario.

Drawbacks:

• harder to implement
• more brittle for the user as app tries to determine what's safe and what is not, which can be both restrictive to power users and still allow edge cases of looping for typical users.

3. Hybrid approach

Elements of both 1. and 2. can be chosen together and mixed to implement a more practical solution. Plus, other ideas like warning before saving can be optionally added in 1. and 2. and within the settings model, a popup/dialog showing users a small quick-guide and risks of the "No Condition" can be shown. Creativity has no limits.

One side note to add in case of either approach

There should be a secondary thing implemented, that whenever a phone's screen is turned off and then turns back on, the overlay and loaded scenario should be right there, but scenario should not start running instantly. instead, it should load back in paused state, regardless of whether it was running beforehand or not. This allows users to turn off screen to pause scenario, in case a click action is triggering 1000 times per second and preventing them from tapping the pause button to pause their scenario while running (totally possible).

[vibhor1102]

Restored back after a month of invisibility as my account was false-positively flagged