Join the Webstudio community

Updated 4 weeks ago

Allow canvas scale/zoom independent of selected breakpoint

Problem

When building layouts on the canvas, I often want to zoom in to see the area I'm working on better. This is especially relevant when I'm designing on the canvas.

Why it's a "problem"

  • Currently in Webstudio, the scale of the canvas is set by the breakpoint you're viewing. The page width is sandwiched between the Navigator on the left and the style panel on the right. With smaller design details viewed on a larger-width breakpoint, it can be difficult to see what you're doing in that relatively small space.
  • This feels like a problem because when designing in Figma and the Divhunt website builder (https://www.divhunt.com/feature/canvas) you can zoom and pan on the canvas.

Current options to deal with this

  1. To scale up the canvas, you can currently undock the Navigator panel on the left to see a bit more screen real estate (higher scale). This does help a bit. But then you need to open and close the Layers panel to see the page structure. Also, I'd like more control over the scale.
  2. You could choose a smaller breakpoint to see better, but that affects the layout you're designing.

Suggestion

Maybe the canvas scale could be optionally unlinked from the breakpoint you're viewing.
  • Then you could set the scale/zoom independently.
  • An independent scale/zoom would mean that possibly not all of the page width would be shown on the canvas. So the ability to pan around the canvas would also be needed.
  • I realize that these features would mean making Webstudio more of a design tool like Figma.
1
O
H
B
95 comments
Do you usually need that level of detail as a way to see more for a few seconds, like a magnifier or do you want to be able to work in a zoomed in state for longer period of time?
I did not dare say this – but my first impulse in front of Webstudio was similar. Have an infinitive canvas, freely drag graphics onto the pasteboard... Try a few effects out on the pasteboard and discuss, before getting serious with grids and stuff.

Then I told myself to reconsider and to rather do this sort of work in tools like Figma. But I can't help finding the WS-workspace “rigid”. For people who mostly sit in front of IDE and command line tools, zooming out likely takes place in other dimensions 😃.

Divhunt's canvas looks neat, Vev also has an interesting approach. https://www.vev.design/
experimental canvas where everything is absolutely positioned is a separate problem though from being able to zoom in
I am interested in solving both 😉
I wanted to be able to work in a zoomed in state for a longer period of time. Maybe I'm just spoiled by being able to do that in Figma. But being able to design directly in Webstudio is liberating. 😀

So my use case is skipping Figma and going right to Webstudio to design/build together.
The challenge here is to figure out the best possible ux that allows to zoom in and out without loosing ability to fully understand the constraints
Figma is not giving you the constraints, and so you are just drawing rectangles. Webflow/webstudio is not giving you enough freedom to experiment and zoom things in/out
Here is what Divhunt does. Breakpoints are tied to device width as usual but zoom doesn't lock the view to the page width of the set breakpoint. You zoom in and out on the canvas using keyboard/mouse combo like in Figma (CMD + mouse wheel).
Attachment
Divhunt_breakpoints_and_zoom_UI.jpg
That necessitates a different approach to rendering the canvas, though. Because now you need to be able to pan around also. I imagine that's pretty different from how Webstudio handles this now.
yes, we tried that, wasn't great
responsive canvas is very important too
the problem with that approach is that you will end up zooming in and out all the time
I found myself using zoom so much that it was more work than with a responsive canvas
so I won't advocate for this figma-style canvas, this is not figma
but I think there is room for having ability to zoom while having a responsive canvas
I know what you mean about zooming in and out all the time with that approach.
That's why I wondered if there was the possibility to consider the option to unlink the scale/zoom from the width on the screen (between the panels) when needed. Then re-link them.
But I definitely understand that a design tool and building tool have different approaches
exactly, I am still thinking about it
I only ask because it felt so great to skip Figma and just go to town in Webstudio 😀
I see 2 options so far:
  1. switch to infinite canvas mode and have a figma-like canvas
  2. disconnect zoom from breakpoints and just let it zoom without switching breakpoints
the second option could be probably implemented very easily
yeah, 1 seems like new approach entirely
the first option gives you beyond zoom also ability to have multiple canvases next to each other
The core of designing is experementation
The core of experementation is being able to compare experiments and share them
that means one and the same thing needs to be able to have variants
and you need to be able to see them next to each other
I think zooming and experementation needs to work together
Maybe this is where the primary goals of Webstudio come into play. Can you see Webstudio becoming a design-as-you-build tool?
its not gonna replace all design cases, like svgs etc
like drawing random shapes won't be the goal
but designing for the web isn't about drawing random shapes
right—goal is websites and apps, yes?
so its going to become a design tool for the web
my definition of design is not graphic design
my definition of design is based on jobs "design is how it works"
in figma you are a graphic designer, in webstudio you are web designer
"functional design" for the web, yes
draw svgs in figma, do the rest in webstudio
of the 2 options you mention above, where might you see webstudio going ultimately?
seems like 2 is a short-term solution, whereas 1 is a step that starts to put figma out of the website/app design business 😀
I am not sure, needs to spend some time prototyping
Also properly defining the goals might help
Our goal is not to be zooming in and out and have that infinite canvas that can allow you to create that completely free mess
our goal is to be able to see
  1. multiple versions of the same thing
  2. be able to zoom in-out to view details at a larger zoom
if these are 100% all the goals, then we don't need a 1:1 figma canvas
agreed that too much freedom (like infinite zoom) can cause overwhelm... and messes
constraints are healthy
in fact I have yet to see a figma canvas that is not a total mess
well I know the good once are cleaned up
we do have them clean lol
but anyone without dedication to cleaning it up creates a 100% mess
in particular creating multiple version of one particular component or section or page has to be a systematic decision
not just a "lets copy this thing 5 times"
it should be "create a version" button that places a second canvas next to the previous one with the same thing on it
to see multiple versions like this, that's where the zoom will come in?
first of all what happens to the breakpoints
if they are global, it means they apply to all canvases
that means no matter which rbeakpoint you choose its always the one used everywhere
and zooming happens independent of the breakpoints
if breakpoints need to be selected individually for each version, then we would need to change where breakpoints are located too
so canvas for a page is like a frame or artboard linked to a specific breakpoint?
aka what framer does would be required
but on the other hand, if you are working on the same thing just in different versions, why would you need to switch to different breakpoints on different versions
you want to compare the same thing
so maybe this can stay in one place
the zoom feature would be basically zooming in and out the workspace not the canvas
ah, yes. 2 scenarios:
  1. compare different breakpoints for a page (same version)
  2. compare different versions for a breakpoint (same page)
interesting. i guess this whole time i was referring to "workspace" as canvas. meaning the area you can view between the panels in the app...
comparing different pages on different breakpoints seems a completely separate goal, basically testing how each page behaves when changing a breakpoint
yeah, in figma they call the zoomable space the canvsa, but in webstudio case it makes more sense to zoom workspace
testing different pages under the same breakpoint is something we will cover differently, we will have a preview mode that you can open in a separate tab and use a special view for previewing in various device sizes
I see it more like "device testing" than building environment
it could be opened on different physical devices too
on canvas I want to focus on "building/designing experience"
its definitely quite a different mode if oyu truly want to test each specific device resolution, you will want not only width and hight of that device but also potentially other things simulated, which is better done either on devices or simulators
in particular on mobile there is shit load of specific problems, liike the url bar behavior, keyboard behavior, overscroll and what not
so on canvas we are just focused on breakpoints and rough sizes we are testing on
with figma-style workspace you need a way to move between the canvases, with workspace being completely flexible you need to drag that with the mouse

if canvases are not flexible and are automatically positioned, they are more like spaces on macos, whic can be switched between via a switch
that sounds fantastic
basically what we need is spaces aka macos spaces + zoom in and out so you can see muliple spaces at once
so its not an infinite canvas at all actually
even though its zoomable
I think we just thought this through
i was just going to say you sound like you already had thought this through 😀
I had thoughts, but it helps to share them
having clarity on problems we are solving and problems we are NOT solving is crucial
i appreciate being able to be a soundingboard
Oh we’re A/B testing can be set up for a page?!
yes, A/B testing should be also made possible by creating 2 branches ... though AB testing is also connected to WHO you want to show it to and how many and this is usually a completely separate feature ...
but yes we need to consider how AB testing would be made simpler with this
Add a reply
Sign up and join the conversation on Discord