Language based formulas vs. node based formulas

[louis-rémi Babé]

Hi Toby and the Apparatus community!

I've just discovered Apparatus and I love its approach to parametric design!
I'm developing Prototypo, a parametric font editor. Right now we build our parametric characters by writing a large json file where we replace the coordinates in the outlines with mathematical formulas written in javascript, and made of constants + user-defined variables + operands. Currently we only present sliders connected to the variables to the users and let them customize the font (check the demo if you haven't).

The next step is to allow users to create their parametric characters and build complete typefaces themselves. The challenge is to provide visual and approachable tools for our audience, tools that will ultimately produce the kind of json files we write ourselves. This is very similar to (if not exactly) what you've done with apparatus, and the result is awesome I believe.
I presented Apparatus to the two other devs in the team, and they weren't as enthusiast as I am. They're much more familiar with node-based visual editors as an alternative to code, such as the ones found in this Blender screenshot, they believe it will be more approachable and easier. I believe that in our use-case, your approach represents an improvement over node-based edition, but I admit this is just gut feeling and not based on user testing or actual research. To me, code isn't something designers are necessarily afraid of. Code is language, and language can be much more powerful and natural to use than visual blocks connected with spaghettis. We just need to find a way to help designers learn code while using it, and also prevent syntax errors.

I'm pretty sure you didn't just wake up and thought of this new tool for parametric design. I'm pretty sure you have some evidences to help me convince the team to really consider your approach and its advantages over node-based edition.

Looking forward to your thoughts,
Keep up the good work,
Louis-Rémi

[Toby Schachman]

I think one or the other really depends on the application and the target audience. I've used node-based editors, and I think their advantages are something like:

1. When you're working with data types (video, 3D meshes, etc) where math notation isn't particularly natural.

2. When it's more natural to think of a stream than functions grouped in parentheses.

3. When it's particularly unnatural to think of names for intermediate "variables".

A particularly nice thing about most node editors is that you can hover on a "pin" and inspect the data on that pin. This is a big advantage over most traditional code editors, but as spreadsheets/Apparatus/etc show, you can and should show the intermediate evaluated values and then this is less of an issue.

Also, Apparatus "code" is mostly just one-line expressions. The kind of expressions spreadsheet users are familiar with. Math expressions are tedious to wire up in node-based editors, and usually you just use an "expression" node where you can type the expression in (this is what I do in Quartz Composer for example).

I think a good test for one or the other is to consider some sample scenarios, things/programs you would like people to be able to make with your tool, and then try to explain the thing/program to your friend on the whiteboard. If you start drawing boxes and arrows then go for the node-based editor, and if you write out expressions, go for text code. More likely you will do neither one and that is how you invent new interfaces ;)

Either way, I would recommend spending more attention on what the output of your tool looks like, that is, the canvas portion of Apparatus rather than the right hand side. This is the representation that matters, the representation that you want your designer concentrating on!

How can you show the most pertinent information within this representation? How can you build interactivity so that the designer can directly manipulate the representation that matters?

--
You received this message because you are subscribed to the Google Groups "Apparatus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aprtus+un...@googlegroups.com.
To post to this group, send email to apr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aprtus/48268963-cf1a-45b3-90bb-16b88972e678%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Young]

On Tue, Oct 13, 2015 at 10:55:18AM -0700, louis-rémi Babé wrote:
> I presented Apparatus to the two other devs in the team, and they weren't
> as enthusiast as I am. They're much more familiar with node-based visual
> editors as an alternative to code, such as the ones found in this Blender
> screenshot

> <http://wiki.blender.org/uploads/thumb/5/57/Dev-texnodes-fractal.png/640px-Dev-texnodes-fractal.png>,

> they believe it will be more approachable and easier.

Hi all,

New listener, first-time caller. :-)

Louis-Rémi, I think it's interesting that the devs on your team favor
a node-based visual editor for prototypo.io. Presumably the devs enjoy
writing code or, at any rate, habitually do write it? I am curious
whether they picture themselves using the node-based editor (NBE) and
preferring it to code, or do they have a hunch that users who are not
like themselves (i.e., users who are not coders) will prefer the NBE?

I have used a couple of node-based programming systems, National
Instruments' LabVIEW, and a program called ControllerMate for
customizing key mappings. Neither made a good impression on me, and
I know that I am not the only one. In my experience, if you mention
"visual" and "programming" in the same sentence, programmers frown and
ask if you mean something like LabVIEW, because they don't like things
like that. Even if you don't mean something like that, you have to
take pains to explain how your meaning is different, because the bad
connotation is there. That's why I'm surprised to hear that the devs
favor an NBE.

Dave

--
David Young
dyo...@pobox.com Urbana, IL (217) 721-9981

[William Taysom]

Louis-Rémi,

Prototypo has a very nice demo, looks like a nice tool for branding.  As Toby said, first consider what you want from your tool, then try to find a form that delivers.  Apparatus, like a spreadsheet, allows for bindings between properties but mostly hides the graph of connections.  Names and mouseovers help show coreference, but there isn't a view of the whole graph.  Node-based editors, on the other hand, make the relation graph explicit, but often hide structure in exchange.

All about tradeoffs,

William