Hi there,
In the new Copenhagen release when I try to update the value on the Y axis, it subtracts the value instead of updating it.
Hi there,
In the new Copenhagen release when I try to update the value on the Y axis, it subtracts the value instead of updating it.
I’ve seen this happen too. In an existing document, not in a new one.
Hi folks, thanks for reporting this. We’ll look into it and share an update as soon as possible.
Hey folks, sorry for the delay. This is an intentional change. We wanted to clear up some positioning inconsistencies, so now we have:
– , it’ll be treated as an operation!Following the example from Alice’s video, type in -2000! to move the frame to that Y position.
In a similar example, if you have a layer in -50 and want to move it to 20, type in 20!
As always, nothing’s set in stone and the team will keep tracking this.
I see what you’re trying to do but in my case it looked like a bug
Obviously this is not the same as me typing -138. And conversely, typing 138 positions the layer at 138. Meaning one action has no mirror equivalent. Additionally: ! is shift+¨ for me, and it’s not close to the numbers row.
This kind of change should come as an experimental feature or get a little coaching box outside a major UI change. Values in fields are such basic a concept that you’ll get “if it’s not broken, don’t fix it” reactions.
My suggestion: make the math the secondary action to direct values (no grumpy users). Double the minus so that we don’t need to hunt for another key: --10 to remove 10 to the current value
I agree with Gael. This behaviour feels buggy and not intuitive.
From the latest update:
When you enter any value to an Inspector field with a math symbol (+ - % *) we’ll now treat that value as a math expression. For example, if a layer’s Y value is set to 10 and you enter -5, the Y value will become 5. To override this and set a negative value, add a ! to the end of the value (e.g. -5!).
This new behavior feels very confusing and counter intuitive.
I’m wondering, how do decisions like these get made? Do you have usage data that back decisions like these? I think it’s pretty obvious that anyone entering “-X” in a field is looking for that to be the new value rather than have it do math. If I want to do math then I’ll actually write math, like “10-x”. Why did you change from the previous behavior?
@samvermette Hope you don’t mind but I’m consolidating your topic with this one, just so we can better keep track of the numbers on this feedback.
To answer your question at least partially, one of the reasons this got changed was to allow for relative adjustments on multi-selections, so you could select three layers with different values and reduce each of their widths by 10, for example.
Regarding how decisions get made — we don’t do telemetry in the app to give us usage data in that sense, purely because we have very strong views on privacy and would rather not be constantly pinging some server with usage data. Also, quantitive data like that only tells us if someone is doing something, not if they find it easy or awkward.
We do however spend a lot of time speaking to customers (here in the forum, and elsewhere), keep a fairly extensive record of customer requests, and test things constantly with our own designers internally. So decisions don’t get made in a vacuum.
Regardless, we’re paying close attention the feedback this is getting and discussing it internally. As I’ve said here in the forum and elsewhere before, we’re not above making changes.
Re: usage analytics I’m totally on your side regarding privacy. But I think anonymous usage data can really help build better products in a way that qualitative feedback can’t. Like when you got rid of the up/down tickers in all text fields (which I saw here and on other platforms received lots of pushback), if you saw that 20% of your users were using it, you probably wouldn’t have removed it. I still think intuition and beauty needs to be the main tools of a product designer, but when removing features I think quantitative data are invaluable. My 2 cents.
Being able to allow relative adjustements on multiple elements is indeed useful, but again that feels like a secondary/advanced usage, so I would have given the advanced syntax for that behavior instead, i.e. entering “-x!” to do relative adjustments.
Hey folks
In the latest beta we’ve reverted this behavior, so:
Thanks for all your feedback on this one!
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.