This object defines the state the figure should be set to when this slide
is navigated to.
A slide definition has several callback properties that can be used to set
figure state including:
enterState: set an initial state
transition: define an animation for when moving to this slide
steadyState: set steady state, then wait for next navigation event
leaveState: set leave state when moving to another another slide
It is good practice to try and make each slide's state independant of other
slides. If a square is shown on slides 4 and 5, then it should be explicitly
shown on both slides. If it is only shown on slide 4, then it will be fine
when the user navigates from slide 4 to 5, but will not be shown if the user
is navigating from slide 6 to 5. Allowing users to go to specific slides out
of order makes slide dependencies even more difficult.
Therefore, the enter, steady and leave states above should be used to fully
define the figure's state on each slide.
However, while this approach will yield a good user experience, developing
many slides, complex figures or numerous equation forms can make slide
definition verbose. Even though each slide is different, many slides may
share largely the same state, all of which needs to be explicitly defined
for each slide.
The SlideNavigator tries to manage this by providing the fundamental state
callbacks above, as well as properties that can be defined once, and shared
between slides. Slides with shared, or common properties make copies of all
the properties so each slide is independant, but require the developer to
define them just once. If a slide doesn't define a common property, then it
will use the definition in the last slide that defined it.
For example, the enterStateCommon property is a common property. If it is
defined in slides 4 and 7, then slides 0-3 will not have the property, slides
4-6 will use the slide 4 definition, and slides 7 and after will all use
slide 7's definition.
Common state properties include:
enterStateCommon
steadyStateCommon
leaveStateCommon
The reason some states have both a common and slide specific property
(such as steadyState and steadyStateCommon) is so the common property can
be best leveraged. If all properties were common, then they would need to be
redefined every time a small change was made. Having both common and slide
specific properties allows a balance of defining some state for a group of
slides once, while allowing specific changes to that state where needed.
In addition to the above state properties, there are a number of short-cut
properties, that make it easy to set state for common figure elements. When
a SlideNavigator is instantiated, a text figure element, a figure collection
and one or more equation elements can be associated with it.
The text, modifier and modifierCommon properties can be used to set
the text of the text figure element associated with the SlideNavigator.
text and modifierCommon are common properties.
The form property is also common and can be used to automatically set the
form of the associated equation elements. A SlideNavigator can be associated
with one or more equations. The form property defines the form each of the
equations should be set to on this slide. If there is just one equation, then
the form property can be a string that is the form name. For two or more
equations, the form property should be an array of strings where each element
is the form name for the corresponding equation. The order of equations
passed into the SlideNavigator, needs to be the same as the order of strings
in the form array. To hide an equation, use a null instead of a string.
If the form property has less forms than equations, then all remaining
equations will be hidden.
The form property is a short cut with several consequences:
All equations with null forms will be hidden prior to enterState.
If the slide doesn't have a transition defined, and if an equation form
is changed, then a transition will be added that animates the equation form
change. If transition is defined, and equation animation is required,
then it needs to be defined in the transition property explicity.
Each equation with a defined form will have showForm called on that form
prior to steadyState.
The life cycle of a slide change is:
leaveStateCommon (for current slide)
leaveState (for current slide)
stop all animations
Update associated text element with text property
Hide all figure elements in associated collection
showCommon
show
show navigator buttons and navigator text element
hideCommon
hide
show fromForm
show all elements that dissolveIn or dissolveOut in an auto transition
scenarioCommon
scenario
enterStateCommon (for new slide)
enterState
addReference
show all elements that dissolveOut and hide all elements that dissolveIn
in an auto transition
Slide definition options object.
This object defines the state the figure should be set to when this slide is navigated to.
A slide definition has several callback properties that can be used to set figure state including:
It is good practice to try and make each slide's state independant of other slides. If a square is shown on slides 4 and 5, then it should be explicitly shown on both slides. If it is only shown on slide 4, then it will be fine when the user navigates from slide 4 to 5, but will not be shown if the user is navigating from slide 6 to 5. Allowing users to go to specific slides out of order makes slide dependencies even more difficult.
Therefore, the enter, steady and leave states above should be used to fully define the figure's state on each slide.
However, while this approach will yield a good user experience, developing many slides, complex figures or numerous equation forms can make slide definition verbose. Even though each slide is different, many slides may share largely the same state, all of which needs to be explicitly defined for each slide.
The SlideNavigator tries to manage this by providing the fundamental state callbacks above, as well as properties that can be defined once, and shared between slides. Slides with shared, or common properties make copies of all the properties so each slide is independant, but require the developer to define them just once. If a slide doesn't define a common property, then it will use the definition in the last slide that defined it.
For example, the
enterStateCommonproperty is a common property. If it is defined in slides 4 and 7, then slides 0-3 will not have the property, slides 4-6 will use the slide 4 definition, and slides 7 and after will all use slide 7's definition.Common state properties include:
The reason some states have both a common and slide specific property (such as steadyState and steadyStateCommon) is so the common property can be best leveraged. If all properties were common, then they would need to be redefined every time a small change was made. Having both common and slide specific properties allows a balance of defining some state for a group of slides once, while allowing specific changes to that state where needed.
In addition to the above state properties, there are a number of short-cut properties, that make it easy to set state for common figure elements. When a SlideNavigator is instantiated, a text figure element, a figure collection and one or more equation elements can be associated with it.
The
text,modifierandmodifierCommonproperties can be used to set the text of the text figure element associated with the SlideNavigator.textandmodifierCommonare common properties.The
formproperty is also common and can be used to automatically set the form of the associated equation elements. A SlideNavigator can be associated with one or more equations. Theformproperty defines the form each of the equations should be set to on this slide. If there is just one equation, then the form property can be a string that is the form name. For two or more equations, the form property should be an array of strings where each element is the form name for the corresponding equation. The order of equations passed into the SlideNavigator, needs to be the same as the order of strings in theformarray. To hide an equation, use anullinstead of a string. If theformproperty has less forms than equations, then all remaining equations will be hidden.The
formproperty is a short cut with several consequences:nullforms will be hidden prior toenterState.transitiondefined, and if an equation form is changed, then a transition will be added that animates the equation form change. Iftransitionis defined, and equation animation is required, then it needs to be defined in thetransitionproperty explicity.showFormcalled on that form prior tosteadyState.The life cycle of a slide change is:
leaveStateCommon(for current slide)leaveState(for current slide)textpropertyshowCommonshowhideCommonhidefromFormscenarioCommonscenarioenterStateCommon(for new slide)enterStateaddReferencebeforeTransitionnotificationformsteadyStateCommonsteadyStatesteadynotification