Natron UI Project


#1

Natron UI Project

Natron is being developed at an incredible speed. Everyday, new features are added and bugs are fixed.

But the UI (user interface), however functional, is in need of some special love to get in on par with it’s commercial counterparts. It is one of the first things someone will evaluate when trying out Natron. It could make the difference between that person sticking to Natron or dismissing it.

UI design and implementation represents a colossal amount of work. That is the reason I am creating this thread, to alleviate the workload of the core devs. A lot of you want to improve Natron and so do I. Here is your chance to help. This is a call for help!

Cahier des charges (specifications)

Before we can design a good interface, we need to understand what the makes a good interface.

Do we want a complex interface where all functionality is available through buttons that are crammed all over the interface? Or do we, on the contrary, want a simple interface with only the essentials and where less used features are a bit more hidden in menus?

Here is what I think, makes up a good interface. Everyone may not agree with this, and I strongly encourage constructive feedback! I will update this post with feedback I get.

What makes a good interface?

  • Intuitive: A UI should be as intuitive as possible without compromising usability. This means having a lightweight interface with icons and terms people are familiar with.

  • Modular: The user should be able to decide how to arrange his workspace, it should not be imposed by the software or software developers.

  • Uniform: Behavior and style should be the same throughout the whole software. Similar functionality in different parts of the interface should work the same and use the same shortcuts.

  • Good looking when you use a program for a prolonged period of time, you want it to be easy on the eye and pleasant to use. Space and padding can greatly aid in guiding the user to the important parts of the interface and not overwhelm him.

Mock-ups

For the last couple of days I have been working hard at making a mock-up for an eventual UI. The goal was to simplify the user interface and making it look good. I would appreciate any constructive critique.

Please, I encourage everyone to post his thoughts, ideas, mock-ups, concept arts, etc. Even if they concern only a small part of the interface (e.g. redesigned slider, better name for some functionality, …). I will try to update this post to reflect the feedback I get.


Azerupi’s mock-up

The goal with this design was to simplify the user interface. Move all the more advanced functionality and controls in context menus, shortcuts, etc. Details may be missing, but it is the general concept that counts.

  1. Like proposed in this issue I would start by splitting of the timeline into its own panel to make the interface more modular. Edit: It was proposed to centre the playback controls and put them above the timeline instead of below.

  2. Simplify the viewer. The current viewer is a mess. Making it slick and minimalistic improves the interface a lot. More advanced functionality could be available through context menus.

  3. Nodes could have color-coded input / outputs. In this mock-up I used squares for input, circles for output and triangles for mask inputs. Like explained to Jean-Christophe via mail, there could be a collapsed and expanded state for nodes. One favouring compactness, the other conveying more information. There could also be a shortcut that could hide / unhide the in- and output names for when you are not yet familiar with the color and shapes.

  4. Node settings is the part that needs the most work in my opinion. The active node should always be on top. Controls could be grouped, with some groups initially collapsed to make the interface less dense. Some padding and color nuances can also help differentiate between nodes.

You can find the .svg version of my mock-up here, you can modify it using Inkscape or Illustrator. Feel free to use, abuse, modify and improve on it!


Sergusster’s Viewer Widget

The user could expose node properties from different nodes to have access to them from the viewer. The properties would be displayed in a semitransparent window over the viewer. This would give you the ability to tweak your nodes without leaving the fullscreen viewer and without the need to constantly scroll up and down in the node properties.


Olear themes

Olear has taken the initiative to create a repository for Natron themes. He’s working on improving the current style until a more in depth redesign. Any help with that is welcome and if you create a stylesheet for Natron, make sure to add it to his repo.


Color Selector Project

Natron is going to get it’s own color selector, more powerful and feature complete than the default OS color selectors.

Go to this post to see the mock-ups that Jean-Christophe made. They have been approved and development started already. Currently you can check out the progress here: https://github.com/azerupi/NatronColorSelector


Now it’s your turn, let’s see what this community can come up with!


#2

#3

I like the style specially of the properties boxes, In my opinion I would only change the purple color that I feel, maybe just neutral gray.

Maybe the position of the playback buttons should be different, closer to the viewer. and centered.


#4

Great starting thread. Guys, is there any restriction for the GUI? I mean, I know there are some special graphic libraries that we (all common people) are not awarre of. Instead of building something from the ground up, maybe we can take and modifiy “themes” by graphical libraries that are already out there? If so, where do we look?

Second observation Should we propose what feels right for 2015-2016 nodal editing from zero? I like minimalism. A LOT, because it saves space, also give out to other users the essence of nifty-tidy-well-groomed-organized application. And that´s what I´m after a compositor.

Ubuntu new version has slick interface UI, maybe we could start from there? Also: I can mockup animation for functions I really would like them to be considerating when using Natron. (remember Sculptris had a bad designed interface, but the FUNCTION was translated to Zbrush re-mesher then everyone went wild happy). So our aim should be function and design.
Cheers.


#5

this is my mod, to begin the threat
:smiley:


#6

You mean the main color? I don’t remember what I used exactly, I have to check, but I didn’t mean to give it a purple feel. :wink:

To give a bit more background on why I put them there in my mock-up:

Currently, when you have multiple viewers, they all have their own timeline and playback controls. But since they are all synced together there is no point in having as many timelines as you have viewers. It’s a waste of screen space. Therefore (and this is already planned) the timeline should be moved into it’s own panel. So that the user can control where he wants the timeline in the interface.

The playback controls however are somewhat a grey area. I think they should be put with the timeline, but having controls in the viewer is handy too. I think they can be omitted in the viewer if we have great and intuitive shortcuts for the more important ones.

I think it is very important to not restrict ourselves with technical details in the concept phase. Go crazy! If it has value it can always be implemented, albeit some things require more work than others :wink:

However if you want to know, Natron uses Qt for the GUI. It is a very powerful graphical framework and it is very customizable. It offers a wide variety of standard GUI elements and gives you the ability to create your own.

As I said earlier, there are no restrictions in the concept phase. Anything can be proposed and discussed. That is the point of this thread, have the community’s opinion on what Natron’s interface should strive for.

In this thread we are only going to focus on UI, because that alone is already very broad. If your ideas are about the UI then yes please! We would like to see them :wink:


#7

Like proposed in this issue3 I would start by splitting of the timeline into its own panel to make the interface more modular.

i don’t think this is a wise idea.
if you have more than one viewer on the screen, it can make a lot of sense to lock/unlock them from the frame number of other viewers for visual reference etc. an extra panel would make that more complicated than necessary. (look how this is done in nuke)


#8

That is a use case I did not consider, thanks for pointing it out!
Though you could easily imagine something like Right Click > Lock Viewer. I am not sure how useful it would be to have multiple unsynced viewers running in parallel. I could be wrong though, can you think of a legitimate use case?


#9

So, I started a new stylesheet, far from done (ignore combobox):

WIP:


ORIG:

The combobox and some other widgets are (sadly) hardcoded in Natron.


#10

Nice, thanks @olear

I started a new stylesheet last week too, but I figured it was better to reflect on what we want first.And so I decided to pause and make a mock-up.

But since your started I will make a pull request with the one or two things I did.

Yes I stumbled upon that problem too. Since it requires a lot more time to tweak than widgets with the stylesheet, I figured it was best to leave it be, until we have a clear idea of what it should look like.


#11

Will upload my stylesheet on github a bit later for testing etc (also need to test on all plattfoms). Will also try to remove hardcoded stuff in Natron.

My first goal is just to make the default stylesheet a bit better, so continue with mockups etc.


#12

DONT EVEN THINK about turning Natron into Fusion.
Fusion’s GUI is just plain disgusting!


#13

Your point can come across equally well without being aggressive. Let’s discuss this in a civilized way. Non-constructive critique does not help anyone and sets a bad mood.

I am interested in everyone’s opinion, but I need you to argument your claims, tell us specifically what you dislike and why, so that we can take it into account. If you critique something specific I can explain some of the design decisions I made in my mock-up, and then we can try to improve it to ultimately come up with an interface that works well. That is the whole point of this thread.

And please, feel free to share your alternatives!


#14

Who said i’m being agressive? 0_o
Will it be better if put a smiley face at the end of the sentence?


#15

As a compositing artist who works in a big production pipelines i can say, that one of the best things about Natron, is that it’s Nuke-like. When you first open Natron being familiar with Nuke, you already just know how to interact with it, you know all the shortcuts and menus - this is very important. So at the moment, aside from minor widgets design, Natrons GUI just need to be brushed up visually. There’s absolutely no need to reinvent the wheel.


#16

So essentially you dislike Fusion’s interface because it’s different from what you are accustomed to? I am not saying that Fusions interface is good. But I have to disagree that Nuke is a good reference either. It may be the industry standard, but that doesn’t make it’s interface and ergonomics good.

I totally agree that shortcuts compatibility is important, though Natron could ship with multiple shortcut presets (like some software have nowadays). And as Natron tries to give users as much control as possible I am not very concerned about this.

I have also encountered a lot of critique about Natron due to the fact that it resembled Nuke too much. Essentially saying that “Natron was a poor clone of Nuke”.

In my opinion it is important for Natron to develop it’s own identity. Picking only the best from it’s competitors.

It would be interesting to hear what the core team’s opinion is about this though, as they have the final say. @MrKepzie ?


#17

And Nuke took it’s looks/layout from Shake, etc, etc.

Yes, Natron should “stand out” and get it’s own identity, and as far as I know this will be worked on in future versions, but nothing major will happen in v2.

I’m all in for changes, as long as we keep existing flexibility and don’t “break” the way people expect things to work (don’t go overboard with the UI changes).

Btw, uploaded my stylesheet (not done), feel free to test and improve. https://github.com/olear/natron-styles


#18

Overall it’s nice to see, that comunity is into making Natron better. Considering that right now developers team have much more important tasks to accomplish, i think that it is reasonable to make small, relatively easy to implement GUI improvements, such as desent color picker for example. Throwing my 5 cent into it, i came up with design sketches of little viewer widget that would be nice to have into Natron. This is overlay element that gathers parameters exposed by user in one semitrasparent movable panel in a viewer. It can be very handy when you fine tune your compose in fullscreen mode and sets you free from constantly scrolling through dozens of parameters of different nodes in property panel.


#19

I am working on that, but it’s going slowly as I haven’t coded in c++ with Qt for years. If you have any suggestions or you can show me reference images of a really good color picker in your opinion, that would be immensely useful. At the moment I was planning to begin with a HSL and HSV version.

Thanks for your input! This could indeed be useful when you don’t have a second screen. I am not sure though about what you mean by “exposed by user”. Do you mean that the user would have to explicitly right-click in the node properties and “expose control in viewer” for example? Would make sense to see as to have only the relevant controls at hand.


#20

You should not start coding on your own aside before proposing any idea. Jean-Christophe Levet, the man responsible for UI choices will be in the end our person we turn to, to make up our opinion before coding something.
He is actively working on UI propositions and so far he has worked on the following:

  • unified “workshop” interface (same panel for nodegraph/curveditor/dopesheet/timeline)
  • the color dialog will be a dockable panel (same as the node graph) that will be invoked when clicking the color-wheel of a parameter and then hidden when done
  • the file dialog will also be embedded as such a dockable panel
  • there are plans to make the UI more dynamic when selecting a node (displaying available layers in the viewers, temporarily open-up the settings panel and then close it when selection is gone etc…)
  • the node graph will have an auto-placement for nodes that will be much more intuitive
  • properties panels will be much cleaner

I will ask him to post his sketches here so that everyone is on page.
Please note that we are not going to make a brand new interface that nobody is going to understand, keeping close to what the industry standard uses (i.e Nuke atm) is for us the only viable option. That means shortcuts, layout, behaviour and tool names should be consistent.

The only part where we can operate is by making things more beautiful or less clunky to use (e.g color picker) and overall more enjoyable for the user.

Stylesheet is not a big concern (a part from the Combobox), rather people should focus on UI improvements that lower the number of mouse interaction required.

Note that regarding the UI, currently the only needed change to make Natron “stable” is to re-write the NodeGraph to use a raw QWidget backend instead of the QGraphicsView which is full of bugs (besides being freakishly slow)

I’m not trying to prevent you guys from spawning new ideas, but keep in mind that radical changes are NEVER appreciated by end-users.
We will pick up ideas here and there, but every change should be as small as possible so that people hardly notice it, or just raise an eyebrow mentally thinking “oah this is cooler than before isn’t it?”