Another dt UI discussion

One point to keep in mind. Darktable is plug-in based. That is every module is self contained and does not know about other plug-ins. So it is harder to have specific control order on screen. An attempt has been made with the QAP. But apart from that, what we have on screen is somehow imposed by the internal implementation.

5 Likes

I read through the whole thread and I have read and been in many of the discussions concerning the UI.

But mostly it are general statements. Building a UI is a very detailed process. So as most general statements are maybe good by intention, they are rubbish when it comes to changing the UI, because they are simply to vague.

Additionally, discussions involving UI often are preferences.

As an example: I personally don’t use keyboard shortcuts. I tend to forget them and I personally don’t see the point of improving the speed off my workflow using them. If I would like to increase the speed, I would snap a picture with my iPhone.

Then some people call the UI bad or ugly. Well in itself that is a very useless comment. Specifics matter.

So, if we want to improve the ui let’s be very specific: what needs to be changed, why does it need to be changed and how. So that if a developer decides to pick it up, there a clear vision of what changes need to be made.

As a very low priority example, I would love to see in the map overview, it would be possible to just have the google maps style pin indicating where a picture is taking, not the photo itself as a pin. The reason is that in a large library, when zoomed out the pictures often cover the map itself too much to show the location. I sometimes use the map feature because I travelling a lot and people ask me: how does this and this country look like, and then it is easier to search on a map then in a collection of folders.

And when it comes to the ugly part. Out of box I did not find darktable very appealing but, darktable has awesome capabilities to style it just the way you want. I took one of themes from darktable as a starting point and modified it to my liking. And if you ask me, my darktable theme looks very pretty.

4 Likes

You may have missed this statement from @dfcsd
“ I’m spending 20h+ a week in darktable for years now”
:slight_smile:

4 Likes

Can we do better than this, please?

A person who has skills that are otherwise lacking I’m the current developer base should be welcomed and pointed in a specific direction where they can apply those skills.

From the otherwise, coming into something relatively fresh and starting off with “this sucks” seems like a great way to get nowhere.

11 Likes

Missed it I had, indeed :slight_smile:

Well, that’s what I tried to do when I said that more fine grained feedback would be very welcome a few posts back.

3 Likes

Personally, I don’t think the UI is all that terrible and even has some advantages over other editors. I’m currently testing a trial of a popular raw editor and found the slider controls are unforgiving in that you need to place your cursor directly over the “mark” and click it in order to move it with a mouse scroll, otherwise the entire menu moves up or down and you have to reorient. In DT you can simply move over the slider and the program knows what you want to do.

This other editor has very coarse increments and no keystrokes to refine the selection, and instead you click on the value and then hit the up or down icons to make single digit adjustments. In DT you have shift and ctrl commands that provide more control. And then the right-click adjustment (that I never use).

And the controls themselves are tiny compared to DT and it gets pretty tedious to make adjustments with precise mouse placements that send you off someplace else if you don’t get it right.

And I found all of these things to be a huge problem in getting white balance right, which is the most fundamental starting point for edits. It’s extremely frustrating to cycle between too much green and then too much magenta. Oh, and kudos to DT for providing a white balance adjustment on a selected area and not just a single point.

I’m not saying there’s no room for UI improvement, but it’s worth bearing in mind the things that DT gets right.

1 Like

I definitely think there’s room for improvement in the UI/UX, and I’m certainly no expert in that area so I can’t really say what’s right or what’s wrong.

One thing I would be careful of though is conflating “usable” with “opinionated”. Darktable does not have a standardized workflow. You mention the exposure module taking 3 clicks to get to. For my macro photos I almost never use the exposure module. Your UX improvement would be a UX detriment for me if suddenly I had to scroll past / hide the exposure module every time I edit a photo.

Personally I find that a huge strength of darktable is that it does not get in the way of itself trying to get me to use various controls. Coming from Lightroom where all the tools are expanded and I have to scroll through them to get what I want to do, this was quite refreshing.

1 Like

Andy Hutchinson has a post on the subject on his Substack, and shares a css with an example of a more pleasing (obviously subjective) style, if not a UI re-build. Is there a library of css somewhere, for comparison?

2 Likes

I think it requires a continual effort from all involved; it isn’t a one time thing.

This is proper proof that things are subject. I would not call this CSS modification pleasing in the least.

But if all that is needed to be “good” is a CSS theme, then it really isn’t that far off, is it?

4 Likes

As someone who has actually built a photo editor UI from scratch…

I think darktable needs in-program guidance for users advising what modules to use in what order.

The plugins should be tagged with info on what they do. Tone mapping? Linear editing? Display-referred manipulations?

Split the huge list of plugins into categories based on the above, and provide UI hints whenever someone does something inadvisable like double tonemapping or wb (linear) after tonemapping (now display referred), for example.

3 Likes

That is a little unfair. He does say that he uses it extensively and has done for years.He seems to be a dedicated dt user. Even if that comes with a dose of “despite…”

he (and others) makes good points. But even if one accepts a complete change of UI paradigm, to something more whizzy and “2026” might be a nice idea, the question remains: would it be worth it?

A huge amount of work, for people that may not be particularly inspired to do it, because they would rather be implementing new ideas and improving how things work and run under the bonnet. Work that many would greet with, to say the least, a big pushback. Not a lot of fun.

Would I personally welcome a redesign? No. Even though I do regularly look a panel of modules, customised too, searching for “Colour Calibration,” and find it really hard to see!

I am quite new to this forum and I feel that I should be treading carefully because anything I will say it’s likely already been said.

I completely agree that seeing all these “color” modules is not only confusing but it’s also made more complicated by the fact that their functionalities often overlap. In fact, I think you forgot at least another one, AgX, which, although it’s not specifically aimed to colors, it has a saturation slider and a second tab dedicated to rotation and correction of color shifts, plus… more saturation sliders!

The point is (as probably it has been said many times) this is not a genuine UI issue. This is the consequence of the way darktable has grown over the years and the way it’s being designed around the pixel-pipe paradigm and the stack-ability of the modules.

Wouldn’t be simpler to have just a global slider for the saturation? Or what about the possibility of creating a new slider for a user-picked hue, where one can adjust only that hue?

The problem is figuring out where to fit this functionality. Would the global saturation slider act early in the stack, somewhere in the middle, at the end? Or would its correction be applied in the same exact order of any other editing step? In the latter case we no longer have a pixel-pipe stack, but a history-like stack, which is a drastically different way of doing things, and not the paradigm around which darktable was built.

Plus, not least important, any substantial change to the functionality of any module will be strongly resisted by many users who have their own workflow, heavily rely on modules the way they are used to and which they apply sometimes in unorthodox ways (unorthodox for me, because I am still learning and I need some structure and some rules, therefore I stick with the scene-referred modules first and display-referred at the end, I don’t duplicate a module unless it’s absolutely necessary etc.)

Breaking with the past, not taking account of the legacy of a project, is not going to make things easier. And invoking presumed “industry standards” is not a good argument, imho, firstly because it’s an attempt to give external authority to what are, ultimately, personal preferences, secondly because some projects are designed to follow their own standard, which set them apart.

2 Likes

[quote=“paperdigits, post:30, topic:58799”]
This is proper proof that things are subject. I would not call this CSS modification pleasing in the least. [/quote]

Nor would I, as it is. But mostly about his colors. What I do like in a general sense is a better visual demarcation of controls / widgets, modules, etc. I.e., more apparently “content contrast”. But I’d definitely choose different colors. LOL

I debated with myself about even joining this conversation since I moved from darktable to ART a couple of years ago. But I still follow dt, so maybe (or not?) my comments can offer another data point.

Personally I don’t think the UI is bad, per se, but for the uninitiated it’s one part of a whole that can be overwhelming at first … for some variable value of “at first”.

For example, consider:

  • The topic of photo editing can be potentially complex and confusing, completely aside from any specific software.

  • darktable pulls no punches by hiding functionality, so it can be complex

  • darktable requires RTFM. But still many (most?) new users just tend to poke around in it. That was me at first… mea culpa.

  • The UI is full of buttons, levers, switches, gauges… you name it. Lots of little things that do stuff, not all immediately ‘intuitive’, many of which can positively or negatively affect the image.

  • The UI is visually low-contrast, so widgets don’t stand out.

  • Widgets, buttons, etc., are often tiny and detailed.

Put all this together and it can be visually overwhelming upon first contact, with all the modules, controls, etc., merging into this “starship bridge” of functionality, none of which has a big sign reading, “Start Here!” Yes I know there are some prompts after installation, which is good, but they’re kind of “pre-editng” things.

My comments aren’t a value judgement of good or bad, just observations.

All of us act and react with and to software differently, but personally I think a huge improvement could be making the UI less flat, tiny and monotone. I’m most definitely not talking about some early '90s “3D upon 3D” nested boxes, nor the current fascination with HUGE buttons and sparse layouts.

Rather just make the movable parts stand out a little more. Give some visual hierarchy to the UI with more visually obvious grouping / containers, shadows, etc. It doesn’t have to look as deep as a strip mine, but IMO it shouldn’t be completely 2D either. Judicious use of contrast and a little highlight color would help greatly.

I understand about not skewing hue and tonal perceptions while editing, but I suspect we might be a little more sensitive than necessary about that, UI-wise.

Just my $0.02, £0.02, €0.02 or whatever…

7 Likes

By standardized I meant 2 things: adhering to the well established colour grading practices when it comes to the module functionality and terminology and normalizing the already existing terminology within the app.

For example, Color Calibration becoming 2 distinct easily-recognizable industry-standard modules called “white balance” and “channel mixer”. Then, using industry-standard white balance values even if it’s “mathematically nonsensical” - it is expected that 5100K is what 5100K has been since before darktable even existed, instead of it being 4500K for some reason (had to figure it out the hard way and to this day I don’t even know if it’s correct).

Then, moving away from the “compsci graduate playground” where everything seem to be lumped together and actually utilizing the powerful module system as it should be utilized:

  • rework the existing modules to do exactly 1 (one) thing per module
  • extract similar configuration into dedicated modules that will be shared among all modules in the relevant part of the pipeline - single gamut compression setting, single midgray point selector, single white/black point selector and so on - so they don’t smear between different modules under different names and with completely different controls, or worse yet happen implicitly
  • normalize terminology and module names, (re)group if necessary
  • present a clear overview of the pipeline, its order (as per “enabled modules” tab) and where exactly in that pipeline you’re currently making edits, normalize module order to emphasize the direction of the pipeline (why are certain few modules marked as display-referred take place before the tone mapper by default? does this paradigm even mean anything anymore?)
  • reorganize the module headers to make module names more readable (especially if longer names are unavoidable as a result of normalizing the terminology) - the real estate is limited and currently with the intended workflows it makes modules indistinguishable
  • completely revamp the existing icons and semantics, better yet just use natural language to describe things

This is not even touching on the UI things that could be improved, just tidying up the existing modules and reorganizing them so they’re at least a little bit coherent and consistent.

5 Likes

Fair point. @dfcsd didn’t say that it’s unusable. They did say that it’s awful, though.

My point being, as I already tried to articulate, that we all agree that there is margin for improvement, and for one I am trying to do my part. But we need concrete examples of friction to work on, not blanket statements about how awful it is.

2 Likes

That’s the price for simplification. If there’s just one module for each basic function you end up with having a whole bunch of instances at several positions of the pipe because most functions comes with side effects that needs compensation afterwards …

There are simpler tools around - but that comes with a price …

Tbf to Andy, I don’t think he is claiming to have fixed the UI - just put a bit of lipstick on the pig :slight_smile:

Andy may have inadvertently stumbled on to one strength of the DT UI: the ability to modify and customize the presentation to meet your individual needs. I don’t know of any commercial program that provides you anything close to that sort of refinement

3 Likes

Indeed very subjective, I have the idea I am looking at a Christmas tree, for me I would never use this, so distracting! But this is also where dt shines, try this kind of customisation with lightroom….

One of the great aspects of darktable is its firm dedication to not breaking old edits. Refactoring the functionality across different modules might sound great, but the old configuration of modules would need to be retained to support older edits. It seems to me that this would significantly increase the maintenance burden.

1 Like