Scaling objects by a percentage

[Ash]

[JohnMcK]

eeeeeeee . . . now that is 'andy

[paolo.limoncelli]

Calculations work for any input field.

Really handy!

 

I use it within Guide Manager.

[bpedit]

Nice feature, thanks for sharing. Any idea why the equals sign is necessary? Cinema 4D, a well constructed animation package, has a robust version of this feature, no entering of equals needed.

[Andreas Larsen]

Nice feature, thanks for sharing. Any idea why the equals sign is necessary? Cinema 4D, a well constructed animation package, has a robust version of this feature, no entering of equals needed.

 

 

Seems unnecessary to me too. Also when writing percentages the multiplier is also redundant - i.e. one should be able to type just "50%" and not "*=50%"

[Ben]

It's an question of consistency.  Some of our input fields will take numbers or percentages.  If you have a percentage field and you type "50%" do you mean 50% of the current value or an absolute value of 50%?  So, we use +=, *=, etc, to show that you mean 50% of the current value as opposed to just setting the value outright.  It works for all units types as well - I could type "+=5mm" into a field showing "3in" and it would do the right thing.

As you say, if you have a size field and you type a percentage, it would be easy to infer that you mean a percentage of the current value, but should we aim for consistency instead?

 

Also, the equals sign shows that it is a function.  The reason again is consistency.  For subtraction we have to use "-=" to perform a relative subtraction in order to distinguish against setting a negative value.  So, we adopted the same convention for all arithmetic functions.

[bpedit]

 I see the difference between what Cinema 4D does and what is shown in the demo. In the demo,  Ash has removed the contents of the input box so the equals is needed to signify that a simple replacement value is not what's intended. In C4D, the operation is done in-line with the existing value, no need for equals signs.

Well. . . it turns out that Designer can operate in the very same manner as C4D obviating the need for the equals sign! Well done. This method should also be shown in the tutorial, I find it easier and more logical. (More logical especially considering you demand the equals sign before the operand.)

[Raskolnikov]

IMHO this should work this way:

 

If I want to make it double big ... I should imput just    200%    or    x2  (100% and x1 it's the actual size)

 

If I want half sized ....   50%     or    1/2      or    x0.5

If I want it a half bigger   150%    or    +1/2      or     x1.5

 

If I want a the size to be third of the actual:    1/3

 

If I want a third bigger:     +1/3

If I want it third smaller:    -1/3

 

If I want it 20 pixels bigger         +20

If I want it 20 pixels smaller        -20

 

 

And no need of: = , * or /     (this app it's not an 80's calculator :D )

 

 

Just think of it, It makes sense and would be much easier (and faster) to understand for new users ;) as well as a timesaver for all.

[Ben]

But here is the problem.  If I have a size input box, with a current value of say "20mm" - I can currently type just a number and the unit type will be automatically applied.  So, I type "50" and it becomes "50mm" if the default value is in mm. This is intended so that I don't always have to enter the unit type.

 

If I want to do "50 / 2", I can, and it will work that out to be "25" then because I have given no unit type it takes on the default type, so becomes "25mm".

 

If I then type "1/2" - what is the correct answer?  What you will get following our present system is "0.5mm". Anything else would not be consistent with the previous example.  Why should the "/" symbol have a different effect depending upon a non apparent context?  Why should "1/2" be a special case compared to "50/2"?

 

The only exception I could possibly see is using a percentage value in a size input box - so typing in "50%" would give me a result of "10mm". But, as I have said, if I have a percentage value box with an initial value of "70%", what should typing "50%" do - give me a new value of "50%", or calculate 50% of 70% to give me "35%"?  This is not consistent, and I don't like the idea that an input box should have different behaviour based on the unit type it is showing.

 

So, we adopted the idea of relative functions using the equals sign to make clear that you mean "the current value add 5", for example. As has already been pointed out, you can begin typing after the current value if you want to do "20mm + 5", for example, instead of doing "+=5" (which will give you the same result).

[Raskolnikov]

Well , for sure you've think more of it :)

 

Thanks for answering!

[peter]

IMHO this should work this way:

 

If I want to make it double big ... I should imput just    200%    or    x2  (100% and x1 it's the actual size)

 

If I want half sized ....   50%     or    1/2      or    x0.5

If I want it a half bigger   150%    or    +1/2      or     x1.5

 

If I want a the size to be third of the actual:    1/3

 

If I want a third bigger:     +1/3

If I want it third smaller:    -1/3

 

If I want it 20 pixels bigger         +20

If I want it 20 pixels smaller        -20

 

 

And no need of: = , * or /     (this app it's not an 80's calculator :D )

 

 

Just think of it, It makes sense and would be much easier (and faster) to understand for new users ;) as well as a timesaver for all.

And so endeth the maths lesson :lol: 

[Tomtribute]

That was mighty helpful.  Thanks!

[ronniemcbride]

I'm sorry, here is a little side story kind of off topic on topic. I recently have been reunited with my favorite high school math teacher through online communication. I told her how I been making out in life and how I've done it without math being a huge "factor" . Lol well, that looks like that about to change. This input box going to take some serious abuse from me now. I'm going to prefer using the cinema 4D method BPedit suggested it just seems more logical for my febal little brain.

 

Ohh, and thank you Ash for these very well done and focused video. You waste no time getting to the point. Makes me think maybe I need to talk less.

[ronnyb]

the only other way I've seen it done is in spreadsheets where you start with the "=" sign, then start the function...

[SeerUK]

This actually makes a lot of sense to me a developer, I use these kinds of expressions a lot:

$foo = 5;
$foo += 10;

echo $foo; // 15

For instance.

[liquidquick]

my own personal preference would be for simplicity and intuitiveness (while still observing standard mathematical order of operations) over worrying about programatic consistency.  functions are great for programmers and accountants... not so much for artists and designers. 

 

if I have a percentage value box with an initial value of "70%", what should typing "50%" do - give me a new value of "50%", or calculate 50% of 70% to give me "35%"?

 

 

short answer: the new value should be 35. 

 

i think the reason this is confusing in this case is because you are using % as both the unit type and an operator... since you specified that this is a percentage value box the initial value should never be 70%, it should be 70 with a unit type of '%'.   the application will do with that number whatever it is programmed to do, and the user would naturally look at that as 70%, but separating out value from unit is an important distinction when it comes to mathematical operations in the user interface. 

 

lets take the property of transparency, for example, which would normally have a unit of %, and instead measure it in cookies.   the value of transparency can range from 0 cookies (fully transparent) to 100 cookies (fully opaque).  if we set the initial value at 70 cookies, then replacing the value of 70 with '50%' should always give the result of 35 cookies.   since the value of the input box should always evaluate out to a number, then the normal mathematical order of operations would apply if there are multiple operations input into the box.  if you actually want the value to be 50 cookies, not 70 cookies, you simply type 50 into the box... because the unit itself is already in cookies.  in this case, since the unit type is fixed (it MUST be cookies...) trying to input a different unit type, '50 donuts' for example, should be invalid, so no mathematical operations would be allowed and the new input value should be rejected.

 

ultimately, the end user shouldn't have to worry about the programming logic and the math behind the input box... since i'm not an excel junky or a programmer, it would never occur to me to use a relative function format for simple math... i just want the application to do all that for me.  case in point: when a client hands me a file that prints all the way to the edge, i have to give it an eighth-inch bleed... as long as i can just append '+.125in' to the value of the box and have it do the unit conversion and math automagically for me (since its a SIZE box, not a % box, so multiple unit types should be allowed) then i'm good.  if i have to figure that out myself, then i get all pissy.

 

-lq

[bpedit]

... as long as i can just append '+.125in' to the value of the box and have it do the unit conversion and math automagically for me 

 

 

You can do just that. In addition to the method specified in the tutorial, you can append an operation to the value currently displayed in the box by only entering an operator (+, -, *, /) and the amount to adjust. Be sure to leave the current value displayed for this method to work.