(Feature): UI/UX + icons overhaul (+ discussion)

[paulHempel]

Make sure to follow our issue report guidelines

• [X] I have read the feature request guidelines
• [X] I have followed the contributing guidelines to the best of my understanding
• [X] This feature is not on the issue tracker and is not a duplicate

Provide a description of your feature request

Currently Natrons UI is very basic (yet functional). To get people more comfortable with using the application, I suggest simple, yet effective UI and UX updates:

• Simpler, distinct, high-res icons (on Mac everything is blurry)
• Less complex UI patterns (e.g. currently there are many black borders everywhere increasing visual clutter)
• More spacing
• If input is provided, adjust some UX specific UI concerns (e.g. grouping icons or redistributing buttons) – this will require some user feedback (and could be split into another issue)

What I would like to provide:

• A mock-up design document, on how things could look (for discussion in this thread)
• The implementation of the UI changes (I'm a software engineer by day)
• The discussion about how to improve UX

What I would need

• Feedback
• A little help, if C++ gets involved (I'm primarily working with Clojure and JS nowadays) – but I'm open to dive into C++ tutorials

What do you think?

Is this a realistically implementable feature?

• [X] My feature is realistically implementable
• [X] My feature is NOT realistically implementable

Can you contribute in creating this feature?

• [ ] I am unable, or not willing to contribute to creating this feature
• [X] I am able and willing to contribute to the creation of this feature

Additional details

It is realistic, but I can't say it is a 1 month type of realistic thing ;)

[rodlie]

Hi,

This has been discussed for a while (in public and private), we also have various mockups and icons (@Shrinks99).

It's currently a matter of doing it, I was planning on doing a UI overhaul when our Qt5 port is complete.

[shetozz]

@rodlie Hi, as @paulHempel mentioned some of the redesigns need some sort of user feedback, so to avoid overdoing the redesign and solving some issues only to create new ones, would it be a little better to create a visual design team of some sort to give some feedback as the users of Natron are split into several categories and everyone has a different preference.

for example, some of the users have a preference for using Nuke others are coming from DR Fusion, and a third group are long-time Natron users not to mention the 3D software users, so it would be a mess to make major UI changes without being extremely cautious.

[rodlie]

so it would be a mess to make major UI changes without being extremely cautious.

My plans are not disruptive, they are primary fixes and style changes (make it look a bit better without changing UX).

Major redesigns are not planned (from my point of view).

[decryptedchaos]

My opinion on this matter is to use caution.

Aside from being great software, my biggest draw to natron is it being closely related to nuke which is the DeFacto standard.

And learning one is near as makes no difference learning the other. I personally think the UX isn't the only issue on the table, but rather why the users want to use natron.

And while as I have said my reasons are because I feel like it's two birds with one stone. being (somewhat) closely related to nuke. I know there are those using coming from fusion. But I feel like staying pure to the nuke methodology as much as reasonably possible is perhaps best overall for those using the software. In mimicking the industry standard you create a best of both worlds scenario where one could interchange the other with ease (from a skills perspective)

It's currently a matter of doing it, I was planning on doing a UI overhaul when our Qt5 port is complete.

I agree Qt5 is probably the best time/place to do this overhaul, hopefully that just isn't years down the road.

[rodlie]

I agree Qt5 is probably the best time/place to do this overhaul, hopefully that just isn't years down the road.

Will happen this year, no ETA though.

[Shrinks99]

Hey there new interested people! For those of you who don't know me, I'm a designer and VFX artist and I've been working on and off on Natron's design for... probably years at this point along with @Songtech-0912. Both of us have been kind of busy over the last few months (just wrapped comping a show myself) and disappointingly have little in terms of concrete additions to the program to show for it 😅. That said, our new website is almost sorted and is in a position where it can be launched pretty much whenever!

As @rodlie mentioned, some significant work has already been put into this! Many of the things said here align with what's been done already. Here's a Figma link for anyone interested.

Our goals for this redesign are as follows:

• Keep the general workflow & layout of content mostly intact
  • There have been a few buttons and controls moved around and grouped differently (better grouping of segmented controls mostly)
  • Largely however, @decryptedchaos is right and the similarities shared between Natron and Nuke are an asset, we don't want to change what makes those workflows great.
• Use Blender's icon library and expand upon it where required
  • Natron's current icons lack consistency, Blender's are generally pretty nice to look at, are compatibly licensed, and there's a reasonably significant overlap in content. Hopefully this will also allow Blender users to grasp Natron quicker.
  • Blender's icons are all vector based and designed on a pixel grid, they will work nicely when scaled to 2x versions for retina displays. AFAIK this is blocked by Qt5.
  • We do not want to use Blender icons that mean one thing in Blender for a different control in Natron. This will lead to confusion for users of both programs.
  • Bender's icons are all pretty much monochromatic. We'll probably break this here and there where required? Hopefully not in a way that hurts our consistency too badly...
• Ignore node graph UX improvements... for now ;P
  • The actual node graph hasn't been touched very much, I have some ideas for where things could get really fancy design wise but I largely want to keep that to a separate future project. Again, for those who don't know me, I have written a whole website about designing node-based software. Natron's node-graph is far from what I would consider ideal but I'd like to keep that to a separate future project for now. Hopefully once the rest of the application is nice to use we can come back and give the node-graph a solid polishing pass and make it actually great to use.
• Increase consistency of other UI elements
  • We have overhauled a bunch of the knob styles & application colours
  • @paulHempel mentions "more spacing" as a general ask but I have always argued that high end creative software is actually quite dense. There are lots of controls that actually do need to be visible and not hidden behind menus, especially in the viewer! We have adjusted the padding of almost everything however, it should feel a lot more consistent in this mockup than it is today. Most of it has been expanded by a few pixels
  • There's also a new reasonably complete mockup of the colour picker — this one is a little more than a "coat of paint" change and requires some actual code overhaul.

Hopefully this gets everyone up to speed! Design aside, there are also some programming related asks from me that come along with this redesign:

• The colour picker (stripping away all QColor scRGB nonsense) implementing the new knobs actually within the properties panel including logic for not allowing users to keyfram HSV & RGB values at the same time (part of the reason it's not implemented this way today)
• Logarithmic value slider implementation, Natron's sliders are all linear right now. A whole bunch of knobs should then have their sliders switch to log sliders to match Nuke's excellent slider implementation.
• New knobs???? (Keyer would be a nice one to have)... This is kind of a bonus and possibly "out of scope" ;P
• Natron's GUI currently does not make use of grouping buttons as segmented controls. We make use of segmented controls a bunch in the mockup.
• I know I said ignore the node-graph for now but if somebody wants to implement Nuke-like snapping of nodes friggin DO IT! :D Don't let me hold you back!

[decryptedchaos]

@Shrinks99

This is great info, I'm excited to see the outcome in the future.

I much prefer the UI tweaks in your example. It's much cleaner, the icons and spacing on the existing UI has always felt a bit haphazard

[paulHempel]

Thanks for all the great feedback.

After reading it, I totally agree to stick to the Nuke inspired UX.

My thoughts actually were pretty much "if this looks like Blender does right now, it would be great" – and suggesting to use their iconography and extending it would be a great thing IMHO. Which would create a cohesive "OSS suite".

@Shrinks99 on the topic of spacing: I would then reword it in "better spacing". In general I agree on the point made about professional software, which wants to present a rather large amount of control on a compact space. Yet the initial feeling for me was a little of. If we let us inspire by Blender once again, their approach on layout is a little more "cleaned up" and nicer to look at. Of course there shouldn't be large spaces of unused negative-space.

To sum things up:

• The best point in time to pick up implementing UI improvements is when Qt5 support drops
• If there is proper user feedback and the UI has been updated, UX concerns could be discussed

What I would do:

• I will take a deeper look at the Figma file and try to test out some UI adjustements and extend the existing Figma template
• I will update this thread with my results to discuss it further
• I would suggest a "more spaced design" inside of the Figma file (this could be toggled by a "compact mode" setting) for users with larger screens and simple workspaces (see this more as an aspirational idea for my surplus free time^^)

[shetozz]

@Shrinks99 Hi, the paper about the node-based interface is really awesome and I really enjoyed it, but I noticed a typo in the intro to nodes section under the Multi-In-Single-Out header

Multi-in-single-out node graphs are typically laid out vertically and their graph structure is less complex than nodes with multiple outputs. They optimize for graph hierarchy and legibility at the cost of only having out output type.

In the last sentence, I think what you meant to type is "only having one output type." It's not the place for this but I don't use Twitter or Instagram and I didn't wanna spam your mail.

[Shrinks99]

@shetozz I'm really glad you enjoyed it, that makes me very happy! Error is fixed, for any future issues you may find (and I'm sure there are a few...) it would be helpful to report these in an issue over on that project's repo instead of commenting here which I'm pretty sure actually does spam Ole-André's email along with everyone else's GitHub issues ;)

...Or send me an email! Really! That's why it's there!

[decryptedchaos]

One simple point I should add in regard to spaced out UI which @paulHempel covered by a setting toggle.

Spacious UIs may make sense in large production houses with the budget for gigantic 5K retina displays with enough pixels to stretch from here to the moon.

But I'm not sure how many of us home shops / hobbyist has that, personally I run 3 1080p panels

[paulHempel]

@decryptedchaos I totally agree with the basic argumentation. Although 4k panels become more common (and cheaper), which also shows in the adoption of support for high-dpi and larger then 1080p interfaces in Linux distros the last years.

Another way of looking at it: maybe small to medium studios want to use Natron and they have a little better and larger hardware - they probably want to make use of their space somehow.

But yeah, 1080p will be the standard for some years to come. Personally I don't run any 1080p panels anymore (only WQHD and up+), so this is my subjective view on the situation. But I also see and understand my privileged situation.

[decryptedchaos]

Another way of looking at it: maybe small to medium studios want to use Natron and they have a little better and larger hardware

I completely agree it should be an option. Just not default until 2k/4k become just as cost effective as 1080.

The practical implications are we will need to maintain two stylesheets in whatever markup/layout is used by Qt5/Natron.

Their will be scenarios where things like icon placement works on one and not the other.