EB GUIDE 6.7—View transition animations
Sabrina Kerzel is one of our UI/UX experts.
How often have you tried to model a fancy animation when a specific view is entered? Or do you even have to model a certain animation on view change, when a pop up appears, etc.?
We can think of dozens of use cases, where you need a feature that gives you the freedom to create transition animations exactly how you need them.
Well, with the previous version it was possible to model simple transition animations, restricted to a view template. But are simple transition animations on a view template enough?
We, the EB GUIDE team, do not think that this is sufficient. Therefore, we are glad to present our new enhanced view transition animations!
EB GUIDE 6.6 throwback
Back in the days, transition animations were added in the properties panel of a view template. To add a transition animation, check the required animation type in the transitions category. Entry animations and exit animations, which are the provided animation types, both come with a few properties and a set of pre-defined transition types.
One example of an exit animation is Move out to top. This transition animation basically animates the y property of your view template as a whole to be moved out to top. You do not have any access on actual widget properties that are located in your view template. It works, but it is not really customizable.
What about unique transition animations that should only be played on a single view? Or just think about animations that should only be played under certain conditions?
Unfortunately, you needed to create one-view template for every transition animation that differed from the standard behavior of your HMI.
First things first. We wanted to provide a holistic feature that is not restricted to view templates anymore. The new concept enables you to create view transition animations (abbr. VTAs) wherever you need them and how many you need and want. This means that we extended this feature to be applied to views as well.
In doing so, we came to the conclusion that the properties panel is not the right place to define VTAs any longer. That is why we have moved the VTAs from the properties panel to its own component.
Let me introduce the VTA component:
The VTA component is context-dependent, meaning that it follows your selected view to show only relevant VTAs, just like the properties panel does.
The VTA component displays all VTAs that are added to the respective view or view template in up to five categories. To prevent the component from being overloaded, a VTA category is only visible if it contains at least one VTA of its type.
Adding a VTA is as easy as adding a data pool. Just hit the + button and select the available type of VTA you need.
You might have recognized that there are up to five different available VTA types:
- Entry animation: played when the view state (the animation is added to) is entered
- Exit animation: played when the view state (the animation is added to) is exited
- Change animation: played on view state change
- Pop-up on animation: played when respective dynamic state machine is activated (push dynamic state machine)
- Pop-up off animation: played when respective dynamic state machine is exited (pop dynamic state machine)
The variety depends on the VTA target. The full set of VTAs is available for view templates and views located in a dynamic state machine. Available VTAs for views in a non-dynamic state machine are entry, exit, and change animation.
Customizable, graphical, and full access
Creating several VTAs of a type at one particular view or view template seems great. But how to tell when to play the right VTA? We have looked back at EB GUIDE 5, where you can allocate conditions when a VTA should be played. Sometimes, old is gold.
That was exactly the feature we needed. You can now add a condition by simply right-click the VTA, select Add condition, and enter the function that defines when to play this VTA, in the script overlay.
Added conditions are displayed as button in the line of the VTA. A tooltip shows a preview of the added condition. Conditions can be edited by clicking the script button, and, of course, deleting the condition in the context menu.
Regarding the opportunity of adding several VTAs and conditions—let us talk about view templates and view template instances.
To keep the overview of the VTAs, even if the view is an instance of a view template, we wanted to provide you the information of inherited VTAs and conditions.
Inherited VTAs have a preview of added conditions, just like normal VTAs have—whereat they cannot be edited at template instance.
But to make it as comfortable for you, our users, as possible, we introduced a Jump to button, that instantly jumps to the respective template when clicked, where you can edit, e.g. the condition.
Let us make a short side trip to the visual part:
Of course, we wanted you to benefit from our graphical animation editor which was introduced with the last release.
So, we did the obvious and integrated the VTAs into our graphical animation editor.
When you add a VTA, the animation editor opens in the content area of the respective view or view template.
Another huge improvement is that you now can animate every property that is located in your view or every property that is published to your view template interface, all properties of the animation itself, and of course, all data pool items that can be animated.
Start modeling now!
As always, we are constantly looking for ways to improve the tool.
Also, do not forget to visit our Resources section to download examples, review tutorials, and read user documentation.
As always, get in touch with us if you have questions or feedback.