Hi guys !

Opening a topic for the design of the nodes here.

My first attempt here, may be more to follow.

Added a simple app in a comment below that loads the nodes onto a canvas as draggable layers so you can get a closer feeling Comment

Comments

Unified cable port + value

Bodysoulspirit's picture
Submitted by

Unified cable port + value ports as when you connect a cable the value port disappear, no need for 2.

Even if "Show values even when cables are connected" is a feature request, one port is still enough as it could be expanded to show the value while having the cable connected at its end.

Hey people !

Bodysoulspirit's picture
Submitted by

Hey people !

Exported the steps I made to get from the original node to the final result. Each step is small but still changes a lot and could be used progressively or separately as a roadmap.

I have updated the "Event only" ports since the original submission as I understood I had been drawing them too big, they should be no bigger then the data + event ports, but that sharp triangle is hurting my soul ;) I love it smooth and round.

Here we go ...

A - The Original Node I tried to recreate in vector drawing

B - Rounder Node + A little growth - No bottom wall bar.

I like both square and rounded stuff, but if I choose round, I like round roundness ;) 10 is too few to me. The node is slightly expanded to allow the higher roundness (just a little).

I also removed the bottom bar that displays a node with wall. I believe this is useless and only adds clutter. The walls on the ports are useful enough !

C - Colors

I'd use solid colors, with HSL in full brightness and a saturation of about 40-50 to ensure a good read on the port labels. I wouldn't make the node transparent as they make the nodes look so pale :(

D - New Event Only port design + Rounded value ports.

As I couldn't get to make a rounded triangle with his border for the event only port I put a rounded white triangle in an oval. That way the design is consistent with the other data ports but still is easily recognizable by the big triangle in the middle. It is now aligned with the space line between the Node title and node class (the original Vuo node alignes with the top of the duo class characters it seems).

Same here. I'd prefer round borders for the value ports too (or go full square rather then 10px roundness). I don't know why the value ports would need an arrow shape on their right part so the port now is a full rounded square. The value ports also have more equal scales. An oval for empty values and for single number values, expands on wish for each added characters.

E - The Font

I'd use another font for the nodes then Signika. One with less serif and straighter characters to get a simpler read. "Avenir" set in 'heavy" for example !

F - Removed the node borders.

No need to be. Moderner look without, looks great on both clear and dark mode (the ports still have borders here).

G - Colored ports on cable connection.

This is more about fun. Not the most important part to me but it would be cool if the connected ports would match the color of the node. Light gray for unconnected cables, color matching for connected ones. Has a functional use too though.

H - Unified Value Ports + Cable Ports.

OK this is the part that could require more work from the original nodes as it changes the place of the ports. so this could be added later.

As already written, I think those different ports could be merged as when we connect a cable the value port disappears. If the FR to show values even with connected cables would be implemented, the cable could just connect at the left side of the value port.

This allows to remove all ovals ports from on the sides of the nodes to ensure a simple and readable UI. The ports also have been expanded a little, they touch each other, no pixel between them anymore, an endless node hug ;)

At this level, the borders on the ports could be removed too !

Walls could be shown with just a bar of the height of the port inside the node (or outside, on the port).

My god ! Spent some hours of work here ! Hope you'll like it ;)

I'm wondering if we still

jstrecker's picture
Submitted by

I'm wondering if we still need the stateful indicator (bottom bar) on nodes. Starting a couple(?) releases ago, we made a lot of the image generating/filtering nodes (e.g. Make Checkerboard Image, Crop Image) stateful as a performance optimization. That this apparently didn't confuse anyone suggests to me that folks aren't using the stateful indicator as they "read" compositions. What do y'all think?

The big rounded corners on nodes are happy and friendly, but they take up extra space. Is it worth it? Thoughts?

@jstrecker thanks for comment

Bodysoulspirit's picture
Submitted by

Jaymie (@jstrecker) thanks for comment ;) Appreciate you read the topic and watched the ideas ;)

Stateful indicators are not important to me. I don't even know that is what the bottom bar was for ;) But that's my opinion. I'd be happy to hear if other users need it. Could try to design another solution then the bottom bar or try a redesign of it.

The rounded corners added pixels on the node size but not that much. Will add an overlay image of the 2 to get a better idea of the difference. Will also try a real square redesign. Combining value + cable ports would also reduce the node's size ;)

I tried to sort the steps on how much they added and changed the nodes : rounded corners, colors, event only ports ...

Can also send the team the vector files.

@jstrecker made some

Bodysoulspirit's picture
Submitted by

Jaymie (@jstrecker) made some comparison images.

1 - The node Width

The Width of the node could be even sized down thanks to the shrink of the arrow shaped port value boxes.

2 - The node Height

I guess the height of the node could be expanded by 1/4 grid height only.

Here is a sample mockup with the node size how it looks in Vuo on my 13" screen with the node zoom set to default.

@jstrecker

Bodysoulspirit's picture
Submitted by

Jaymie (@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.

Personally I like the

alexmitchellmus's picture
Submitted by

I REALLY like the newest design above! Well done @Bodysoulspirit!

Jaymie (@jstrecker) because I know Team Vuo has thought through everything- what was the original purpose for telling apart stateful / stateless? 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? You mention that many nodes were updated to stateful for performance reasons- so has it kind of lost its original meaning? The other thing is that if someone is really interested in what the node is doing- they can check out the source! ;-).

Maybe it would be better as I said before to place a symbol for stateless nodes?

After looking at the last design more- I think something needs to be done with the event triangle? (Don't know what though!)

@Bodysoulspirit have you though of designing a matching UI set (for use within the new UI Node?). I really like your simple clean design!

@Bodysoulspirit I posted a

alexmitchellmus's picture
Submitted by

@Bodysoulspirit I posted a while back in the UI thread an image of libcinders GUI elements. Although they are very sparse and dry, maybe something along those lines could work nicely? You are already on the same track with simplifying the nodes- I think a simple elegant UI could really make Vuo stand out! (I like the new 100 point roundness, maybe use this throughout the UI?)

@alexmitchellmus thanks man ! I

Bodysoulspirit's picture
Submitted by

@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 ;)

@Bodysoulspirit, I really

jstrecker's picture
Submitted by

@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.

I have what may be a naive

useful design's picture
Submitted by

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 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 — Jaymie (@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?

On the question of ports, I

useful design's picture
Submitted by

On the question of ports, I recall the pre-alpha discussion of ports and how they came to be half-outside half-inside. Jaymie (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.

Nice discussion. I think good

jersmi's picture
Submitted by

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 Alastair (@usefuldesign) '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).

@jersmi are you a regular

alexmitchellmus's picture
Submitted by

@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

useful design's picture
Submitted by

@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.

Cool, @useful design. I

jersmi's picture
Submitted by

Cool FR, Alastair (@usefuldesign). (<-- 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.

@Bodysoulspirit designed a

alexmitchellmus's picture
Submitted by

@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).

I know these things come and go- soon flat ui will look old hat I am sure. But currently it looks good and gets out of the way. I would also be interested in discussing more advanced UI changes (such as having some sort of per node GUI window) but that may be for another discussion. I do think that there is lots of space in the middle of nodes going unused. I suspect this is why PB and PD use a top down data model- as this uses less space.

Great convo!

@Bodysoulspirit designed a

jersmi's picture
Submitted by

@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?

I also think that if/when a

alexmitchellmus's picture
Submitted by

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! :-)

@jstrecker

Bodysoulspirit's picture
Submitted by

Jaymie (@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 Alastair (@usefuldesign) 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 Alastair (@usefuldesign)’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.

Thanks for the nice comments

Bodysoulspirit's picture
Submitted by

Thanks for the nice comments and thought @alexmitchellmus @jersmi and Alastair (@usefuldesign)

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.

Pages