Rethinking the Auth panel

[alexiglesias93]

Update

After your great comments, I've drafted a new iteration in this comment, where we combine the proposed Events panel into the existing Actions panel.

The context

Currently the Auth panel in the Wized Configurator has two purposes:

1. Creating Access Controls for the site's pages.
2. Displaying some pre-made authentication requests for users to implement.

The most important functionality out of the two is nº 1: creating Access Controls as it allows users to protect pages based on their own conditions (user hasn't logged in, user is not an admin, etc...).
The second functionality, the premade requests, is just some helpers that advanced users don't seem to use much, once you get the drill of how requests work in Wized you can build them yourself in a matter of seconds.

We'll talk about the premade requests later, first I want to focus on rethinking Access Controls.

In Embed 1.0 users can create them by:

• Selecting an Attribute as the trigger. Only pages with that Attribute will run this Access Control.
• Defining a condition. Only when the condition returns true the users are allowed to stay on the page.
• Defining a fallback page. When users are not allowed to access a page they are redirected to the fallback.

In Embed 2.0 we decided to enhance Access Controls with a new Variable condition trigger, which works very similar to the Variable condition trigger for requests:
Users define a custom Condition function. This Condition function is evaluated when the page starts loading and then is re-evaluated any time that its dependencies change.

This has one big benefit: as opposite to the Attribute present trigger, with Variable condition we don't need to wait until the DOMContentLoaded event has fired to check if the Attribute is in the current page. Instead, we can just run the Condition function as soon as possible which greatly improves speed and UX.

The idea

Ok great, so far this seems to be a nice improvement. But I think we can do even better. I think we have the chance to improve the platform even more with just a few tweaks.

If we take a step back and analyze what Access Controls actually are, you'll realize they are just callbacks that run under a specific condition:

When this happens (attribute is present or condition is met), perform this action (redirect the user).

Which is just a fancy way of describing how Events work in JavaScript.

So this got me wondering, why don't we just expand this and allow users to do anything after an Event, not just redirect the user.

We already support events to trigger element-specific Actions (On click, On change, etc...) and events to trigger Requests.
What we don't support is global events, not entirely at least. Access Controls partially implements it, but by removing some constraints we could allow users to do much, much more:

• When this condition is met, run this custom function.
• When page starts loading, run this custom function.
• When page finishes loading, run this custom function.
• When this condition is met, set this cookie.
• When this condition is met, update this variable.
• When this condition is met, redirect the user.
• When this condition is met, perform this request.
• Etc...

Essentially:

When this happens, do that.

The proposal

I propose repurposing the Auth panel into a new Events panel (or any similar name).
It would work very similar to the other panels: users could create/update/delete Events, sort them and classify them into folders:

(This is just some quick UI draft)

The amount of available events and actions could be expanded over time, always trying to find a balance between giving more flexibility to the user while not overwhelming them with too much options.

The downsides

I can think of two immediate downsides:

1. More technical concepts to teach to users. The more flexible and extensible we make the platform, the more we might be increasing the learning curve.
   With Access Controls it is pretty straightforward to implement a gated page.
   With Events, we might have to teach users about the concept and how to make the most out of it.

2. Multiple ways of doing the same thing. Requests can already be dynamically triggered when a condition is met. With Events, you'd also be able to the same. Is this a bad thing or a good thing? I am not sure, honestly.

What else? I'm sure we can be picky.

What about the premade auth requests?

Let's not forget that in the current Auth panel users can access premade auth requests like "Login user" and "Logout user":

I think that we can find a different place where to put those. Or maybe even get rid of them if we find out users don't use them at all.
One potential place to locate them is inside the Requests panel.

While creating a new Request, the Request Summary panel is completely empty until the Request is successfully created and saved:

I think we could use that empty space to display pre-made requests and other suggestions.

[theflowagency]

Another thing to think about is how Events would be thought about as different to Actions in a regular user's mind. Since Events would be "if this, then that" the second part is usually considered to be the action especially when you compare to NoCode tools like Zapier. Does this then require further thought as to what an Action is too I wonder? Either way, I think it is very important to not confuse the user by making it very clear what those differences are.

In terms of whether introducing the concept of Events is a good idea or not for Wized's audience, my personal opinion is that it will work as long as the UI/UX is simple and the lessons around their use are clear and accessible. I always defer to Webflow University at this point to make my point as many people approach Webflow with fear as the tools and panels can be intimidating but once the new user has done a few videos from the university, that fear starts to subside. I think Wized is doing a similar thing to Webflow here and that is to help people to utilise the true power of code without (too much) coding so to this end, perhaps Wized should not shy away from the features that will make it the powerful tool we all need it to be just like Webflow "went for it" by covering a huge amount of HTML and CSS in its features.

The difference is that we are moving into the territory of LowCode with this move in Wized which isn't a bad thing, but it needs to be done with the NoCoder AND Web Designer in mind. Your idea of premade requests (and premade events even) would be a big tick in the box on this point i.e. writing a piece of code, however small, from scratch is going to feel 10x harder than using a snippet that you can adapt. Having a library of the most common requests & events would not only speed things up but would help with alleviating any cognitive load for the user whereby creating code from scratch is not in their comfort zone.

I wonder if even having the scaffold in the premade requests would suffice? You mention these, for example, and each could be a starting point in which the user fills-in the dynamic values:

• When this condition is met, run this custom function.
• When page starts loading, run this custom function.
• When page finishes loading, run this custom function.
• When this condition is met, set this cookie.
• When this condition is met, update this variable.
• When this condition is met, redirect the user.
• When this condition is met, perform this request.

Not to be silly but add an AI assistant to the mix and the user + AI could create these requests and events easily together!

Those are my immediate thoughts. I hope they make sense!

[wadecreative]

My first thought is that while no-code users don't understand programming in a lexical sense, they can be just as capable at understanding concepts of logic with the right educational resources at their disposal and we should always assume that they're capable. I think these are great ideas. As a more technically minded designer, I haven't used Wized much because of its restrictions like these.

I do wonder if something along the lines of a snippet library like Xano has could a) be a solution for concerns about widening the learning field too far and b) a great way to put some effort and work into the hands of the community that love the product.

And lastly, the UI could really lend a hand in user comprehension if it had some visual indicators and tools to help - think flow charts that help hem to build the request that essentially represents the flow of data from action to action. That's a low-level example, but if I were a new user looking at only a narrow panel of words that I don't yet quite understand, I might turn tail and run to something that I, as maybe a visual learning, could understand more easily.

Hope this helps!

[FerdiBoxman]

Firstly, I believe that this idea of RFCs is truly excellent, as it allows Wized users to be more engaged in the thought process of where the product is heading. The primary objective is to deliver the utmost value to users. Also, i think doing one-on-one interviews with beginners, intermediates, and professional Wized developers could also be a good idea. This can also serve as a test to determine if, for instance, the first downside is too technical (this, of course, would be a consideration for a later stage).

This could also be a Friday technical stream. An open call to discuss these kind of stuff. I think together we can give you some fresh and clear ideas. You are weeks/months in the development of this, maybe this helps to zoom out sometimes and see it form other perspectives. (I don't know if this is the case/needed but it is just an honest thought).

Personally, I don't think you need to restrict the product's capabilities for the sake of simplicity (downside 1). At times, it may be challenging for novices or even for those attempting to teach others. However, web app development is generally not an "easy" endeavor.

I'm strongly in favor of the idea of incorporating Events, as it provides us with significantly increased flexibility. Currently, we can initiate requests when a condition is met, but why not extend this ability to perform actions when conditions are met? It might be worthwhile to explore the actions tab. At present, we can only select attributes. Imagine if we could also choose variables in the actions tab, and execute the action if a specific condition is met. Combining Actions and Events to offer more flexibility in the actions tab seems like a fantastic idea, enabling more operations when conditions are met.

So no events tab, only an actions tab. This will already make it a lot easier to understand for beginner users.

Perhaps it would be beneficial to establish separate technical levels, such as a lite version and a pro version (this, of course, would be for later), as seen in numerous other tools. When people onboard, they could select their technical level, and the product could be adjusted to fit their technical abilities. The pro version would have no limits, could participate in beta testing, wouldn't have pre-made components, and wouldn't display tutorial videos in their UI. On the contrary, the lite version would offer exactly the opposite of this, catering to those who are still developing their skills.

Would love to hear your thoughts and other people's thoughts on combining Events and Actions in to one Action tab.

[alexiglesias93]

@theflowagency @wadecreative @FerdiBoxman
You have really great points, thank you very much for taking the time to share your thoughts!

After your comments, I think that the idea to combine this Events panel idea together with the Action panel makes total sense.
After all, we are performing Actions. Some are applied to elements, some are applied to events/conditions, but they all are the same, Actions.

With a simple additional Action Type dropdown we could distinguish between Actions that are applied to Elements, and actions that are triggered based on Events:

Element action:

Event action:

How do you feel about this?

[benoiteveillard]

Great conversation!! Here are my thoughts on that one :

1. Variables and Cookies
   On the left panel, I would remove the auth panel (as it is an action) and put a new one (called Environment, Config or Global Data for example) that would include :

• Variables
• Cookies
• URL Parameters

Those are keys concepts but a bit hidden for now I think.

2. Data in & Data Out
   I would factorize this one to call it requests (as you did on your screen).
   I would also :

• remove the trigger thing from the request panel. I think it is confusing to be able to trigger request directly from the request but also from the actions.
• move the after request into the Events panel also

3. Actions
   I would rename Actions in "Events".

4. Triggers
   Now it is a bit confusing because we can trigger something from the requests panel and the actions panel.

But here I would define a trigger type like :

• on page load
• on click
• on change
• etc...

And then choose the attribute of that trigger.

So the workflow would be :

1. I define the trigger (e.g. on click on button with attribute abcd_)
2. I define a new event based on a trigger (or several with and/or)
3. I define the after action

Example :

1. I create a new event called "Render List"
2. I create the trigger called "Page /test Load"
3. I create the action to (e.g. render list)
4. I defined the after action

Like this :

A lot of things on my message, hope it's clear

[FerdiBoxman]

The first point (1) is already under Page Data, so no need to add an extra tab.

Point (3), why would you name this "Events", i think "Action" is way better. For example, a data in or data out could also be seen as an Event.

[benoiteveillard]

(1) My opinion is that they are too hidden right now especially when you have 2 or 3 requests running

(3) True! It is just a naming suggestion because I think Actions is not the best one either :)

[FerdiBoxman]

Yes now you mentioned it again it makes a lot of sense. The cookies, variables, paths and paramaters are indeed too hidden below all the requests in page data.

Maybe it is an idea to move cookies, variables, paths and parameters above all the requests in page data. And that you can only VIEW the current value of for example the variable or cookie in Page Data. And that we have indeed another tab called "Environment" were we can CREATE/EDIT/DELETE all the vars, cookies and parameters.

[alexiglesias93]

Great insights, thank you all!
FYI, moving the General page data up to the first position is an update that we have already made, it's prepared to be deployed to production very soon:

[Manki32]

This was a great conversation, and I love the input from all of you!

Since we added events to the Actions panel, should we also remove actions from the Request panel?

The After Request panel and the Trigger panel could be moved to Actions instead. We would just have to display these linked Actions in the Overview panel flow:

This way, all Actions would live in one place only. There wouldn't be two ways of doing the same thing.

What do you think?

[FerdiBoxman]

To keep things simple and organized this is a great idea. Would be useful that if you clicked in the overview on a linked Action, that you directly go to that action in de Action tab.

@Manki32 @alexiglesias93

[FerdiBoxman]

Today, I was working with the Webflow CMS, applying 'wized' attributes to each CMS item, each with a dynamic value originating from the CMS itself. The values would typically follow this pattern:

For example,

wized="cars_car1"
wized="cars_car2"
wized="cars_car3"
wized="cars_car4"

... and so on.

After setting these attributes, I would then manually add all the attributes to Wized. However, this process becomes quite tedious as my clients add more content to the CMS, because this means that I have to go back to Wized and add more attributes to the triggers.

It occurred to me that it would be quite beneficial to enhance the event trigger system, especially the trigger type related to attributes, by introducing "Attribute Logic".

Right now, we have to manually add each attribute. But, what if we could introduce some logic that could automate this task?

The logic could be based on a rule such as: Trigger an event for every attribute that contains, starts with, or ends with a specific value.

For instance, attribute.startsWith("cars_") would trigger an event for any attribute that starts with "cars_". This enhancement could significantly streamline the process, making it much less labor-intensive than the current manual method.

@Manki32 @alexiglesias93

[Manki32]

I'm curious to hear why you need a unique attribute on each item. Could you explain your use case? Are you applying the same action or does each one of those cms items have a unique action?

[FerdiBoxman]

It was actually for checkboxes. Now when you have checkboxes, you need to set a different attribute value for each checkbox to get the value (maybe this is fixed with the new form update).

I have these checkboxes connected to the CMS for clients to add more in the future. (See image)

Maybe its not needed and im thinking to complex. But i can see use cases that you want to do different logic for different items (or groups of items with the same tag/category) in the CMS.

[alexiglesias93]

@FerdiBoxman in Embed 2.0 we have a new f in the DataStore that stores all the inputs from forms after a form submission.
The data looks like this:

f.your_form_name = {
  checkbox_1: true,
  checkbox_2: true,
  checkbox_3: false,
  input_1: "my input value",
  // ...
}

Where each input is included using the name of the input.

I believe this will solve your use case.

[alexiglesias93]

Hello all!
After some more exploring I think I've found a very nice way of implementing this that unifies how all types of actions are implemented in a site.
Please, take a few minutes to watch this Loom video and share your feedback!
https://www.loom.com/share/a836af3516924163b6fd5cd2be2e6643?sid=2e09f62e-89c9-4386-bee1-b3fc8c36b3ca

[Manki32]

Yes, this is great! I really like this approach.

I think removing the Trigger section, and the After Request section from the request panel makes a lot of sense.

It will be much easier for developers to understand what's triggering a request since the trigger can only live in one place; the Actions panel.

[FerdiBoxman]

Yes one place for all actions! A lot more overview and simplicity.

Idea to even simplify it more: If an user wants to trigger something after a request, let them also select the request.

Action panel --> Action: After request --> Choose requests (can be multiple) ---> configure

Via this way, I think you can also easily add the trigger to the overview information. Other solution for this would be: if request is mentioned in code editor -> add to overview.

[alexiglesias93]

Closing this as it was already shipped.