Direct Tweaking in Twoville
A student and I working on tools for composing SVG files. The scenes are programmatically generated, but the geometric properties can be tweaked via direct manipulation. In other words, the user can drag on the shapes to modify both the scene and the source code. Consider the following program, which plots a rectangle.
Select the rectangle and you’ll see controls appear. Click and drag on them to change the size or corner position. That’s direct manipulation.
Initially, we thought to just update the geometric property, which we’ll call $p$, by replacing its original value completely with a new value derived from the mouse position, like this:
This simplistic replacement scheme seemed reasonable until the expressions got more complicated. Suppose the property $p$ was the result of a sum.
Should the entire $a + b$ expression be replaced with a new value derived from the mouse position, abandoning the addition operation? Or should we be more selective about what we update? We have decided to be more selective. The $+$ must have some semantic meaning to the designer, and we want to preserve it.
I now enumerate the kinds of expressions we target and describe how we selectively update them. You can probably stop reading. The primary audience of this post is my collaborator and me.
number
When the expression is a number, we just replace it with a value derived from the mouse position. This is the only situation in which we replace the entire expression.
expression + number
When the expression is an addition operation, and the right operand is a number, we update only the right operand—no matter what the left operand is. For instance, the expression could be $n + 2$. We assume that 2 is some magic number waiting to be tweaked.
We know that the property is computed as $a + b$. We have $p$ from the mouse position and $a$ unchanged from the original expression. From these we can solve for the new $b$.
number + non-number
When the expression is an addition operation, the right operand is more complex than a number, and the left-operand is a number, we update only the left operand. For instance, the expression could be $2 + n$. We assume that 2 is some magic number waiting to be tweaked.
We know that the property is computed as $a + b$. We have $p$ from the mouse position and $b$ unchanged from the original expression. From these we can solve for the new $a$.
expression * number
When the expression is a multiplication and the right operand is a number, we update only the right operand—just as with addition. We compute the new $b$ from the mouse position and the unchanged left operand $a$.
But what do we do if $a$ evaluates to a 0? My current leaning is to fall through to the default case described below.
number * non-number
When the expression is a multiplication, the left operand is a number, and the right operand is more complex than a number, we update only the left operand—just as with addition. We compute the new $a$ from the mouse position and the unchanged right operand $b$.
But what do we do if $b$ evaluates to a 0? My current leaning is to fall through to the default case described below.
expression – number
When the expression is a subtraction and the right operand is a number, we update only the right operand. We compute the new $b$ from the mouse position and the unchanged left operand $a$.
number – non-number
When the expression is a subtraction, the left operand is a number, and the right operand is more complex than a number, we update only the left operand. We compute the new $a$ from the mouse position and the unchanged right operand $b$.
expression / number
When the expression is a division and the right operand is a number, we update only the right operand. We compute the new $b$ from the mouse position and the unchanged left operand $a$.
But what if $p$ is 0? My current leaning is not let the manipulation update the expression in this case. As the mouse keeps moving, $p$ will keep updating and we may re-enter defined territory.
number / non-number
When the expression is a division, the left operand is a number, and the right operand is more complex than a number, we update only the left operand. We compute the new $a$ from the mouse position and the unchanged right operand $b$.
But what if $b$ evaluates to 0? My current leaning is to fall through to the default case described below.
expression ^ number
When the expression is an exponentiation and the right operand is a number, we update only the right operand. We compute the new $b$ from the mouse position and the unchanged left operand $a$.
But what if $a$ is 1? We’ll have $\log 1 = 0$ in the demoninator. There’s no way to raise 1 to an arbitrary value. My current leaning is to fall through to the default case described below.
number ^ non-number
When the expression is an exponentiation, the left operand is a number, and the right operand is more complex than a number, we update only the left operand. We compute the new $a$ from the mouse position and the unchanged right operand $b$.
But what if $b$ evaluates to 0? An exponent of 0 can only produce the value 1. My current leaning is to fall through to the default case described below.
default
If the expression matched none of the above cases, then instead of replacing the expression with a value derived from the mouse position, we preserve the designer’s original expression but tack on an offset $\Delta$. We compute the new $\Delta$ from the mouse position and the unchanged expression $e$.
This case kicks in when the above rules land in undefined waters or when the expression is a function call like $\cos x$, a subscript into a collection, or some other crazy operation.