Iāll add my vote - I much preferred it how it was too and Iām not surprised thereās been a bit of a backlash.
1 Like
ok I have to add to this. why was this even changed? left click drag worked fine for years and now suddenly I need to use right click for something I do hundreds of times a day. every other tool I work with uses left click, so now Make is the one odd app that I have to remember works differently.
and the worst part is thereās no setting to turn it off. at least Miro and Figma let you choose. just give us a toggle in the settings to bring back the old behavior and everyoneās happy, the people who like the new way keep it, the rest of us go back to normal. not a big ask.
2 Likes
Hi everyone,
this is Lukas from the Make product team.
Thank you for the direct and detailed feedback in this thread. We read all of it, and it helped to shape our plans, so I want to share what is coming.
The new navigation stays as the default, but you will no longer be locked to pan with right click only. We are adding a setting to choose how you pan the canvas:
- Mouse: pan with right click or left click
- Trackpad/Touchpad: the same choice, so you can pan with a single finger drag if you prefer
@Lea_Bonet, @Stoyan_Vatov, @Ram_Moshkovits, this is the option to choose between left and right click that you asked for.
We are also making it easier to select several modules by dragging a selection box on the canvas, on both mouse and trackpad/touchpad.
This is rolling out in the coming days. I would rather land it properly than rush a date, so I will come back here once it is live with the exact steps. The choice will live in the canvas options, under input device settings.
Thanks for caring about Make enough to tell us when something is not working. It genuinely shapes what we build.
Lukas
6 Likes
Make team on fire with quick reactions to feedback lately 
Will the choice be user specific or organization specific?
4 Likes
Thanks Stoyan, appreciated. The choice is per user, so everyone sets their own way to pan.
1 Like
Hi @Jaz,
this is Lukas again, coming back to you because my earlier reply did not properly address your point.
You asked us to reopen this with the team. We did, and it changed the outcome. We are adding a setting to choose how you navigate the canvas. With it, panning will use the same input you already use for clicking and moving modules, so the constant switching you described should largely go away. A few occasional actions, like opening the menu and selecting several modules at once (marquee), still use a separate input.
To be straight so there is no false expectation: this is a choice of how you navigate, not a switch back to the old behaviour, and the new model stays the default. But in practice it should take the repeated switching out of the things you do most.
You were also right on the principle. Giving people control over a forced interaction model is a baseline for inclusion, not an extra, and we took that on board.
This is rolling out in the coming days and I will post the exact steps once it is live. Once you have tried it, please tell me whether it genuinely works for your day and your rollout.
Thank you for pushing on this. It changed what we are shipping.
Lukas
5 Likes
Make has been KILLING IT with features and releases lately; the IF/THEN option and all the AI features in particular have been amazing. I will definitely agree though that fundamental changes to navigation are not taken lightly and this change has really thrown me off too. I am so happy the team takes feedback seriously and is releasing a potential fix to the clicking issue. I am glad to learn it wasnāt just me and that you guys are on it already, so thank you!
I would also second that the zoom levels are a bit too extreme as well; the zoom in is fine, but one click back makes it almost too small and there is nothing in between, so adding back in some granularity in zoom levels would be amazing as well.
4 Likes
+1 on the zoom, and Iām relieved itās not just me - Lea_Bonet, @William_Gravier and @tommyb already flagged this and itās exactly my experience.
Since the canvas update the wheel zoom jumps in steps that are far too coarse: one notch and Iām either buried inside a single module or thrown so far out that the module numbers disappear and I lose all orientation. Thereās no middle ground anymore, which makes navigating even a medium-sized scenario genuinely tiring.
It got annoying enough that the consultant who handles our automations built himself a small, open-source browser extension that fixes it locally:
It intercepts the wheel event over the canvas and re-dispatches it with the scroll delta scaled down to about a third, so each notch becomes a gentle, controllable step. That one change made the editor usable again - which honestly shows how small the fix on your side would be.
The same extension also patches something thatās been broken for well over six months now: Hebrew text in the editor renders in a broken fallback font thatās genuinely hard to read. Weāve basically stopped waiting and just force a proper font ourselves. It would be great to finally see that fixed natively.
So two asks: please add a zoom-sensitivity setting (or simply smaller default steps), exactly the way you just did for the pan button - and please take another look at Hebrew font rendering. You listened on pan, which was great. Same energy here, please.
1 Like
Update: the pan choice is now live!
You can now choose how you pan the canvas. Open Canvas Options, go to Input device settings, and under āCanvas panningā pick Left-click. The new model (Right-click) stays the default, but if you prefer to pan with a left click and drag, you can set that now.
We also made it easier to select several modules (marquee) at once by dragging a selection box on the canvas.
If you try it and something does not work the way you expect, tell me here and I will follow up.
For more details, please refer to this documentation.
Thank you all for the direct feedback. It genuinely shaped this.
Lukas
6 Likes
thank you for this, and for being specific on both.
On zoom: youāre right that the wheel steps are too coarse, weāre actively looking into the step sensitivity now, and details like the scroll-delta behaviour your consultant described are genuinely useful input. I canāt promise a date yet, but if we ship an improvement Iāll post it here. (Thanks for sharing the workaround too. Useful signal for us, even if itās not something weād point people to officially.)
On Hebrew rendering: that one shouldnāt have sat this long. Did you happen to raise it with our customer care team? If you have a ticket reference it helps me trace it, and Iāll flag it internally regardless.
Your listened-on-pan energy noted, and appreciated.
Same intent here.
Lukas
2 Likes
I just found out that its not true. Maybe for a generic user this works, but as a Partner Iām part of about 70 organizations at the moment and I have to change the setting for each one separately. Any chance this can be updated so I have to change it just once?
I appreciate your detailed response and your teamās decision to offer this choice to your consumers.
2 Likes
Hi @Stoyan_Vatov,
thanks for flagging this.
A quick clarification that should help: the setting is stored per zone, not per org, so it carries across all orgs within the same zone. If you work across EU1 and US1, you set it once in each zone, twice in total, rather than for every org.
One thing to know: it is applied when a tab loads, so if you have several tabs open, set it in one and refresh the others to pick it up.
It still does not follow your account automatically, which I understand is the real ask. I canāt promise anything on that yet, but Iāve noted it. But hopefully twice plus a refresh is a lot less painful than what you were expecting.
If you ever see it reset within the same zone, tell me, since that would be a different problem.
Lukas
Update on zoom, based on your feedback.
Two fixes are now out:
No more over-shoot on direction change: the zoom was carrying over acceleration that did not reset, so switching between zooming in and out could make one step jump far too far. That is the āburied in a module or thrown too far outā issue many of you flagged. It now resets when you change direction, so steps stay controlled.
Consistent speed on Mac and Windows: zoom behaved differently across the two; it is now aligned.
This should make moving around large scenarios feel calmer. It fixes the erratic jumps, though it is not yet a sensitivity setting or smaller default steps, so if it still feels too coarse after you try it, let me know here.
Thanks for the precise reports, they took us straight to the cause.
Lukas
Oh yeah you are right I was changing between us1 and us2. Now I tested with eu1 and and can confirm that all of my orgs in that region got the setting.
1 Like
Hi Lukas,
Thank you, genuinely. A couple of these have been on my list for a long time, so it means a lot to see them taken seriously.
On pan: the per-user setting is exactly what I was hoping for. Letting each person pick their own pan button instead of forcing one default is the right call, and it ended the friction immediately for the people I onboard. Thank you for shipping it.
On zoom: honestly, this one already looks sorted on my side. The wheel zoom is back to how it behaved before the canvas update, smooth and predictable, no more diving into a single module or flying all the way out in one notch. I checked across a few different browsers and accounts to be sure it wasnāt just my setup, and itās consistent everywhere. So whatever landed, it worked, thank you. Iāve retired the local zoom tweak we had, itās not needed anymore.
On Hebrew rendering: no formal ticket on our side, so let me give you something more useful instead. The consultant who handles our automations traced the exact root cause:
- The UI font is Inter, served subsetted to Latin only. Every
@font-facefor Inter declares aunicode-rangeover Basic Latin and Latin Extended, but none include the Hebrew block (U+0590-U+05FF), so Inter has no Hebrew glyphs to draw. - Most UI text (scenario names, folder names, sidebar labels) is set to
font-family: Interwith no Hebrew-capable fallback after it. So Hebrew characters fall through to the platformās last-resort font, which on Windows is Times New Roman, a serif. That is the broken look: Hebrew in a heavy serif next to the clean Inter sans, splitting mid-word in mixed strings (Latin and digits stay in Inter, the Hebrew letters jump to the serif). - Confirmed with Chrome DevTools (
CSS.getPlatformFontsForNode): on the scenarios screen, every Hebrew element draws its Hebrew glyphs in Times New Roman while the Latin in the same label stays in Inter.
On the fix: the right way isnāt to bolt on a generic fallback, since that pairs Inter with whatever system Hebrew font happens to exist and looks mismatched. The clean, standard multi-script approach is to keep Inter for Latin and pair it with a Hebrew companion that shares its style, served via @font-face with unicode-range: U+0590-05FF. The browser then uses Inter for Latin and the companion for Hebrew automatically, per glyph, and because they harmonise it reads as one cohesive system instead of two clashing fonts. Good open candidates that sit naturally next to Inter: Heebo, Assistant, or Noto Sans Hebrew. That would finally give Hebrew users the same polish the Latin UI already has.
Happy to share the exact selectors and findings with whoever picks it up. Would love to retire our local font workaround too.
Thanks again for the energy on this.
Aderet
2 Likes
Aderet, thank you, genuinely.
This is exactly the kind of report that makes a fix easy, and the root-cause work your consultant did is impressive.
Iāve logged it with the full diagnosis, and Iāll follow up with you directly on the details.
Thanks again for the feedback and offer related to the selectors and findings!
Lukas
2 Likes
Thank you so much, Lukas - I genuinely appreciate you taking this seriously and logging it with the full diagnosis. Honestly, my only regret is not flagging it sooner; Iād assumed it was already on the radar.
For context, this hasnāt been a niche annoyance. Hebrew falls back to the Times New Roman serif for essentially everyone working in Make in Hebrew, so itās been hitting thousands of automation professionals across the Israeli community ever since the new UI rolled out in late 2025.
In the meantime weāve been patching it locally with a small Chrome extension. Youāre welcome to look at the actual fix in the code - itās just a per-glyph @font-face fallback with unicode-range: U+0590-05FF, so Latin stays Inter and only Hebrew glyphs pick up a proper face:
github.com/arielmoatti/make-bugs-fixer
Looking forward to seeing it solved natively. Thanks again for the quick turnaround! 
2 Likes
Hi Aderet,
Thank you for taking the time to dig into this so thoroughly. The detail you and your consultant provided made all the difference.
We understand the impact for the Israeli automation community. Happy to share that our engineering has picked this up and is actively working on a native fix. Youāll be the first to know when it lands, and hopefully that Chrome extension can finally be retired for good.
Greetings from Prague!
Lukas