Vuo redesign - Nodes

[Bodysoulspirit]

@alexmitchellmus thanks man ! I really appreciate the kind comment !

Yes an unified UI is something important in a software. I have made some custom editor buttons and some stuff for myself.
I will try some projects and mockups for the editor when I have time, takes a lot of time ;)

Yeah I remember your comment on the lib cinders GUI in the UI Feature Request. Another style, even flatter, all in square. I like it too. This was an attempt to roundness here, and I will try to add some other UI parts on the same style in this thread, perhaps we should separate topics by style, like you could create a flat square design one ;) Perhaps will try one too.

Design is very subtile and subjective and always evolving. Guess in a far feature it would be great to get some customization options to match all users styles with some node roundness options, opacity, perhaps font, custom canvas backgrounds with tiled images, whatever, but I guess there are some more important stuff for Vuo in a near future.

Just wanted here to give the default nodes a fresh look too and tried to match the flat and simple UI we see a lot nowadays. I personally love those a lot ;)

Thanks again ;)

[alexmitchellmus]

@Bodysoulspirit, yeah, the “to be implemented” UI nodes for “buttons” “sliders” etc would look great with this UI design. I don’t think square would be good- but clean curves like you have and block colours is fantastic!

[Bodysoulspirit]

@alexmitchellmus thanks. Don’t know what the example default UI parts will look like with that feature request but @jstrecker recently commented there with some good news : customization ! ;) To satisfy all the tastes ;)

Comment on UI nodes … here Jaymie’s comment

[Bodysoulspirit]

@jstrecker

If one would want not to increase the size of the node at all, one could still find some in-between solutions. So that it wouldn’t look as good to me, but still pimps up the node in my opinion.

The node size was increased for 3 reasons, first for more node roundness, secondly to increase the line between the node title and the node class and at last to add a little spacing between the port labels and the node bottom and top.

If I remove those and keep the orignal spacings, and reduce my node roundness down by over 75% to get a roundness of 100 points (on my remake of the original node I got smtg like 30 points on the original Vuo node so this means I somehow do 3x the original roundness) I still can get something to look pretty in my opinion ;)

See the images below, the gif to shows the nodes have the same sizes :

So these changes include :

• More roundness (± triple).
• Colors in full alpha but with saturation set to 30% - 50% and lightness 100% (nodes in full opacity).
• Removed arrow shaped part of the port values (which saves space by shrinking the node overall node width).
• Real ovals for single value ports.
• Real ovals too for empty ports or color ports (to ensure a solid harmony between all ports).
• Stretched ovals (perfect rounded rectangles) for ports with more values.
• A new fire on start / data only port that consists of a rounded triangle inside an oval.
• The alignement of the fire on start port between the middle of the title and the node class text lines.
• Removed the border on the node body.

This doesn’t include other things I’d consider like another straighter font, some spacings or unified value + cable ports.

[jstrecker (Jaymie)]

@Bodysoulspirit, I appreciate all the effort you’ve put into this, particularly in trying out mockups with different parameters.

I have what may be a naive question (I am not a designer): In UI design, how does one find a balance between the appeal of harmonizing the visual appearance of parts vs. the cognitive load of identifying the differing functionalities of parts? This has come up in some of the debate over flat design. In terms of Vuo, I wonder, for example, to what extent event-only ports should be differentiated from data-and-event ports. Is there any way to tell in advance if changing event-only ports from a triangular outline to a circular outline would help or hinder usability? Are there UI design principles that guide such decisions, or does it have to be decided by usability testing?

what was the original purpose for telling apart stateful / stateless?

@alexmitchellmus, the stateful indicator was part of a larger effort toward being able to “read” a composition’s functionality entirely from the canvas so that you could tell exactly how it would work without having to go hunting for hidden settings. Some parts of that effort worked great and we’ve kept them around, e.g. displaying constant values on canvas. Other parts did not work so well, based on the feedback we got about “visual clutter”, so we eliminated them and no longer have a strict every-setting-is-visible paradigm.

Currently I use it just to know what the node is doing (it remembers some value) but is there a better way to use it?

Not that I know of. That information is also in the node documentation.

You mention that many nodes were updated to stateful for performance reasons- so has it kind of lost its original meaning?

Yeah.

[useful_design (Alastair)]

And yes, interactive mock-ups do take a heck of a lot of time Christain! I tried to mockup sub-comp inside parent comp as window in window back in the day using QC and it was a shit-fight getting QC to stay responsive and not grind to a halt or not behave in flaky way.

[useful_design (Alastair)]

I have what may be a naive question (I am not a designer): In UI design, how does one find a balance between the appeal of harmonizing the visual appearance of parts vs. the cognitive load of identifying the differing functionalities of parts? This has come up in some of the debate over flat design. In terms of Vuo, I wonder, for example, to what extent event-only ports should be differentiated from data-and-event ports. Is there any way to tell in advance if changing event-only ports from a triangular outline to a circular outline would help or hinder usability? Are there UI design principles that guide such decisions, or does it have to be decided by usability testing?

There’s no one particular principle i can think of which adjudicates on this matter, and even if there were, design has many manifestos and philosophies around how function and aesthetics should be done. I guess that’s what makes design interesting. In Architecture people have spent their whole lives developing concepts around the fusion and/or disruption of functional, cultural and aesthetic needs/traditions/principles.

One of the better known design schools of thought in the digital world is the 20s/30s German Bauhaus school of early modernist design synonymous with minimalism and and the industrial aesthetic. In this school, less is certainly more (an ideal of Mies Van De Rohe the third and final Bauhaus director ). But that less is often an excess of materialist delight, extreme engineering feats (big column spans, mullion thinness, big glazing dimensions, self-supporting circular staircases –> SJ etc etc) and luxury, not an interest in efficiency per se. Or, paradoxically, even functional effectiveness much of the time. When we talk of reading a design, it has a specific meaning in Visual Programming, as we’re actually trying to read the code (not read it for beauty or semiotic delight) and what for one person might be a ‘linguistic aid’ to parsing the composition will for another person be clutter. Just as there are many coding styles in text programming although most agree spaghetti code is bad, which QC and Vuo can start to appear like without macros/sub-compositions and a sense of flow and order in the layout. People like Jonny Ives, Jobs etc first received Bauhaus through objects like the [Braun calculator][2] and the Dieter Rams catalog has become something of a temple of design sense at Apple and elsewhere because of it. Of course in the Architecture world things have well moved on from Bauhaus/minimalism completely (rejected in 80s for it’s coldness and banality in the hands of the many) but it’s still going strong in ITC (and graphic design more generally to some extent.)

So with that little historical interlude, i’d suggest that it really depends on your perspective, but I want a UI/UX to work nice (functionality is fluid and somewhat anticipatory of my needs during interaction events), look nice (just as attractive to the non-user as the user would be a good starting benchmark), behave nice (no gotchas and over-sensitivities or peculiar hangups (persistent datatype locking for example on Share Value node with no visual cue as to the datatype mode it is in)) more so than I want to get more on the screen or follow some in-principle overarching style rule or dictate.

To me using more screen real-estate to do things nicely is okay, and that’s often the trade-off often comes down to — @jstrecker mentioned it above. I don’t want wasted space, but i don’t consider nice design a waste of space. I’d love to see QC style macros or (double clickable) local sub-compositions that behave just like they do in QC to solve space and readability issues first up. Is that a feature request yet, because I made a presentation on it for Vuo that i’d be happy to post for a discussion start point?

[2]: Ghostly International  

[useful_design (Alastair)]

On the question of ports, I recall the pre-alpha discussion of ports and how they came to be half-outside half-inside. Jaymie (@jstrecker) made the (true) observation that in QC sometimes it’s very difficult to tell which noodles attached to input ports lead to which other patches and output ports. This is the case in curved and straight noodle modes. The solution that was arrived at to my mind didn’t get it right; to my mind the reason this happens is a lot to do with noodles coming in at extreme angles to the horizontal when using straight nodes and they all tend to overlap making intuiting the port connection difficult. When they come in straight and don’t criss-cross it’s much easier to see which port is with which noodle. Curved noodles make them come in closer to the horizontal but it tends to make them criss-cross also.

The same actually happens in Vuo, if many wires come into a node on a steep angel, even having the input ports in a sort of levitating position does little better at distinguishing the wire/port pairing. I’ve grabbed screen shot examples of this in the past but resisted posting them as nobody seem ready for a complete redesign discussion and i felt it was probably a thing for Vuo 2.0. I looked at ports inside outside and half-in half-out before I even saw what nodes ended up becoming and my feeling was the visual appearance outweighs any ideas about ‘reading’ cables because it has very little influence on that from my research. Something like a rainbow cable mode where selected nodes have rainbow cable (think old computer ribbon cables) to highlight connections would be miles more effective than any nuancing of port aesthetics I was able to come up with.

I’d be happy with light grey lines for ports like Max and in the example above perhaps with dark grey lines for walled ports. I think the inputs could do with a tad more vertical spacing, especially if vertical lines are used for port demarcation and the Node headings are still large than require to my eye.

something else I thought might be useful in “reading” compositions was a set of symbols for datatypes that could at least be next to the node output ports. Symbols for Binary, Text, 2D point, 3D point, 4D point, List of…, Integer, Real, Enums (new datatype for UI elements), Mesh, Image, User authored nodes could invent datatype symbols for new datatypes or just use a generic “Custom” datatype symbol. This got argued strongly against at the time so I dropped it, but i think it would greatly help particularly new users and when viewing 3rd party comps and sub-comps.

[jersmi]

Nice discussion. I think good visual design is well worth the effort.

@Bodysoulspirit, I appreciate all the iterations! I think your last version is getting somewhere (smaller ports, less roundness, better use of space, smaller is still better, imho…) I’m sympathetic to your style – I’m a fan of Benetton/Colors magazine, of Swiss Style, contemporary design in general. I can’t think of anything skeuomorphic I like offhand, I’m sure there’s something…

I think Jaymie takes it to the heart of the matter:

In UI design, how does one find a balance between the appeal of harmonizing the visual appearance of parts vs. the cognitive load of identifying the differing functionalities of parts.

With this in mind, I think I would not go all the way to flat design for Vuo (or rounded everything). This is the classic form follows function concept.

Space

I think well-handled spatial cues can help the “cognitive load” – things to separate parts, color (of course), as well as other elements like stroke/outline, texture, gradient, shadow (with restraint!). Admittedly, I usually like some well-conceived use of “space” in design, usually balancing 2D and 3D, sometimes 4D, too (ie, space + time). (Resolving the design “space” issue is often a tough problem, but that’s another discussion. In short: feeling space gives me joy).

There’s a piece of audio software called Plogue Bidule I still appreciate for it’s minimal visual approach to node based stuff. It uses two things worth mentioning (well, three): a tiny outline around nodes, and a gentle gradient top to bottom (and the gray/blue easy on the eye default palette). I think these subtle elements help. (This software is maybe 15 years old, btw.)

Regarding color –

I’d like to see @useful_design 's idea for colored cables to help the spaghetti factor. Sounds promising.

I’d make the difference between the oranges and greens currently in Vuo more obvious.

I’d vote for an agreed upon node set palette (4 or 5 more colors?), then customizable palette for users (ie, OS color picker).  

[alexmitchellmus]

@jersmi are you a regular user of PB? I used to be but I just couldn’t get my head around the node & linked parameter model they use. (you know how you can link things between nodes without cables- or even a hidden cable- or even a spooky send- you just “link” them)

I do have a very soft spot for PureData, which I don’t think will ever progress past its ‘ageing’ interface- although it would be super cool though if they did a quick update!

[jersmi]

Yep, I love Bidule! I cut my teeth on node based stuff in Bidule. My path: Bidule → Quartz Composer → Vuo. Bidule is a great tool, props to the devs, Plogue Art et
Technologie, in Montreal.

[useful_design (Alastair)]

@jersmi
regarding node and cable colouring (and much much more) please see my Feature Request for Vuo editor Scripting and/or Macros. Here i suggest that canonical and user defined colour rules could be toggled between at will if there were scripts or rule based macros.

regards Plogue Bidule it reminds me of the synth I built in 80s had 30+ fader knobs and multi-postion switches and I never bothered to buy the 3M sticky backed bromide for the front panel because I had pretty much memorised all the dials. I can still recall the functional blocks of dials, if not what each one and each position on each one did. I’m all for minimals long as extra info is close at hand.

[jersmi]

Cool FR, @useful_design. (<-- how do I get rid of the space between “useful” and “design”? I don’t type it this way…)

I should clarify about the Bidule reference – I was trying to give an example of something that is not flat design, something I have found effective where the nodes have an outline and a gradient (and an easy on the eyes color scheme) that helps the user by creating a bit of perceptual space. This is not a new idea – come to think of it, the last version of the QC editor used these concepts (and the change in design probably made some unhappy).

I would not necessarily suggest a minimal approach for Vuo – it’s not appropriate for the tool. I’m all for “form follows function”, which I think is at the heart of Jaymie’s post.

You do bring up a good point with your 80’s synth example – when you get to know a tool you need less visual cues. Your scripting FR might allow us to make minimal setups to save screen space.

[jersmi]

@Bodysoulspirit designed a flat ui which I think reflects the modern and streamlined Vuo design philosophy perfectly. It is pleasing and simple. It gets rid of clutter and unnecessary info (stateful bar).

Cheers to this, and the convo. I appreciate your work, @Bodysoulspirit, for the love of this awesome software.

I haven’t looked closely, but it looks like it might even be possible to “skin” the Vuo editor, using command line tools or something?

[alexmitchellmus]

I also think that if/when a change happens that it would reflect in some ways a re-booting of the Vuo brand. Just like OS X’s iOS style re-vamp, from then on all screenshots will look different, and older screenshots will be dated.

Taking and sharing screenshots is very important, because it is a universal way to share the power of the software- and the way in which it looks and functions. Just check out the ‘screenshot’ gallery in many software projects.

People don’t even need a Mac to see how it works. That’s also why @Bodysoulspirit’s mock up is great! :-)

[Bodysoulspirit]

@jstrecker

I have what may be a naive question (I am not a designer): In UI design, how does one find a balance between the appeal of harmonizing the visual appearance of parts vs. the cognitive load of identifying the differing functionalities of parts ?
Are there UI design principles that guide such decisions, or does it have to be decided by usability testing ?

Great and important question !

I’m not a professional designer neither, only a hobbyist. I don’t know the « HOW » answer and I don’t know if there is a definitive answer to that (as @useful_design wrote) ! One thing I’m sure however, is that the balance you mention can be found ;)
I guess through discussions, tests, learning and inspiring ourself from others etc.

This is surely a sub-question of the big « Functionality VS Beaty » balance question of life. Yin & Yang, hot & cold, light & darkness … ;)

This has come up in some of the debate over flat design.

But this balance you mention isn’t isolated on flat design is it ? I think flat doesn’t necessarily mean over-simplified. Flat is a style, simple rather a method. I guess one can make simple skeumorphism and complex flat design ;)

In terms of Vuo, I wonder, for example, to what extent event-only ports should be differentiated from data-and-event ports. Is there any way to tell in advance if changing event-only ports from a triangular outline to a circular outline would help or hinder usability ?

Don’t know. You think to put the triangle inside an oval would make it harder to read ?

I don’t like the actual triangle ports for several reasons, but they may be personal and subjective. I think it doesn’t fit with the actual node already. The actual node already has some slight rounded borders that feel so different from the sharp edges of the Event Only Ports.

I don’t claim this design mockup is perfect or totally finished. Design will and has to evolve.
The triangle inside the oval was only a solution between others I came up later with because, as written before, I couldn’t get to make a triangle that would have a border, would be the same height and width as the other ports and would be rounded to match the style submitted here.
My mockup evolved as I understood how the actual node was built. The first mockup was a big rounded triangle. I realized it was too big, so I tried to shrink it. Then I realized the Editor had some borders implementation method I should try to make use of. I also tried to make a Event Only port that could be achieved with code only. I guess drawings are different from what you can achieve with code.

And that’s why I came up with the triangle inside the oval. That way :

• It would match the overall style and harmonize.
• Still be differentiated from the Data ports thanks to the triangle inside.

But any other ideas welcome.

I also keep in mind the thin cable for Event Only helps with reading the composition. Hard to oversee the difference between the cable thickness IMO.

Regarding @useful_design’s concern about Data Types

something else I thought might be useful in “reading” compositions was a set of symbols for datatypes that could at least be next to the node output ports. Symbols for Binary, Text, 2D point, 3D point, 4D point, List of…, Integer, Real, Enums (new datatype for UI elements), Mesh, Image, User authored nodes could invent datatype symbols for new datatypes or just use a generic “Custom” datatype symbol. This got argued strongly against at the time so I dropped it, but i think it would greatly help particularly new users and when viewing 3rd party comps and sub-comps.

on this mockup the Fire/Event Only/Refresh triangle is inside the round port, one could imagine rounded ports to include some other symbols to notify the users of other stuff, like for example that a certain Data Type is set.

This would however be way less important for Data Types if Data Types could be automatically reset to default when disconnecting a cable or if being able to update itself automatically to the new Data Type when a different Type Cable would be connected.

The question somehow is « should we use unified rounded ports with different symbols in them for different stuff or should we use different shapes for all the different stuff we want to differentiate » ? Should we change the shape of the ports or should the round ports include symbols.
I like the idea of unified ports with symbols, as ports already use text, numbers and colors within them.

[Bodysoulspirit]

@jstrecker

Realized the borders in the Vuo Editor where centered and not put inside or outside, which led me to the possibility to make a rounded triangle fire / event only port.

Don’t know which I prefer, I like both the triangle in an oval or a rounded triangle.

The rounded triangle here however is :

• Shrinked down a little to match the same size of the oval ports (with borders).
• More equilateral then the original which is isosceles.
• Horizontal aligned with the middle of the node ends.
• Vertical aligned between the node title and the node class.

The border colors could be either like the cable ports, aka the color of the node header background (middle dark gray) :

Or white :

But I guess I wouldn’t use different colors for the borders wether they are as main refresh ports or as input / output ports, or let the node border follow the port shape

[Bodysoulspirit]

Thanks for the nice comments and thought @alexmitchellmus @jersmi and @useful_design

I think people nowadays care about how a software looks. Branding has never been more important than today. I see it in all the new softs coming out.
Sketch for example, compared to Illustrator. Recent designer love how Sketch looks like and love how easily some things can be achieved compared to Illustrator.

Again, a good balance has to be found between the time spend on functionality of the software and how it looks.

Yes alexmitchellmus, as you say,the iOS and OSX styles change and change with the current design moods of the era. I think a software has a part of its own, his own signature that has to be recognizable over the years, but should be able to adapt its signature to the current trends.

It’s obvious that all brands see their logos update and all softwares see their UI updates over the year.

But I don’t want the team to work too much on the design neither, as some great work over functionality can be done too. That’s why I tried to make some changes that would start from the actual node and gain some big changes with few work as shown in the steps.

[Bodysoulspirit]

@jersmi

I’d make the difference between the oranges and greens currently in Vuo more obvious.
I’d vote for an agreed upon node set palette (4 or 5 more colors?), then customizable palette for users (ie, OS color picker).

Agree with both the nodes and the cables, they look too similar, even when colored.

This Mockup submits the idea of full alpha colors for the nodes (and cables). I don’t really know why the Team sat the Nodes / Nodes Colors to some transparency, perhaps to see a node behind the other, but as I mentioned earlier, I personally don’t overlay nodes (don’t know if other people do) and think this adds some clutter and make the colors look pale and washed.

I would, as written before, use full alpha, full brightness (or down to 97 % for some more color variations), with some saturation set to 35% - 50% to ensure a good view of the port label texts.

My mockup increase the cable thickness difference between data / event cables. Bigger Data cables could also mean they would be more visible (and their color therefore too).

I totally agree with a OSX color picker for custom node colors. I remember some Facebook discussion about this. I could make the nature request for it. I remember Steve writing about red being omitted because it would be used to report some Node Error but I guess there could be another way to report the error, a red border or anything else.

Current Alpha :

Solid :

Big Solid Cables :

[Bodysoulspirit]

Some additional design parts I made regarding this Redesign Project.

1 - The borders and the cable ports.

What I’d do is simply harmonize all the different borders sizes on all ports !

If I’m right, the Vuo editor uses some borders on the node body, on the value ports and on the Event Ports etc. Those are set to be centered middle (nor inside nor outside).

The borders on the cable ports are needed to highlight the port from the node body they are on, these could be removed in case the Cable + Value ports would be unified and placed along the node instead of hand on top). So in case the cable ports would not be unified with the value ports, the borders on the value ports (including on the event only ports would be the only borders left visible).

1a - As already mentioned : Removed all Node Borders.

1b - Set all cable ports (including event only ports) to have a middle border that matches the color of the node header (or event. white for the event only triangles).

1c - Set all value ports to have a middle border too, BUT FROM THE COLOR OF THE VALUE PORT ITSELF. This allows all the ports to have the same height and harmonize. So in fact all ports have borders, but all value ports borders are “invisible” because of their color. Exception could be kept for the “Color” port if wanted, but the light gray would already be sufficient.

This method also allows a better reading for the “Value Summary” for example because the text isn’t framed inside a border that seem to shrink the value port.

I also believe the attached cable port to the Value Summary looks better now. Same height.

The actual borders :

Actual Zoom :

Harmonized borders :

Harmonized Zoom :

2 - The node alpha on ports.

I also think full alpha for the nodes will make the ports look better. Right now we can see through the port and see the cable end.

Actual alpha :

Full alpha :

As written before, here you can see the difference in the cable thickness too.

3 - Roundness Smoothness.

A zoom on the actual roundness of the nodes and ports shows the vector is calculated using 3-5 points. It could perhaps be upgraded a little bit if more roundness was added, lines edges could become more obvious.

An actual zoom :

More line points (more then needed though) :