Natron UI (Re-)Design Proposal

I’ve created a UI mockup for Natron on Codepen, based on Material Design guidelines. If there is enough interest, I will be willing to begin implementing it into Natron.

Full Explanation
I am a student who is learning graphic design, and I recently started using Natron. I was surprised by its functionality - it is almost as feature rich as After Effects - but I felt that the UI was difficult to navigate and to use.
Because of this, I began creating an HTML mockup of Natron on Codepen (link here). It is very much a work-in-progress, but I think that it is already easier to use and navigate than Natron’s current UI. Here is an image:

I am very new to the Natron community, but it seems to be a large and bustling community. I know that a complete UI redesign is far-fetched, but I would be willing to learn Qt and apply for GSoC if the community would support it. There are a few projects on Github that have implemented Material Design in Qt; I could use that as a starting point.
I hope the very best for Natron and its community. I would greatly appreciate any comments/suggestions about my design.

EDIT: I’ve created a GitHub repository for anyone who is interested in working on Natron’s UI. The link is here.


Hello & welcome! If you’re interested in UI/UX, there are so many projects around here that could use your help :slight_smile:


Welcome to this community!

Very nice! Are you familiar with other node-based workflows? Have you had a look at DaVinci Resolve’s Fusion implementation (and its redesign)? Applying for GSoC would be great.

Apart from that…I would love to see this come to fruition!! (who would have guessed?!)

1 Like

Hi, I’m also a design student with a few years of comp experience! For my fourth year thesis project next year I plan on doing a redesign of Natron with the goal of creating the ultimate compositing program… UI wise anyway. Haven’t begun that project yet though because I’m saving it for the fall haha.

With that out of the way, I do have some critique.

I believe the material design spec is the wrong choice for a professional desktop compositing application. It sacrifices information density for clarity and readability and the UI elements you have implemented here are all optimized for a mobile interface. Dark mode aside, what you have made (which is a well implemented material spec) would not allow professional compositors to operate with the same speed that they are currently able to with an interface that is much closer to Nuke’s or Natron’s current UI. While it is much friendlier looking at first glance (which is a bonus!) the amount of padding that material design encourages alone results in a much clunkier experience for a compositing suite. Have a look at Adobe’s tools, Blender 2.8+, and even Nuke (UX wise, and yes, there is room for a lot of improvement there too) and you’ll find a much denser interface. Using these tools for extended periods of time should afford you some insight as to why they are designed in this way.

The node graph you have proposed here is also an issue. A bendy-pipe left-to-right node system is much more well suited to something like a 3D material editor than a 2D compositing application, spend a solid amount of time in Nuke or Natron and creating giant organized node-graphs and you’ll quickly see why the current system of elbow joints and pipes is probably be best one. I suspect you’ve taken inspiration from Blender’s compositor but lets just say there’s a reason that most actual compositors (not 3D artists) use a separate dedicated program.

Nuke-like operation is one of Natron’s strong suits, especially as it is an open-soruce alternative. Having a familiar interface (especially concerning the node graph and modular panel layout) allows compositors to get started in Natron much faster than they would otherwise be able to, something I have experienced first hand and am very grateful for, that said there is absolutely room for improvement.

While I believe that a Nuke-like layout and shared amounts of information-density should stick around in Natron I have compiled a list of all the things that could be improved across both pieces of software that I plan to tackle in my redesign proposal. I’ve done many tutorial sessions with friends and lots of what I want to improve upon is the result of watching people struggle with Nuke’s various quirks. I think Natron has some great potential to improve in these areas. There are plenty of small changes that would make the first time user experience easier overall however I also believe that some learning curve for both Nuke and Natron will always be a requirement, having low-level image transformations available to the user is both a blessing and a curse, if you want them done for you go use After Effects.

Some of the things I plan to iterate on in my report (from a design perspective, I likely won’t be doing much of the implementation on these) are as follows, would appreciate any insight you have on them as a user!

  • There is no unified standard node colour scheme
  • Clicking the roto-tools buttons twice to switch them sucks, why is this not a drop down
  • Editing a roto-shape’s settings (life time, etc) is not a great user experience and is very difficult for first time users to learn
  • Natron’s icons should probably be redesigned to offer more consistency
  • Natron and Nuke both have poor trackpad experiences, much of which could be solved by multi-touch gestures
  • Natron’s tab-to-add node functionality isn’t as good as Nuke’s (gotta find out exactly why that is)
  • Natron doesn’t have dual monitor support for saved layouts (this one is just a known bug)
  • Natron’s mask input and node graph is messier than Nuke’s in that it doesn’t hide mask inputs… maybe this is good because it makes things obvious that a mask input is available, maybe not it results in more inputs that mostly will be connected to nothing, gotta think on this one.
  • Nuke has a better timeline for browsing through frames, why?
  • Nuke has better sliders for adjusting values - they all start in the middle and have better incremental numbers, this makes sense more sense than a linear scale as it means compositors will be adjusting values logarithmically without even knowing it which is how our eyes see lightness values anyways, this one is actually huge and a really good piece of UX on Foundry’s part. See Nuke’s grade node for an example.
  • Natron’s current Natron Community Plugins repo of downloading community-made nodes is a good thing to exist but not as good as it could be. Nuke has Nukipedia but even that would be MUCH cooler if it was built into Nuke itself. Having some sort of plugin browser that offered one click install of user created nodes would be giant… and also a giant amount of work so that’s definitely out of scope right now.
  • Natron refers to “Channels” as “Planes” which is confusing because “Channels” is the industry standard name and I don’t know why that was changed here.
  • The save dialogue seems to have a redundant text field which confuses people where to input their file name.
  • When writing things out with a write node there are a lot of settings that should auto-populate but don’t, also the “Default” setting is very unclear because it’s literally just labelled “Default” and all description as to why that is just tells the user “It tries to pick the best settings” which is great but WHAT settings are those?! Also some image compression options should only appear when the acceptable file format is selected in the write node

That’s my current short-list of gripes, all of which I plan to document and introduce solutions for, if you’ve got more please let me know!

Aside from those, I would recommend you spend a solid amount of time if you haven’t already either using Nuke non-commerical (it’s free!) or Natron to get a real idea of the workflow and the process. Make a short about a guy that can teleport or something, that’s a fairly simple effect. What you’ve made here looks really nice at first glance from a visual perspective but unfortunately I think it is flawed in what it is trying to accomplish. I don’t want to be too harsh here because I recognize that you’re trying to contribute positively to a project that is in dire need of more contributors but unfortunately I think this mockup comes from a place lacking in user-empathy and a more focused understanding of the tasks that come with compositing will help you create a better end product.


Thanks for the comments! I will probably be making a more optimized Nuke-like version once I get the time to. A denser layout is definitely more useful, though I still think that using a material design color scheme, font, and icon set would be helpful (and wouldn’t be too difficult to implement).

The UI has never been a big priority, yes it needs work, but looking at the big picture we have much more important things to fix (UI stuff is trivial compared to other issues). But don’t let that stop anyone :slight_smile: Personally I think baby steps are the way to go, fix small things here and there, we have many paper cuts (and open issues) regarding the UI that can be fixed by anyone with basic understanding of Qt/CSS.

We had an installer, but it was not maintained (that’s mostly on me, I didn’t have the time). The installer could easily be resurrected, or something similar could be made from scratch. I can help setup something if someone is willing to maintain it.

Touch can be added, but will require Qt5.

This has been an issue for many new users, and should probably be removed to avoid constant confusion.


Perhaps a UI/UX team could be set up for dealing with the current problems? I understand that Natron development is mostly in bug-fix mode right now (correct me if I’m wrong), and that UI/UX really isn’t a priority, but judging by the amount of interest, volunteers could be enough.

1 Like

Sure, feel free to coordinate. Also note that someone is already doing stuff with the UI (, if it gets merged is another thing.


A UI overhaul would be great but here are my thoughts on one little thing:
I see that you have designed the mockup with nodes like Blender. That’s not recommended.
Please keep it as a top-down workflow and not left-right.
Blender and Fusion have left-right workflows and they’re tricky to keep track of especially the more complex the project gets. Fusion is more intuitive than Blender though because well Blender’s compositor didn’t see a lot of development over the years.
Nuke’s and Natron’s current workflow allows you to work in a top-down…
… or in a left-right workflow

It’s good to have that kind of worflow freedom in compositing software as projects can often get complicated with 100s of nodes and it gets hard to organize nodes.
I suggest that the way nodes work stays the same. Improvements to the current workflow and aesthetics would be great but please don’t make it like Blender’s node workflow.



The way I see it, Blender’s compositor isn’t meant to be used as a dedicated compositing program. It lacks tools like OCIO tools, OpenFX, etc which are extremely important in today’s world and has a non standard UI. Looking at the renderlayer read inputs, it seems to be for directly working with renders made with Blender with a few basic tools for color correction, VFX and stuff.

HDPI setting. (Like Blender’s Resolution Scale setting)

1 Like

I might add that fusion lends itself more to a left-right flow, but you definitely can do top-down if you want to.

Keeping that flexibility is a very very good thing, so I have the same doubts about the mockup…maybe it forces a workflow upon the user that gives less freedom.

1 Like

Yeah that’s why I said Fusion is more intuitive.
To be fair I don’t have as much experience working on Fusion as I do on Nuke/Natron but Nuke’s node workflow feels a little more comfortable than Fusion’s and much better than Blender.
Blender’s left-right workflow works good for shading as most render engines out there have a similar workflow for material nodes.
For compositing, though, there are mixed opinions. Some prefer top-down and some prefer left-right. So the workflow flexibility that Nuke/Natron and Fusion have currently is important. If it can be improved upon, that’d be really great. But removing that flexibility will mean a lot of people will have to adapt to either workflow or they might just give up on Natron.
Anyways, I feel like a UI/UX overhaul would be great and it would breathe new life into Natron.

1 Like

yes to all of the above, especially this:

1 Like

I’d like to see some minimal improvements on the UI/UX.

For example:

The sliders have quite a high amount when sliding them, would be nice to be able to drag and move with the mouse clicked in the numeric field to adjust in much finer steps:


and finding keyframes takes often a lot of time, when a node is selected, it would be nice to see a small tick on the timeline:


You can adjust with the mouse wheel in the numeric field.

Does not seem to work on the Linux version…

Works fine on Linux here.

1 Like

A, I got it, the value must be highlighted first… Thanks!
it works now.

also note that ctrl-click (cmd-click on mac) on the slider gives you access to a finer scale

1 Like

UPDATE: I’ve created a redesign of my design, shown below:

Check out the full overview here.