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

@jersmi

Bodysoulspirit's picture
Submitted by

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 :

Some additional design parts

Bodysoulspirit's picture
Submitted by

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

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

(No subject)

Bodysoulspirit's picture
Submitted by

Some Work on the Editor ... Tried to use more of the OSX UI Elements. The day Vuo will be ported the Windows, it could match Windows's UI.

  • Rounded Start Button & modified Show Events Buttons.
  • Flatter Node Library.
  • Optional Canvas Points Grid (going to make a feature request for that).

The Buttons

The Node Library

Full View

(No subject)

Bodysoulspirit's picture
Submitted by

I've been playing a little bit again ... To show the nodes wouldn't need to be bigger. To gain some space for the Node Title I sized down the node class font size to 1/2 of the label font size.
I"m trying to get rid of the borders on the ports too.

Some work on the drawers too. Not really done yet.

Remember @Bodysoulspirit do a

alexmitchellmus's picture
Submitted by

Remember Bodysoulspirit do a version without any refresh port... Good to see how it all looks. Also it does look a bit confusing without borders if the draws are all close together, maybe no border but a small gap beteeen? Like in current design?

Also you have removed the port circle? That's different. If we remove the refresh it would be good to be able to see clearly that an event can flow into any port and yet the port can still have a value.

Maybe also it would be good to have a type converter or port mode: strip event from cable? Or possibly to have data onlky cables.

@alexmitchellmus ;)

Bodysoulspirit's picture
Submitted by

alexmitchellmus ;)

Remember Bodysoulspirit do a version without any refresh port... Good to see how it all looks.

As said on Facebook, I'll try a version without if I understand the team really is on the track to remove the refresh port. Not sure how far that idea has traveled there in Athens yet ;) Basically it would look quite the same but just without it for this redesign project (others welcome ;)).

Also you have removed the port circle? That's different.

You mean I removed the cable ports ? Yeah this last mockup brought up an idea done before already to unify both "data" & "cable" ports as when we connect the cable the value port disappears.
It would save some node width and clean up the node visual.

If we remove the refresh it would be good to be able to see clearly that an event can flow into any port and yet the port can still have a value.

Event only cables could connect to the value port and leave the value visible just as they do on the actual nodes am I right ?

Actual

Possible

Ok- this may sound crazy:

alexmitchellmus's picture
Submitted by

Ok- this may sound crazy: what if event only cables had an arrowhead at one end? So we take away the refresh arrow from all nodes- but if you then connect an event only cable to a node you see an arrowhead pointing into that port? (Can be a small arrowhead) to me this signifies a fire event and also clearly shows that the data entered in the port is also "pointed to" so that is the data that is used?

Also maybe we could also refresh nodes then by placing a cable anywhere on the grey top part of the node- it would just connect with an arrowhead anywhere.

Just thinking of something visually clear?

@alexmitchellmus

Bodysoulspirit's picture
Submitted by

alexmitchellmus

When we unify the port draw and port on a node then wouldn't it make it harder to connect a list to list input as opposed to a list draw ?

Sorry I'm not sure to understand, could you make me a screenshot of the difference between a list to list input as opposed to a list draw ?

... but if you then connect an event only cable to a node you see an arrowhead pointing into that port ? (Can be a small arrowhead) to me this signifies a fire event and also clearly shows that the data entered in the port is also "pointed to" so that is the data that is used?

Ain't the problem though that adding an extra arrow on the cable would only be needed if there where no more difference at all between Data Ports and Event Ports , like they would all be round with no sign at all on them, but then you would not be able to distinguish a port type before you would drag a cable (with an arrow on it).

So for me we still have 2 possibilities :

  • Keep the actual, different port shapes for Event and Data ports (with a possible redesign for the arrow shape if wanted).
  • Round the ports to harmonize the shapes and place an arrow on the round port for event-only cables, or an "E" for "event" or another sign (see some mockups earlier above).

One thing I keep in mind too is a discussion with (Alastair if I'm right) about Data Types not obvious on ports. I guess that can be disturbing for new users, that Data Types don't automatically update / are able to auto change when connecting a new type.
It is obvious for some ports (2D or 3D Points), but less for others (Real and Integers). Therefore one doesn't always know you can reset it to default to be able to use that port with other Data Types.

Proposed changes to design

jstrecker's picture
Submitted by

Summary of proposed changes to design

Trying to sum up the discussion so far — here are all of the design changes that have been proposed on this thread:

  • Node drawing
    • Increase the rounded radius of the corners of nodes.
    • Increase the number of points used when drawing the rounded corners of nodes.
    • Remove the border around nodes (including type converters).
    • Switch to a font with less serif and straighter characters.
  • Node colors
    • Make nodes fully opaque.
    • Make node colors more vibrant (full lightness, lowish-to-mid saturation).
    • Make the difference between the oranges and greens more obvious.
    • Provide a customizable palette for node colors.
  • Port drawing
    • Do something with event-only ports — Rounded triangle in a circle? Rounded equilateral triangle by itself? Same as data-and-event ports, but add an arrow to the cable?
    • Make ports fully opaque. (Don't show the incoming cable behind them.)
    • Remove the border around ports.
    • Do something with drawers.
  • Port constant values
    • Unify data+event input ports and constant value flags.
      • If port has constant value, display it in the port circle (which may be widened to a rounded rectangle).
      • If port has incoming data+event cable, or port type has no constant value display, make the port circle blank.
  • Cable drawing
    • Increase the thickness of data+event cables, and difference in thickness between event-only and data+event cables.
  • Cable paths
    • Make cables approach ports horizontally instead of coming in from above/below at an angle.
  • Visual cues for node/port properties
    • Remove the stateful indicator (line across bottom of stateful nodes).
    • Provide some kind of indicator for port genericness.
    • Provide some kind of indicator for port data types.
    • Change the port color to match the node color when a cable is connected (gray otherwise).
  • Editor toolbar
    • Round the corners of the Run and Stop icons.
    • Replace the Show Events icon with one showing two circles.
    • Use a flatter design for the Node Library.

Comments on proposed changes

Unify data+event input ports and constant value flags

Would there be a way to tell just by looking whether an input port is editable? For example, would an Image input port (not editable) look somehow different from an empty Text input port (editable by double-clicking)? (Currently there's no difference.)

Make nodes fully opaque.

The motivation for having them transparent was to be able to see the nodes and, more so, cables crossing behind another node.

Increase the rounded radius of the corners of nodes.

Checking out some other visual coding environments, I notice that Quartz Composer has rounded corners while TouchDesigner, Max, vvvv, and Isadora don't. Any thoughts on why that is? One of my co-workers floated the hypothesis that rounded corners might make some people think "toy" as opposed to "serious product". (To me, rounded corners suggest ease of use. Do some people consider ease of use vs. powerfulness/professionalness to be opposites?)

Provide a customizable palette for node colors.

Related feature request: Set default tints in the node library

Not yet covered

There are some additional factors involved in a redesign that have not been brought up yet on this thread...

Colors are complicated because the individual decisions about colors interact in so many ways. The canvas can be light or dark, and opaque, slightly transparent, or very transparent. Nodes can be selected or not. Ports can be highlighted when hovering near enough to initiate a cable drag from them. Input ports can be highlighted at two different levels as a cable is dragged, one to indicate directly connectable and the other to indicate connectable with type converter. Et cetera. These factors are all multiplied together. This results in very many combinations in which to make sure that colors that should be similar remain similar, and colors that should be different remain different. Just sayin'.

Ports have markings to indicate whether they are a trigger, how they block events (wall, door, or none), and whether they are a port action. How would this look with the proposed changes, e.g. ports along the edge of the node?

How would published ports look?

How would the Editor's toolbar look with Yosemite's new unified titlebar+toolbar?

Misc. comments

[Alastair] 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.

Could you elaborate or maybe provide a sketch?

[jersmi] 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?

See comments on Scriptable Editor and Editor Rules/Macros (< think Excel macros not QC).

[Bodysoulspirit] 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.

Yes, that would be nice.

[alexmitchellmus] Maybe also it would be good to have a type converter or port mode: strip event from cable? Or possibly to have data only cables.

I'll reply on your feature request.

What next?

Would it make sense to break out the proposed design changes into separate feature requests? How interdependent are they? Or if not using the feature request system, any thoughts on how to prioritize these changes with each other and with other development? And how to decide on the ones that might be controversial?

@jstrecker really appreciate

Bodysoulspirit's picture
Submitted by

Jaymie really appreciate your feedback. Makes me realize you consider the work done ;)

Just a quick answer before a deeper one.

COLORS

Yes, the more mockups I made studying the actual Editor made me realize how difficult it is to get some good color system adapt to the editor mode and all the subtle changes like mouse hoover etc.
I did not cover all of those yet in those mockup because I wanted some global feedback first.

ROUND NODES

Yes I understand the comparaison with QC and some other Apps. I have been thinking about it too (I think it depends on the HOW of the roundness too, for example, I don't think the messages in iMessage look toyish, but I agree it is not the same family of software though !).
I tried to compare with some other apps too, not only with the same software family and keep myself daily informed about the actual design trends on Dribbble, Bechance etc. and I will try to expose those and compare with a larger approach.
This mockup here, which I updated the title to Project AA - Rounded Flat assumes some other mockups and concepts.
I really want to make some other ones but it takes a heck lot of time ;)
As written before, I want to try a full square one too.
Everyday I try to gather some inspiration for the Vuo nodes in all the different designs I see over the web in all design categories. And I see some nice stuff with the same amount of roundness as the actual Vuo nodes. So I will even try some mockups with the actual roundness.
As written before too, I think even just for a node itself, many different parts can be worked on (node shape, node font, colors and alpha etc). So some parts could be done independently from the roundness (which could require more mockups and discussions).

ROADMAP

I don't think the design should slow down the Vuo releases and the work on the functional features in any noticeable way !
Feature requests are splitted, so should the design be too IMHO (thats why I tried to split the steps of the mockups too).
The Vuo design could be enhanced (all designs can and should be updated and refined) but Vuo has already a certain design that makes it already very nice too use (even more in dark mode ! ;) (smooth canvas scrolling and node library will make it even better)).

To resume I think some more discussions and some more mockups need to be made before changes applied though. I wouldn't want the team to work in a direction and later have to move backward . . .

;) Thanks Jaymie.

Back again ! Jaymie's answer

Bodysoulspirit's picture
Submitted by

Back again ! Jaymie's answer made me want to work again.

Tried to solve some problems mentioned above by some people and to make some compromises.
I also tried to make it mostly simple for the team. Tried to use mostly 2 colors (the node body and the node header colors) to solve different states in different Editor color mode.

Tell me what you think.

PS : Splitted the node background in 2 to show how the node would look in both bright and dark mode.

A - The default node

  • Basics : The exact same size as the actual node. No more borders at all. The whole node is in full alpha (body + cables), default body gray slightly lighter.
  • Roundness : The exact same roundness as the actual node (a try, because else could look too toyish).
  • Fonts : A modern font (Avenir), same size as the actual (only the class has been recolored and sized down to 1/2 the title size to clean the space up).
  • Event Only Ports : The same as actual, vertically aligned between node title and node class, without borders and placed beside the node (I have made some projects though of other shapes and signs, could post this separately).
  • Ports : Unified Cable + Value Ports, Removed all borders. based on ovals, larger value ports are rounded to match the oval roundness, all ports values are aligned right together (instead of centered on the port middle).
  • Cables

B - Approach Mouse

Instead of highlighting ports and labels with some new colors as Vuo actually does, why not just invert the colors ? Or use the same colors as the node body or node header.
On a default colored node the port color could be set to the same as the header color, the text too (white, as the title).

Optionally the labels could be faded (25% opacity).

For the cables the same. As like the actual Vuo, default cables would have the same darker gray as the node header, could turn to the node body gray when approached). The same could simply apply to colored cables.

We only used 2 colors so far for the whole thing ;) This is a test to reduce the colors and states, the actual purple highlight could be kept if preferred.

C - Approaching Cables

Approaching cables and color ports with cable color tries to solve or help or make use of some of the above comments made by Jermsi and alexmitchellmus.

Approaching a cable (in default gray or tinted) would color the ports they could connect to to the same color of the cable !
This means you have an ever more obvious support that shows you at the glance where you can connect.

Optionally the cable end could have the shape of the port type it can connect to / cable type it is (shape or oval). This is for fun but may perhaps disturb new users thinking they could not connect and event only cable to a data port.

D - Connected Cables - Color Ports with Cable Colors

Not very much more to add here.
A view of the drawers though.
Drawers have the same color as the node (like the do actually), cables and value ports are unified like on the nodes and disappear just as on the node when connected.
The connected cable can be shown on the drawer though, with is dot colored end and the drawer number in it (optionally, could gain some drawer width).

Output Cables are tinted as the node (like the do actually).

E - Colored ports when cables have wide angles

As one Vuouser mentioned above, many cables coming inside the node with wide angle values makes it almost impossible to use.
The tinted connected ports with the cable colors would help with that (even if I fear some colors may not always look good combined with each other but hey, here the functionality is important though).

F - The selected nodes and node opacity.

One thing Jaymie I understood perhaps after your comment about the opacity of the nodes to show what is going on behind the nodes (I personally don't think that necessary and think it adds some clutter but it is my humble opinion) is that perhaps the opacity is used to differentiate idle nodes from selected nodes.

Idle nodes are transparent, selected are fully opaque.

The problem with that is that I find the difference between selected and unselected not be very obvious. Quite often I select a node and don't see which one I selected (don't remember if it is more obvious in dark or bright mode).
This is even more obvious with cables. You select a node, go at the other end of the composition by following the selected cable to see where it is attached to, but once there, you can't really see the difference between selected and unselected cables and must zoom out and try again.

For example here below

The nodes on the left are unselected, those on the right selected.
The difference between the tinted nodes are slight.
The different between the cables colors almost impossible to see.

This made me think of a potential solution (have been thinking about shadows, but they are not to see on the dark mode, borders, ugly and not obvious ...) which is a default color for selected nodes.
Some blue for example that would not be in the default tint palette and that would apply to both the node and the cables (left the drawers behind to identify the drawer from the cable connection).

Something like this (would only apply to the outgoing cable color of course but here the mockup assumes upstream nodes are selected too to show how it would look).

G - Some other ideas and thoughts.

a - The Input Editors.
Jaymie I'm jumping here to that discussion about input editors being cut but the window end and your comment that the input editor has an arrow tho show what port it is editing. And that flipping left right would help for left / right screen ends but not up / downs. Just mockuped one way here perhaps that could help. Either the canvas would have to automatically move, or it could use a cable to show what port it is editing.
Optionally, the not edited ports could be faded to 25% opacity.

b - Missing Nodes.
No more crisscratch, just a one faded light gray color for the node (body + header) and hidden labels with a big "Node Missing !" text (same text size as the Node title).

c - Node Error.
Remembering Steve's comment Red had been omitted to report errors.
If an OSX color picker for custom tint colors posed up, the same technique as above (big text in the middle, labels faded out) would allow us to use red though.

d - Walls and more roundness.
Answering Jaymie's question about walls. As already posted earlier, perhaps just some straight bars (instead of bent), beside the ports, full or split (like the actual).

Just made a version with some more node roundness for fun though. Not as much as earlier. I think the toyish side is increased too because I uploaded big screenshots with an enormous tinted node of 700 px ;)
An actual node sized up and tinted looks more toyish too then when in normal size I guess ;)

Anyway, this was an attempt to keep the actual roundness though as written, an almost the same fire on start and some changes that would apply everywhere the same, for a light code and happy team ;)

What you guys think ?

This thread is really

tobyspark's picture
Submitted by

This thread is really positive. Well done Bodysoulspirit and team vuo for picking up on it

I'd suggest you go further. In particular I still think

  • event vs data handling can be communicated better, using fewer concepts. See this thread. https://vuo.org/node/166
  • the use of colour in Vuo is a missed opportunity. Tinting nodes feels to me like something that was easy to implement, not something that addresses the fundamental issues of organisation or readability. My feeling is that Vuo itself should use colour to communicate, Quartz Composer took some good steps there.

I appreciate this is a bit of a parachute-in comment, I've been too busy elsewhere to be able to use Vuo in anger. But I did trouble-shoot somebody using the latest Vuo a month or two back, and got the same feeling that I did back in the early days – I won't rehash here, ie. https://vuo.org/node/159

How about making Vuo

MartinusMagneson's picture
Submitted by

How about making Vuo themeable (pro?)?. Wouldn't it mostly just require some XML file containing color tags for the different input/output types along with optional vector files for the graphics? I know for instance Reaper (reaper.fm) allows for this, where good concepts has been taken into the official theme, but you still get the crazy ones for those that prefer it. It would also open up for minimal solutions, high contrast, B/W etc that I can see would be useful in some scenarios, and apart from the initial groundwork, it would offload team Vuo from a lot of the work if/when someone's unsatisfied with how it looks.

Of course, to make it really cool (or nerdy? (or inception-like?)) in execution, it should be possible to make it inside Vuo. Maybe a "theme" node of some sorts?

Hi @Jaymie, regards your

useful design's picture
Submitted by

Hi Jaymie, regards your summary, (Thanks for doing that):

  • Visual cues for node/port properties …

    • Provide some kind of indicator for port genericness.

    • Provide some kind of indicator for port data types. …

Not sure what the first one, generics is and how this relates to the data-type symbols idea. Please explain. I'll try and answer your questions next week after a project I'm (conference demo on Visual Programming for app developers — i'll make sure to plug Vuo) finishes.

On Vuo being Themeable, I've

useful design's picture
Submitted by

On Vuo being Themeable, I've thought about this a lot over the years and I really think that having a Scriptable Editor and/or Editor Macros (rule assignment to Editor canvas and Node properties like you do with smart lists, email rules etc etc) is the way to do this with the most power and least imposition on Vuo team to build all the UIs for it and complexity that would be desired. Just make the certain properties getter/setter accessible via scripts or rules and leave the rest tot he community. Obviously would still require a lot of work under the hood, and now might not be the best time to do it given so much core functionality is still desired by users.

See my Feature Request (also linked above) for a long discussion of scripting and macros.

Not sure what the first one,

jstrecker's picture
Submitted by

Not sure what the first one, generics is and how this relates to the data-type symbols idea.

Alastair, an example: When you create a Hold Value node and click on any of its ports, it says the data type is generic. If you connect a Fetch Image node to it, the port's data type becomes Image. You have to click to open the port popover to see if the port is currently set to generic or an actual type.

Another example: When you create an Add node and click on any of its ports, they say the data type is Real. If you right-click on the port, you can select "Revert to Generic Data Type", then right-click again and "Set Data Type" to some other type. There's no way to know without right-clicking on the original port that it could be changed to a different type.

ah right, thanks Jaymie. As

useful design's picture
Submitted by

ah right, thanks Jaymie. As you know, I had enormous trouble understanding that ports can get locked to a type and don't revert to 'generics' when cables are removed. So yes that's a big learnability issue for me.

I read an interesting article about "onboarding" new users yesterday and what actions and principles work and what gets in the way. Might be of interest… they are essentially pitching their own product that does user testing for "onboarding" (currently free i think) which they say often gets missed out from website usability testing as it's added later. I guess any way we can make Vuo and easier tool to learn the faster it gains users and critical mass to ensure it's future development (hopefully with a full time dev and support team).

Hi again! Me and the rest of

jstrecker's picture
Submitted by

Hi again! Me and the rest of Team Vuo had some discussions about this thread, making sure we understand Bodysoulspirit's design so far and seeing what more needs to be done. Thanks so much for all the time that you all have put into this. It's a huge effort and we appreciate it.

We have some questions for y'all...

  • Shape and layout of nodes and ports
    • Change rounding of node corners.
      • Any further thoughts on round vs. square? Are there any design principles that would favor one over the other (in the context of Vuo compositions), or is it just a matter of which trend to follow?
    • Switch to a font with less serif and straighter characters.
      • Since Avenir is pretty expensive to license for distribution in a desktop app, can you suggest a good free/low-cost alternative?
    • Adjust sizes, weights, and placement of text.
      • In some of the mockups, the node class name is a lot smaller than the node title, to the point where it's hard to read. Back in Vuo beta, there was a bigger size difference between the title and class name, but we heard from some designers who said that didn't look so good, hence the smaller size difference today. Thoughts?
      • At one point mnstri suggested adding an option to hide node class names. How would that affect the design?
    • Move ports to the outside of nodes, and unify ports with constant flags.
      • Someday we're considering adding the ability to edit the initial value for an input port that has an incoming cable. (This would avoid having to put in a Select Latest node, as described in the manual section Set up a port’s data when the composition starts.) It would mean that an input port could have a constant value and an incoming cable at the same time. How would that affect the design?
    • Change indicators for node properties.
      • We already talked about removing the bottom bar indicating statefulness. What about the wi-fi icon indicating interface nodes? Would you miss it if it went away?
    • Add indicators related to port types.
      • We talked about the benefit of being able to tell by looking at a port if it has a generic data type. Any thoughts on how this would be indicated?
  • Colors
    • Make node colors more vibrant.
      • Bodysoulspirit, you said that nodes look pale and washed out because of the transparency. Since the transparency is only ~15%, I think that impression may be coming partially from the brightness and saturation as opposed to the alpha (which I'll ask about in a sec). We had intentionally made the node colors somewhat muted, so it wouldn't be that hard to adjust the brightness and saturation to be more vibrant. Sound OK?
    • Make nodes opaque.
      • Bodysoulspirit, you did a mockup showing two nodes stacked on each other, which I agree looks better with the nodes fully opaque. But I hardly ever see nodes stacked like that in real life. As I mentioned before, one advantage of nodes being slightly transparent is that you can see cables going behind nodes. Are there other advantages of full opacity besides node stacking?
    • "My feeling is that Vuo itself should use colour to communicate, Quartz Composer took some good steps there."
      • tobyspark, are you thinking of how QC colors patches by their execution mode (consumer, processor, provider)?
  • Event flow
    • The concept of event streams — that an event is emitted from a trigger and flows to all connected (downstream) nodes until stopped by walls or doors or the end of the line — is essential for understanding Vuo. We get a lot of questions from new users about why a node isn't executing (because there's no event going into it). We also get questions from more advanced users about why a composition isn't working as expected, which is often because events are flowing to places that the user didn't notice or expect. There are different ways we could address this, including automatically connecting some cables from triggers and adding a context menu option to highlight all the nodes downstream of a trigger. On Improve style of nodes and cables, tobyspark proposed integrating event streams into the visual design. Thoughts?

@Jaymie hi ;)

Bodysoulspirit's picture
Submitted by

Jaymie hi ;)

Sorry I did not have much time recently doing more mockups and give feedback about the design (and don't have much these days around).
The more I understood the actual design the more I got understood some under the hood reasons that link some things together.
I also think most of the time could be used by the team rather to add more features to get more users.
And even if some changes could be made to the default nodes, customization as suggested above in some comments will be cool at some feature point.

Just some quick notes on your comments above

Change rounding of node corners.

As tried above in some mockups, I think the actual node roundness could be kept for now, some other tweaks coud after all be done before.

Since Avenir is pretty expensive to license for distribution in a desktop app, can you suggest a good free/low-cost alternative ?

Will look.

In some of the mockups, the node class name is a lot smaller than the node title, to the point where it's hard to read. Back in Vuo beta, there was a bigger size difference between the title and class name, but we heard from some designers who said that didn't look so good, hence the smaller size difference today. Thoughts? At one point mnstri suggested adding an option to hide node class names. How would that affect the design?

Mmm ok. Yeah harder too see when smaller, however as I use the class less I thought it could be shrinked down to a value that could be seen though when zoomed a little. But if some users need why then don't touch it.
In a mockup below I kept the same sizes (but shrinked the line spacing for some points).

Perhaps if the node class could be hidden one day, could be cool if the name that would vertically align to the middle of the node header.

I did place the "Fire" arrow between the node name and class earlier, below I kept the actual position. May bee kept for further feature.

We already talked about removing the bottom bar indicating statefulness. What about the wi-fi icon indicating interface nodes? Would you miss it if it went away?

I would not for both, but the wifi icon doesn't bother me neither, it's small and looking nice IMO. So as one would like. Bottom bar looks not good I think.
Perhaps if one would not need the wifi Icon, statefull nodes could have a "S" alphabet letter at that location ?

We talked about the benefit of being able to tell by looking at a port if it has a generic data type. Any thoughts on how this would be indicated?

Have some ideas about it, but if they could auto-update as discussed on the data type topic, perhaps it would be less important ?

Bodysoulspirit, you said that nodes look pale and washed out because of the transparency. Since the transparency is only ~15%, I think that impression may be coming partially from the brightness and saturation as opposed to the alpha (which I'll ask about in a sec). We had intentionally made the node colors somewhat muted, so it wouldn't be that hard to adjust the brightness and saturation to be more vibrant. Sound OK ?

Mmm.
Mockups use some trendy acid colors. I don't know if they would be too bright ? Since the purpose of colors is to differentiate the nodes, it would do the job even better no ?

The transparency doesn't help me when it comes to see cables behind it, nor seeing cables crossing themselves. I think it more adds clutter to the thing, but that's my opinion.
However I seem to understand the transparency changes when nodes are selected or not, used as a highlight somehow. So if it would require deeper changes for now, it could be kept for now IMO.
However, perhaps the alpha could be shirked down from -15 to -10, would already make things look better perhaps (see below mockups).

The only point transparency could help me is if 2 nodes would be below each other, I could search for it and don't find it. But that happens unfrequently and I already have not been finding a node with the actual transparency.

So the below mockups use 100% brightness, 100% or 90% alpha, and 35% - 50% saturation depending on the colors.

I the next mockups I tried some things to make the work even less for the team but still add some visual changes.
This could perhaps be a first step that would not require much work !

Here is the default node in

Bodysoulspirit's picture
Submitted by

Here is the default node in green

Here is the EXACT same node except that

  • The green is 100 bright and 35 saturated.
  • The node header and borders keep their original gray (they don't tint). I think it looks cooler. So no more 2 different greens, only one for the body and ports.
  • The ports labels text is darken a little bit more, tints less (down to 35% brightness).

Here it is in 85% alpha then in 90% alpha (I like it more if some transparency has to be kept).


Then I took the same original node and changed only the font to Avenir (sorry the mockup had been made before I read your comment about the price of Avenir, will look for another one.
However, Signika is used throughout all Vuo and the website.
Either way only the nodes would / could have a different font, because of the readability of the composition, or it would require the font to change for the rest.
So perhaps the colors only (as seen above) could already be a good start, made the font mockup though.

Signika

Avenir

Both the colors and a new font

Cheers

Tried to find some modern

Bodysoulspirit's picture
Submitted by

Tried to find some modern free fonts and made some mockups.

Montserrat and Varela are Google Fonts, Ikaros Sans is free for both personal and commercial use.

Ikaros and Varela are at their boldest there, only thinner exist. Character spacings have been set to match the Signika width.

What you people think ?

PS : Be sure to open the image in full size for better resolution, can upload bigger if needed.

Thanks for the comparison of

jstrecker's picture
Submitted by

Thanks for the comparison of opacities and fonts, Bodysoulspirit. I'm interested to hear what people think of them.

I also think most of the time could be used by the team rather to add more features to get more users.

A lot of people have told us they don't like the current design, though. Some have even given that as the reason that they choose not to use Vuo.

So far, everyone who's commented on this thread has been really positive about your redesign, Bodysoulspirit. For many people, I think improving the visual design of Vuo would be as helpful as adding functional features.

My co-workers and I talked it over, and we're thinking it would work better if we did a significant redesign all at once instead of incrementally. Previously when we got some design suggestions, we added them incrementally across several releases, but that didn't result in positive feedback. Some people stated that they wanted to see the design considered holistically instead of broken down into a tweak here, a tweak there.

I realize there's still a lot of work to do toward a redesign. Published ports, subcompositions, hidden cables, maybe triggers, etc. etc. Later I'll post a composition that contains all that stuff.

this topic is getting really long as one page doesn't it ? Should we get auto splitted topics in pages when more the 20-30 answers ?

Added :)

A lot of people have told us

Bodysoulspirit's picture
Submitted by

A lot of people have told us they don't like the current design, though. Some have even given that as the reason that they choose not to use Vuo.

Yes, but don't you think some other don't (yet) use Vuo because of the lack of features too ?

What I mean is that has been my thoughts at some point too ! I did think the canvas looked really ugly, but I must admit that since I have Vuo pro and dark mode it's better already. I remmener suggesting the Dark Mode in both basic and pro vuo. You say people chose not to use vuo because of the design, you mean after a trial ? If yes, perhaps the dark mode would already have changed their mind ?

As already mentioned as I did some redesign I understood many different things had been added by the team to express some states and stuff.
But still I don't mean it could / should not been done another way, I can imagine different ways, but I understood too sometimes design has to work in relation with function too.

At the start I was a lot about design, but the more you use Vuo, the more you enjoy but simultaneously the more you know its actual limitations too and rejoy for all kind of improvements (features, design, bugs, other UI/UX stuff (canvas position memory, smooth scrolling ...)).

At some point we want all that done tomorrow ;) And I do think sometimes the team could gain time by doing it more efficiently from the start, or discussing some things more etc.
But I think it is always easier to critic when from the outside ;)
I guess it is also easier to add some features to a software (like QC) compared to building one from scratch ;)
So for some things I hope more from the team, and for other I thank them and love them for all they have already done !

So yeah design is really important !
Cool we can discuss it here and hear feedback and ideas !
I'm just not sure if it is more important then features, right now I'd say just as important.
That was my idea when I suggested to fly to Athens, spend some time on design while you guys are already so busy with features !

So I still think it would be better to improve design beside features.
And add some customization perhaps at the same time slowly (one design will never make all happy) (could think of custom node colors first with color picker, then later perhaps custom fonts, custom shape roundness, custom opacity for nodes, canvas background only, cable size, cable shape (straight / curved) ...).

Sometimes I also don't know where / how I could do more redesign mockups ... Instead of doing static mockups If I was pointed out with a tutorial how to try live redesign with either QT or scripts (as Alastair mentioned if I'm right), how I could tweak the code of the nodes etc.
But perhaps it's part of the proprietary editor code, don't know.

But that's my opinion.

Later I'll post a composition that contains all that stuff.

;)

this topic is getting really long as one page doesn't it ? Should we get auto splitted topics in pages when more the 20-30 answers ?
Added :)

Thanks

Pages