You should consider adding groups to pages. Such a feature has at least two uses:
1) The ability to group pages makes it possible to create virtual “sub-routines” within actions.
For example, one can create groups to handle specific sets of actions in the prototype. For example, assign pages 5-8 to the ‘Animation’ group.
2) Grouping pages will allow for larger, more complex plots since grouping will allow the user to better organize pages. For example, specific ranges of pages can be give unique names, which will make it possible to split up plots into distinct sections that cover specific sets of interaction.
For example: pages 1-5 might be the ‘Login’ group and pages 10-15 might be the ‘Error Handling’ group.
If implemented, grouped pages would appear in a tree like structure where they can be expanded or collapsed as needed.
Does this make sense?
Thanks for the suggestion 🙂
True it is not a real grouping and you can not expand / collapse the group, but it can make a clear view of the structure.
I think the real lacking feature is the ability to create “sub-routines”. Now we can handle the event generated on element, and jump to another page (for example, the first page for animation), but the animation can not run automatically, we still need to switch pages in the event handler, that will make the behavior become complex.
If we provide the “onLoaded” event for pages, the first page of animation can handle this event and start playing the animation (switching pages for interval).
So I think the “onLoaded” event for page is more useful at this phase, thoughts?
That makes sense to me.
The page event handling mechanism and the “Page Loaded” event are provided in V1.45
This question is now closed