First, I want to say thank you to @MaxZieb because you’re taking the time to think and share what can be nice for Bricksforge, and this is something that all users we will take advantage (even those ones like me that have 0.001% of knowledge than you have).
Second, thank you to @Daniele to listen to us and do all the hard/dirty work.
And now my opinion about the topic…
Having something like that will put back a good reason to have interactions in Bricksforge. (I’m just thinking how funny can be to have interactions with the keyboard in certain website )
Even in terms of “marketing” you can use it like “bricks interactions on steroids” (this is only a concept).
And this is following pretty well the line that Bricksforge it’s having. I mean, Bricksforge it’s a plugin to expand possibilities.
Whoop! I like this a lot!
I was sad to see the potential that BF interactions disappear, but was unable to express exactly why, but this list is pretty much a comprehensive reason for them to stay
I don’t think this level of interaction will be opened to the native builder.
The event list above was mainly based on what the browser anyways offers (raw DOM events, compelling and nice). Also, above are some suggestions for Bricks specific JavaScript events for Slider sync and potential events covering built in elements.
But, wait there is even one more potential source for events (depended on GSAP being loaded, though). If it is loaded, there is this wide range of observers it offers… so even more events one could offer in the events panel!
Summary:
Rich callback system including onDown, onUp, onLeft, onRight, onDrag, onDragStart, onDragEnd, onHover, onHoverEnd, onToggleY, onToggleX, onChangeX, onChangeY, onChange, onClick, onPress, onRelease, onMove, onWheel, and onStop
Debounced by default for maximum performance (you can set debounce: false if you prefer)
Cross-browser compatible - automatically senses if TouchEvents, PointerEvents, or MouseEvents should be used.
Automatically prioritizes the event with the largest delta (like if a wheel and scroll and touch event all occur during the same debounced period)
Ignore certain elements, like ignore: ".deadzone"
Get velocity (on x and y axis separately) as well as the clientX and clientY coordinates (for touch/pointer events)
Set a minimum threshold for dragging. For example, dragMinimum: 5 would only fire the onDragStart/onDrag/onDragEnd callbacks if the user moved 5 pixels or more.
Set a tolerance so that the movement-related callbacks only fire when a minimum delta is reached, so tolerance: 50 would wait until there has been a change of at least 50 pixels, and then once that’s reached it starts over.
Set a wheelSpeed multiplier if you’d like to tweak the wheel-related deltas (speed them up or slow them down).
Sidenote for people concerned with performance: The neat thing is that all the suggested events are basically built into the browser, Bricks or GSAP and BricksForge would only need to “write” the trigger/glue code to make them work based on your specifications in the panel. Hence, it should be very little code that is generated on a per-page basis and no interpretation or “runtime” is needed to make it work that is not anyway already present.
Woaaaah! Great Input! I’m already working on implementations. And: to make the UI more clear for a big list of events / options, I’ve created a grouped select for a better overview. This will be exists for events, but for actions as well:
You are welcome, and I am just loving this product and … you are absolutely killing it!
I’ll be testing the hell out of this as soon as it hits our downloads.
Just brainstorming a bit… not sure about the buttons and colors, though.
Bottom half is a little variable/API lookup. It educated the user with a brief explanation and has links to the official manuals (little icon). It is populated by area differently. Showing variables that are accessible in any given context. Top title describes what the code is for. Window can be dragged and resized, and bottom viewer can be resized inside the modal as well. May rather us abort then close. Double-clicking on a work in the left lower viewer inserts the command into the code editor (inspired by Hype). Under the example text event (object) we can see a table, but it could be anything (text, code examples etc.).
Here is a version with a collapsed help viewer (only brainstorming here):
Wait a minute, I am currently on the road, but was thinking about the screenshot. I posted earlier on the left bottom part there should be the target object and underneath all the keys and each key gets a description with a link to the official documentation the same was should be done for other objects like event, I will correct the screenshot when I am back home. This should help newcomers learn and using the double click below even for seasoned programmers to insert objects that are available really really quick. Combine this with auto complete and it’s a killer feature.
Food for thought: The below viewer could be built from the same lookup as the autocomplete, reducing redundancy when creating and preparing the docs even further.
All the above would be very useful for me!
I’m making decent progress with my development skills, but I’ve never collaborated or finished a proper course, and generally like to just fiddle with stuff. Visual representations and examples built into this would be a huge help with that, Max
Daniele, the Ui is looking fantastic. I think you’ve massively improved upon the Bricks design system, and so far nothing has felt disorganised, or in need of guesswork.
Having conditions on events was introduced by Brick interactions, and I think it would make much sense to keep inline with that idea. There are the simple statement-based conditions, that would probally be rendered into an event scope: random example from a user: window.a == window.b
This returns true or false and will probably be part of the event callback and abort it if not true.
There are also events based on gsap.matchMedia and they use media query string… so that would be another great source for event conditions. These run the content and even have the ability to revert animations if not meet. Pretty powerful stuff if implemented correctly.
Even more events: Callback events!
There is a whole slew of further events. These are in a way special as they are mostly dependent on a prior action. Hence, in the case of timelines, they are consequences. For example, they can fire if a timeline starts and ends or progress. The can fire as the consequence of load an image or another action. Given the current interface it would be nice to have them also in the events panel. Hence, you create an new event “GSAP Timeline ends” and pick an existing timeline by name. But what happens if the timeline is deleted? You would need to unhook, disable or garbage collect if the item (like the timeline) they depend on is removed. “Unhooking” would be maybe a solution and rendered them inactive, but retain your settings.
Putting them inside the item and actions, on the other hand, would introduce a nested layer of complexity, but place them where they logically belong. It is an interesting problem to solve from a UI perspective.
Anybody have a solution or thoughts on this? I am just brainstorming here as it’s fun AND the callbacks events is another great source for events.
I don’t know if you have the time or inclination, but I think you’d make an absolute killing with courses.
Your posts here have (for me, at least) touched on complexities that I usually tend to put into the “let’s learn/investigate this later, but never really” bucket. But you’ve explained many of them well enough that I feel emboldened to try.
It’s clear you’re enthused by Bricksforge’s possibilities, so perhaps an enrollable course on the more complex stuff using Bricks and its Forge would provide some sort of recompense for your time.
It seems like a win-win-win for Bricksforge, you, and the people Bricksforge seems to be aimed at.
0.9.4 will include many of the mentioned events, including MutationObserver and ResizeObserver. Also I’ll introduce a conditional logic system for your event actions, with the additional possibility to create really custom conditions for more complex stuff:
)
