Can I do page transitions without any animation?

[graphaz]

Principle Version: 5.10
macOS Version: 10.15.3
Sketch Version: 60.1

Description of what you need help with:
I’m trying to have pages linked on tap but without any animation. I want it to just jump to the page – no slowing, no sliding… nothing.

Steps to reproduce the behavior:

1. Imported artboards from Sketch
2. In Principle linked from a group (via circled flash symbol) on one page to another page using Tap.
3. Then got rid of default animations by clicking on transition arrow and hitting “No Animation” in the timeline.
   In Preview it jumps to pages on tap as desired but still shows animations (groups/elements are moving forth and back, up and down, lines rotate…).
   I don’t want any of that!
   I’d like to show a client a “dry” prototype first where they can experience where it jumps to when they click on certain elements on the page. No added gimmicks.
   I really hope that’s possible and somewhat intuitive.

Screenshots/Sketch File/Principle file:

• Video of corresponding transitions (on tap) with unwanted animations: NoAnimationPlease.gif

Also, are there any preset options in Principle where one can set defaults like that?

Thank you!

[shonen]

Principle auto-transitions elements with same layer names in 2 different screens, so the best way to don’t have any transitions is to make sure that there are no repeating names in any of both screens.

The items that are animating at he moment is because they have another layer in the other screen using the same layer name, simply add something to the layer names to make them unique and they will simply ‘pop’ with no transition whatsoever.

Hope this helps!

[graphaz]

Thank you, Shonen!

Did you mean the two layers/elements that are “linked” can’t have the same name (I guess that would probably make sense from a developer/implementation standpoint).
Does that also mean that the groups these two elements are in can’t have the same name, or both?

Based on the above assumptions I got rid of all links and changed the names of the two elements that are linked and also the names of the groups they are in.
Unfortunately there’s still animation. So that can’t be the issue then, right?

Or is it that no two elements on the two linked screens can have the same name? Or even: no two elements on any of the screens can have the same name?

Is it just me but I don’t see why it wouldn’t be set to no animation by default, no matter the name of the elements? And then you’d go in and define animations/transitions as you want them?

I think it would be more logical if generally there would be no transition/animation by default if not defined otherwise (instead of random transitions).
Likewise it would make sense to have the same transition/animation for elements with identical names if not defined otherwise (instead of random transitions).

But maybe I just don’t see the obvious…?
Help is highly appreciated!
I spent way too much time on this already.
Thank you!

[shonen]

If there’s an undesired animation/transition is because of layer names, I’m sure that’s the reason.

Check well, it works for groups too.

Feel free to upload the file to Dropbox and share it here so I can help you out identifying the issue if you want!

I think they made it that way as it’s actually a very quick way to work and create something quickly without touching or adding anything else!

You add a circle named ‘circle01’ in one screen and then the same circle ‘circle01’ in another screen has properties changed (position, scale, colour, etc…), so if you transition from screen 1 to screen 2, Principle will automatically animate that transition without you adding any keyframe or anything, similar to auto-transition that comes in Keynote (or magic transitions, not sure what name is it)

I think the way it works is perfect, if you keep your layers tidy, and name everything correctly, you can reduce a lot undesired results, and things that don’t change between screens won’t be animated.

So review all layer names, start for those that are animating. If you have a layer being animated called ‘XXX’ I can guarantee you have another layer ‘XXX’ in the previous screen where you transitioned from.

Let me know if you have further questions!

[LikenToLichen]

That seems like the best solution @shonen but as another sillier way could you simply reduce the transition time to zero?

[shonen]

@LikenToLichen, hehe you got me there! It actually makes sense that too, and definitively works too.

As a quick temporary solution I think that’s best indeed, but if you are working in a big prototype and want to keep things tidy and avoid undesired effects, I’d recommend naming layers accordingly.

Thanks for that tip, I missed that option completely!

[graphaz]

Sorry but I’m relatively new to this, so I have to assume I’m not really understanding what solution you guys are suggesting? I’m a bit lost right now to be honest.

First, just reducing the transition to zero alone didn’t get rid of random animations, at least in my case at hand.

Second, for the renaming solution proposed by Shonen – for simplicity sake let’s assume transition btw. only two screens, forth and back – only by making sure no elements, groups or layers on the second screen had the same name as any on the first screen finally eliminated most animations. And I say absolutely no elements, even if they’re not involved as a tapp element anywhere, as soon as I have one with the same name animation is back.
I don’t know… naming every single instance of every single element or/and layer different on different screens (no matter if used as a tapp element or not) seems crazy and confusing. Specially when you need to have nearly as much screens as you have transitions to make it work to begin with.
Consider the use of libraries with instances, components and symbols in Sketch – you’d have to go in and change the name of every single one of them?!

But I’m probably a bit lost by now anyway. My page is rather complicated and has lots of transitions and elements. I guess I’ll have to make a very simple example with maybe three screens and maybe 4-5 transitions between them to learn the tools and understand the process – then build on that. That way it’ll also be easier to share my files with you in case I get stuck again.
Back to square one…

[shonen]

Here’s a quick video of what we meant with making transition times 0 so there won’t be animations, just note doing this will remove the animations, but objects will still ‘pop’ in different places if they have same names and different properties or there’s elements that exist in one screen and not on the other…

Link to video here

I recommend you to use components as much as possible, that reduces the amount of layers/groups considerably! Specially if your design is already complex, you need to reduce that complexity either by working with components or flattening layers when you import from Sketch.

Tip:
if you add ‘principle flatten’ to the end of a layer name/group, this will be flattened into a single image when importing to Principle.

What I do sometimes, is that elements that I know for sure won’t be animated apart from maybe be within a scroll, I flatten them, only interactive elements I make them a component.

You can reuse components but the way is currently implemented sucks a bit, it’s not like in Sketch that you have a component and then you can change some overrides to make a new instance.

In order to have that, you need to create the componente in a separate Principle file, then copy it into your working project.

Example:
I have a button I want to reuse many times with different label, so I create such button in a new Principle file I usually call ‘playground file’, in that file, you create the button, with all the style and animations and messages going out of it, then you give a label a name for example ‘Login’ and then copy it back into your working project. Need another button with same style but different label? Go to your playground file, change the label text before copying back into your project file, and so on…

It’s not ideal, and I hope @Daniel is going to include a way to do overrides soon, but not sure.

It takes some time to get things going on, and at first you will find yourself a bit lost, but it’s not very complicated.

[graphaz]

Thank you so much, Shonen, for your time and patience! I really appreciate it!

So it is in fact a bit cumbersome with having to rename each and every instance.
I thought it was just me, thought I was loosing it.
There doesn’t currently seem any good way around that (if I got that right) – except maybe for setting the animations to zero (I’ll give that another go).

I like the idea of deciding what won’t be animated and can therefore be flattened, resp. mad into components. It also forces one to plan ahead.
Like you mentioned it’s probably a matter of working around current short-comings and limitations and finding smart and efficient ways of doing so.

It’s a nice perk with Principle to be able to create animated transitions and share them. And it’s good that there’s competition to InVision and other clumsy sharing tools.
I’m just amazed that, after all these years of Sketch (and other web/app focused design tools) being on the market, there’s still no easy and intuitive tool (or plugin) to share web designs and prototypes with interactivity in a way that clients and team mates get a good feeling for basic functions and interactivity.

Again, thank you guys for all your help!
I’ll keep you posted on my progress and findings along the way.

[shonen]

I agree, some things could be improved, but overall Principle is a great tool, I tend to find that the more work I do on Sketch of tidying and renaming stuff, the less painful work I have to do in Principle.

So it’s good practice to try to be tidy when naming layers and groups in Sketch having Principle limitations in mind, group and flatten everything that can be flattened, and keep editable those elements that need to be animated later on.

Another thing I do is that if I have 20 different screens, probably within those 20 screens there’s lots of common components, so I only have to import once and build those components in Principle to reuse them in the rest of screens, so I won’t import those 20 screens but maybe just 2-3 more relevant ones, and I’d build the prototype on Sketch, if I need a new element from Sketch, I’ll import it to a new Principle file to avoid messing with my current work file, and just copy and paste from that temporary file into my working one. Of course if you import 20 screens and have to re-name everything you will drive yourself crazy!

Glad I can be of help, any more questions, I’ll be around!

[graphaz]

I do have one other question, not directly related though.
I’m working on a desktop only prototype right now, but, just out of curiosity, how do you go about responsive with the Sketch/Principle worklfow?

[shonen]

I’m not sure what you mean with that, as in… how do I prototype responsive designs? If so, I normally create separate prototypes for it, one for desktop, one for mobile (and maybe some tablet views if there’s need for it).

[graphaz]

Shonen, yes, that’s what I meant.
If I understand correctly you create separate prototypes, one for each size/breaking point?
Good and simple in many cases, sure.
But what if you want to realistically show a client “fluidity” as in what happens when you resize the browser width?

The problem is that when you’re sharing your animated Principle prototypes with a client (specially when the receiving end sits on a PC as the only options are .gif or video) you can’t control in what size screen they look at it and how they change the browser width. They end up getting the wrong impression and for example perceive things as too small etc…

Sure, you could send them all the different sizes separately and talk them through it but for an animated prototype sharing app that seems odd, I would expect that to have some responsive/break-point features built-in, no?

Or… maybe we can figure out a simple work-around using animation for breaking points? Something like “if you go wider than the transparent background square on this mobile size artboard jump to the next artboard” (which in this case would be the tablet view artboard) or something like that…?
Begs the question if it’s possible to have different sized artboards in one Principle file.

[shonen]

To be honest, if what they want to see is the transition when resizing the browser, you could do that directly recording the screen and using Sketch and resize an artboard to see how every element should adapt to it’s new parent container size, for that specific reason I don’t see the need to create a whole prototype just to see how elements adapt since you have that already in Sketch!

Said this, I’ve done what you say before, I’ve attached a video, I took the idea of Google Material Resizer tool that you can see here: https://material.io/resources/resizer/#device=window&width=1440

So basically, you just create the prototype in the bigger resolution and trim down the screens as you select smaller ones.

You can see it in action here: https://www.dropbox.com/s/5oa7zug3jnu0lx6/resizing-view.mov?dl=0

Hope this helps!

[graphaz]

Thanks again, Shonen.
Sure, I could just record some of that in Sketch. I still think it would be helpful for having such a feature in Principle.

Speaking of work-arounds… I just found an interesting post I’d like to share, by a fellow named Marcos Felipe, on Dribble. He uses drivers and a slider to suggest responsive behavior:

[shonen]

This is a cool way to represent that! And using drivers shouldn’t be too complicated to achieve. Of course the UI in the example is very simple, it might be lots of work if your UI is more complex, keep that in mind.

Thanks for sharing!

[graphaz]

I took a more simple approach, just transitions, no drivers.
As you pointed out, Shonen, these solutions are maybe good for sharing rough concepts of behavior in an early prototype phase. Combining this kind of responsiveness animation with complex scrolls, buttons and other interactions within the pages themselves you would end up with hundreds of screens, even if you were to flatten most of the layers.

[shonen]

Looks great! I’m glad you managed to represent your view!