I don’t see the point of drawers unless the order of attached cables is functional. In any case they’re less like drawers and more like open shelves.
I’d suggest they be retractable from the base of the nod. Could expand and retract by double clicking on the associated node input label e.g. “Objects” label on the Render Scene to Window node.
Hopefully the lists of lists feature will get rid of the three(!) drawers on the **Copy 3D Object **node.
To my eye drawers as they currently stand do add considerable clutter to the graph. It occurred to me that Drawers could actually just be a unique node type exclusively for list construction with many input ports and one output port (think Grasshopper lists typed out on the graph as a node). So they could be positioned conveniently by the user, and with type introspection quite handy too if pulling values from far off nodes. Then i realised that one difference is that drawers are unique in that they can have inputs created and removed easily where-as Vuo nodes aren’t able to do that easily ATM, calculate expression is one of the few i can think of that rebuilds the ports to match the expression input. That’s why there is one node that has a 2 input and a 8 input version i guess (don’t recall which on though, sorry :-) ).
existing drawers:
replacement drawers closed:
replacement drawers Objects drawer (only) open (speculating that introspection of types is possible) I would think that dragging a cable onto the Objects port it would create a new entry in the drawer and add it:
I think the hardest part about reveal and conceal drawers may be in figuring out the animation of the cable jump from single input port to it’s place in the list of input ports. Maybe I should try an mockup an interaction animation in Origami/Vuo :P
Alterative list style. Grasshopper uses this including where you might want to type a list of immutable 3D point values or any type value which can be represented in text. This methodology could really handle an insert drawer for input port right-click option (i think insert drawer is different to insert input splitter, which it would also be great to have for refactoring convenience).
Uploaded the Photoshop file if people want to edit further.
yes i agree drawers should probably be in the open position on node creation. or at least one of them. if there’s multiple drawers at once in my mockup then i guess the drawers need at a minimum dividers and probably labels, e.g.
I hadn’t used the Copy 3D Object node before — there is a solid quantity of drawers there! I’d be concerned about the ambiguity between a single-value port and a drawer port, however, so I’d be less inclined to hide the drawer UI entirely by default, if it were up to me.
Perhaps a way to declutter a bit would be to either:
Enable the user to hide them (to make them appear like @useful_design’s mockups), with a contextual menu,
Make them automatically expand on mouseover,
Make them automatically expand when the user is dragging a cable with a matching (or easily convertible) data type, or
Implement one or more of the above points, but also give a drawer a new port shape. Event-only ports have a triangle, Event+Value ports have a circle, perhaps a drawer port could have a hamburger button style square. Or, if Event-only drawers are a thing, a circle and triangle version of the same thing to distinguish the two port types.
Love the idea of a Drawer node. Alastair – the 2/8 port nodes are the Input Selectors, the perfect example of nodes that could benefit from self-populating drawers (i.e., the Vuo next-gen version of QC’s multi/demultiplexers, esp. “indexed lists”). I could imagine an input selector loading by default with a Drawer node attached… Seems a no brainer that a drawer port would simply have its own distinguishing visual, like transform.
thx for reminding be about Input Selectors @jersmi. shows how much more work i have to do to learn Vuo, don’t even know what the ‘multiplexer’ is called ;-)
Noting this feature request for ‘drawers for output ports’. So in light of that, output to Drawer and the previously mentioned hand typed list. Idea being if you set the list type to a specific datatype you only have to enter numbers with spaces and the node auto-formats text with brackets and commas for points. Hit enter for a new item in list.
yes seems like three requests in one @jstrecker. If anybody seconds them I’ll create three separate feature requests (if that’s the preferred way to do it) or as one requests but organised more logically with your listing and images for each (if that’s the preferred way to do it). Maybe there needs to be discussion about how interaction occurs with them if drawers were collapsable. I’m not a fan of contextual menu items to do things one needs to do many times a minute. I’d be more likely to go for double click the input port to open and close the drawer… why defer it to a seconder order interaction when there’s perfectly available interaction already there with the base objects. Plus the auto-opening with cable-drag approaching previously mentioned.
In other words clicking or double clicking is not already use for anything, those opportunities should be used before right clicks need to be employed. Also right-mouse click already has a node level interaction, so you’d have to demarcate parts of the click zone for node settings and part for input port drawer interaction, which would be feasible but I don’t see why one would choose that route when double click is ‘easier’ and more intuitive all round (as in this is the thing i want access to (port drawer) — I double click on it (port) and it opens the drawer, like a folder or an app in Finder).
Out of interest @jstrecker, does input order in the drawers for the Render Scene to Window node make any difference? It’s not like QC where objects behind objects in 3D scene-space can be in front of objects they should be behind because their rendered is on a higher level, right? So objects could be fine in the one input port, and window settings, can’t see why order matters there either, but I didn’t make Vuo so I don’t really know and testing all the permutations could take a while :-)
