I think it’s about the flexibility of frames. The question is why not to use frames for everything? I get what you are saying but I think the mental model is not to think about which container I need to use, it is using the one that is most flexible and later on set its properties. My opinion is that everyone will end up using frames and forgetting graphics even exists because it is not a logical way to work. It’s just my opinion, but it is somewhat based on what I see in my work and others’.
Hey I’m still discovering new features and possibilities in beta. New frame option is really useful for us but I really didn’t find the any use case of other options. Or maybe I’m wrong. I know sometimes I need groups in frames but why there is a graphic option? I agree with @wwwedran on this topic.
We’ll do a proper introduction with examples when we release publicly, but I’ll explain a bit.
In short, frames are for UI elements, graphics are for icons and illustrations.
Frames are a container for standalone UI elements. They have a fixed size. Their contents have sizing options and are fixed size by default, and support pins and are pinned top-left by default. When you resize a frame, its contents adjust based on their sizing option and pins setup, for maximum flexibility. Frames can also have Stack Layout applied, in which case they’ll lay out their contents in a row/column, with lots of layout options available. Smart Layout remains available too.
Graphics are a container for icons and illustrations. They also have a fixed size. But their contents don’t have any pinning or sizing options. So when you resize a graphic, its contents always resize proportionally — and in the future, we want graphics to scale their contents’ styles too (borders, shadows). Graphics don’t support Stack or Smart Layout either. They’re a much simpler container for when you’re drawing, not doing layout.
Either one can be a symbol. So your UI components will likely be frames (and many with stack layout), but you may want your icons to be graphics so you can resize them to make the icon appear bigger or smaller.
If your work is mostly UI design, maybe you never find yourself ever creating a graphic, and only interacting with them when inserting icons from a library — and that’s totally OK. If you do a lot of icon design, you’ll likely be making them.
@paulozoom what is the logic used when applying autolayout to existing frame with objects? Sometimes it resizes the frame and sometimes it keeps it the same size but adjusts the position of the layers within. It’s bit difficult to understand how it chooses what to do.
The inference logic for Stacks is so complicated we couldn’t begin to share it. But it’s something we’re constantly improving and validating even post launch.
Please give us a specific example of what you found unexpected
I think the main point of confusion is that frame sometimes defaults to fixed height or width and sometimes it defaults to fit. In Figma it seems that it always defaults to hug, which is my expectation. In Sketch there is an invisible area around the layers and I’m not sure where it comes from and what informs its behavior. Maybe I’m missing osmething here but it feels a bit weird when I’m using it.
I understand. Thanks for the video! At 0:37 I think it’s because the size of the frame is far greater than the size of your content we do not set the width and height to fit. If you are deliberately drawing a frame that large, and adding a couple of small layers on it – we might hear from another user that it is annoying the frame they drew (at that specific size) is not being respected.
It’s not just a black and white set of rules, there’s logic depending on various scenarios and situations and we try to make best guesses based on intentions. But it’s impossible to get right.
Makes sense. I understand this is very complex. I’m just trying to understand its behavior so I can predict it. I guess your approach makes more sense because if you initially drew a container you likely want to keep it the same size. If you want to wrap layers together then you draw layers first and wrap them in a stack.
The invisible wrapper is still a bit unexpected and I see it causing some confusion for users. That’s where Figma’s approach is more predictable.
Thank you for giving some insight into what Graphic container will do. They are a bit confusing in their current implementation. One thing I would expect is that shadows on a graphic layer would behave like they do on groups. Meaning that the shadows would take the shape of the content, not the graphic’s rectangle. That way we could resize the graphic and keep consistent shadows. If I want the shadows to resize, then I would apply them to layers within the graphic.
Could you give me an example of an icon where this is preferable?
But note that the moment, resizing a graphic won’t resize the shadows of its contents. Only the dimensions of the contents will be proportionally resized, its styles won’t. If you want the styles of the contents such as shadows (and also borders) to also resize, you’ll have to use Scale (K) on the graphic instead of normal resizing.
Sure, so let’s say I have icons used throughout my app as blank screen illustration. I might have different sizes but would like the same shadow effect fo consistency.
Or more pragmatically, as I rework the design I might be tweaking the icons sizes but I would want my effects to stay the same, again for consitency and balance with other shadow strength I might have. Basically I’m thinking of shadows like I would type sizes, I establish the contrast I want / need and then I maintain consistency as much as possible.
Part of my comment was about shadows on graphics and frames. Is there a way to get the shadow style on the frame to reflect the objects within? Like the figure on the right:
No, you’d have to group the elements and apply the shadow to the group. But we’ve had some discussions recently about shadows on fill-less containers, I’ll talk to the team.
I made an artboard (frame), but didn’t use a predefined preset before making it (allowing the prototype player to just show a macbook pro screen for example and the rest scrollable).
Now that we have frames instead of artboards, is there a way of setting that after you’ve made a frame? or does it need to be chosen before creation
Good news, @Gael. I was wrong, there is a way, yes. Disable “Clip content” on the frame/graphic which has the shadow. Not that this only works if doesn’t have a fill, border, or blur — the presence of any of these will make the shadow cast on the container itself instead of the contents.
Like with shadows on groups, this is limited to one shadow for technical reasons. Having two shadows will make them cast on the container too. We’d love to lift this limitation one day, but it’s not quite feasible at the moment.
We realize the influence of “Clip content” is not very obvious, and we’re at this very moment working on figuring out a way to make this simpler for people. Stay tuned!
@Gael Update: we’ve improved this so “Clip content” will no longer be a factor when deciding to cast shadows on the contents vs. the container itself. If the container has a fill/border/blur, its the shadow is cast on it. Otherwise, it’s cast on its contents. This will be available in the next beta.
I know I previously moaned about the size of the padding handles before, but I feel this is a little too far the other way they’re a little fiddly to grab now if theres isn’t initial padding on a frame, maybe if the handle height were double to 2px?
Also it’d be awesome if holding cmd and dragging allowed you to pad a single side at a time, similar to the radius behaviour
Not sure if this is known, I know some other stack & instance things are but on a text object the behaviour of fit and fill work the wrong way around it’d seem when creating a symbol in the latest beta plus sometimes when drawing a shape into a frame with shift held down it messes up the proportions - video attached.
I was waiting a while to get used to the new UI elements but I still can’t get used to new icons for Stacks. Most of the icons, including the add stack one, are not legible enough. I think the problem are thick elements that are too close together, especially noticeable on the add stack icon and the alignment ones. I guess we can get used to them, but they just feel a bit below the high level of quality of other icons in Sketch imo.
they’re a little fiddly to grab now if theres isn’t initial padding on a frame, maybe if the handle height were double to 2px?
