Animate Between Hype Scenes

Hi there,

I recently was introduced with a example file where I could click or swipe up and down to change between hype scenes. The animation between scenes was simply a constant speed until the next scene was full in view.

I wonder if there is any way to achieve some kind of animation when changing between scenes. An example of the type of animation I would be looking for is like this website: https://www.fb.se/

Any help would be greatly appreciated,

Thanks

@Ollie

Do your transition animation entirely in "Scene 1" (i.e. appear to go to "Scene 2" from "Scene 1") then do an instant transition to Scene 2 once this transition animation is complete.

Using this approach You can create any sort of effect your skill level allows - not limited to Hype's "built-in" transitions... if You've worked with a motion graphics editor You will realize the possibilities are endless.

Hi @JimScott

If I understood correctly, you are suggesting I can create an animation for the transition between the two scenes directly in Scene 1 and then create a trigger that when that animation is complete to go to Scene 2?

Thanks

Hi @JimScott

I have had a look back through the example where I first discovered scrolling between scenes and have realised it was your example file you linked me.

Following on from this, to clarify my intentions I have added in the original example you showed me. My desired outcome would be to change the animation when scrolling between the scenes. As you can see in the example file it is a straight forward constant scroll. Whereas I would like to aim for something along the lines of the website I linked: https://www.fb.se/

Thank you again.

scrollingScenes_JHS.hype.zip (16.7 KB)

@JimScott may have some clever ideas, but I don’t think there’s a great way to do this right now if you want to use Hype’s scenes. Only one can be showing animation at a time, and those animations don’t start until the transition is complete.

You could probably do an approach with a single scene, like this post shows.

Hi Ollie!

Checking back in to write here and I see that @jonathan has already responded with what I think would be the approach to take - one scene. You can use named anchors to scroll to different sections (i.e. the fixed position navigation “dots” on right side of screen).

1 Like

Thanks Jonathan for your suggestion.

Hi @JimScott

Thanks for getting back, would you be able to tell me a little more about the use of ‘named anchors to scroll to different sections’ I don’t think I have heard / seen this before.

Another quick question regarding the example file you linked, would there be a way that after the first couple of scenes the scrolling to the next scene can be disabled. I would then use buttons to access the other scenes rather than scrolling through all of them.

Thanks for your help.

1 Like

me neither.

@Ollie @Ed_Sager

Note: The term "named anchor" is actually a throwback to HTML4 when the "< a >" tag could either be a hyperlink or an "anchor" on a web page. In HTML5 there are now only "hyperlinks". Also in HTML4 You could use the "name" attribute, but now only the "id" attribute is supported in HTML5.

So with this in mind...

A "named anchor" I think is best illustrated by an example:

<body>

<h2 id="top">Top of page!</h2>

<p>In no time at all Hype 4 will be released.</p>

<a href="#top">Go to top</a>

</body>

Inside the opening "h2" tag we see id="top". In the opening anchor tag near the bottom of the HTML markup is written < a href="#top">. Clicking on this link instantly (no scroll) places the "h2" element's page location at the top of the page (if the spacing on the viewport~page length permits).

This is an extremely short "body" length designed to illustrate the principle, of course one would typically use this type of arrangement with much longer pages.


A demo - created by @MarkHunte - effectively demonstrates this basic operation in an elegant bit of code - differently executed than the example above but with the same ultimate result:
smoothscrollingEdge2HypeDRAFT2_MH1.hype 2.zip (28.4 KB)

The function running things is called "smoothscroller". Note: Mark uses "classes" and he uses jQuery (loaded in the "Head HTML").

The jQuery utilizes a script featuring "animate" (part of jQuery's lexicon) in the "smoothscroller" code, which - as implied in the function name - allows the page to smoothly scroll to the appropriate element.

Original thread:

4 Likes

I will move this into the "single scene" realm now... and You probably got this already - but just to complete:

Use the markup (< body > < h2> < a>) shown in the initial example in my post above as a guide to "jump" to various sections (i.e. no scrolling)... no need for the "smoothscroller" function as in Mark Hunte's example for these buttons.

@Ollie
The following is closer to your original question about animating between Scenes - and is intended to show general principles. Your original example is basically the same set-up > scrolling between discrete Frames~Scenes that lock into position.

@jonathan Challenge accepted - for the usual stakes? :sunglasses:

Dynamic Animation during Scene Transitions - Online Demo.

Hype project file: SceneTrans_JHSv1.hype.zip (22.2 KB)


Disclaimer:
I still think a single Scene is the best way to handle a scrolling behavior scenario. This demo is intended to show another approach (and more work) which is best suited to "visually disruptive" transitions such as cross-fades which allow for a greater tolerance of heavy-duty animation shenanigans - even so you can still get pretty granular with this technique.


Overview:
There is one controlling group in every Scene (two Scenes total in this demo). Each controlling group contains the other Scene's initial animation (sub-group) in addition to the current Scene's animation (another sub-group). When the "Go to Scene" button is clicked there is a shift in the "top" position of the controlling group in the Scene which displays a simile of the "Go To Scene" (sub-group); then an instant jump is made to the actual Scene. There is deliberate lag in the "Go to Scene" button's appearance (i.e. "Go to Scene 1" or "Go to Scene 2") in order to show the synchronizing between Scenes (i.e. when a button is displayed You are in the actual Scene).

An examination of the attached project file will yield a better understanding of this process than a full explication here... but I am happy to answer any specific questions regarding this Demo.

1 Like

How many beers do I owe you now? :wink:

Actually this got me thinking about using Persistent Symbols to avoid element duplication between the transition scenes. What do you think about doing it that way?

@JimScott

Thank you for your continued help on this!

The example you have just previously explained and linked will certainly be a excellent concept to add into my existing project.

Again I really do appreciate all your efforts and help to guide me in the right direction on how best to achieve my original thoughts.

Kind regards,

Ollie

2 Likes

@jonathan

I will be responding further (I’m deep in the weeds on a deadline). Just quickly - the Persistent Symbol was my first “go to” - but it had an issue that I ran out of time to resolve and went with the set-up You saw.

1 Like

@jonathan - et al!

This is in answer to your question about using “Persistent Symbols” for scene changes involving custom transitions with or without animations (“trans-animations”) occurring during the transition.

A question before we move along...

Duplicating the elements is easy from a layout perspective - so I am assuming the above relates to overhead? (Let’s exclude projects with lightweight imperatives such as banner ads.)

Part of the design goal would be to keep the elements involved in the transition to a minimum.

Would duplicating a simple set-up such as headline text (four words); short paragraph; basic SVG (i.e. not a map of the United States); one image 300px x 400px; and eight Hype primitives (ellipses & rectangles) comprise much of a hit? The image would of course be cached.

I know this is similar to asking how long is a piece of string - but just a seat of the pants guess?


For the purposes of this post a “custom” transition is a manually created~directed transition as opposed to the “standard” Hype transitions. For an example of a “custom” transition with “trans-animations” please see the video at the bottom of this post showing an example containing 3 separate trans-animation styles.


1) Video
This is a slam dunk situation for “Persistent Symbols”. Trying to synchronize a trans-Scene video without this valuable feature would be torture. The following example also appeared in another post. Persistant Symbol across Scenes.hype.zip (2.6 MB)

2) Sliders ~ Filmstrips
I am seeing a marginal utility here unless it is just a couple of scenes.

Reason: Suppose we have (5) Scenes all custom transitions. If You are navigating back and forth between all the Scenes where would a "regular" set of elements fit in? To keep the idea of no “repeating elements” going the entire set-up would need to be a Persistent Symbol - so You might as well just have one Scene with Groups serving as frames in the slider.

3) Complex Transitions...
involving destructive pixel operations such as crossfades, or situations where duplicate images are needed to stack over each other to achieve the effect. You would need to duplicate the necessary elements in a Persistent Symbol also.

By no means am I trying to portray the above as an exhaustive examination of the possibilities but rather examples of common situations.

Example: Three separate “trans-animations” during the transition:
Element rotation; “Vertical venetian blind”; Blurred background to sharp...

While you are correct layouts have more overhead than a persistent symbol, I really was just thinking more from an editing perspective so a change doesn't need to be made twice. If there's not a lot of elements it isn't too big of a deal in non-ad cases.

There's definitely a point to be made that persistent symbols may not be necessary in cases like this. I'd say it is up to how someone wants to organize and deal with complexity.

True! This is a good reason for them not aways being a good fit.

1 Like

Thank You for your thoughts!

This is exactly what I been looking for. Thanks.

1 Like