Module Group Improvement Mockup

[rvietor]

@PhotoPhysicsGuy

First I don’t think this is true, he suggested a certain UI-behaviour which could be distinct from the actual pipeline behavior as he referred to ‘other groups’. I read that as a list of inactive modules could be in alphabetical order. Second: in order to suggest a ‘better UI’ you do not have to know how and why the UI that he wants to improve came to be. Why? If the logic in which the modules are presented to an uninformed user is important, but doesn’t get communicated…that already qualifies as something that could be improved upon. Or am I missing something?

The problem is the “uninformed” part. Where do you communicate the logic behind the interface, when it goes beyond grouping modules by function? In this case, the pipeline order. It is explained in the manual, but new users have to read at least part of it. But then they are no longer “uninformed”.
And getting users to read a manual is hard, which is perhaps why camera manufacturers don’t bother anymore beyond the bare basics (of course, not providing a paper manual being cheaper as well, might have played a role…)

@PhotoPhysicsGuy

I will probably be able to adapt to any user-interface, no matter what, but my personal usage can adapt is not the reference.

Indeed, most can get along with about any user interface that gets thrown at them if they have to (and I’ve seen some “nice” ones on expensive scientific equipment I had to get along with…). But in case someone finds an interface suboptimal, there are at least two possibilities:

• the interface is bad;
• the way the user thinks/works doesn’t fit with the logic behind the interface.

Figuring out which of the two is relevant in any particual case requires the users to have some experience with the interface under discussion, as an unfamiliar interface will always feel clumsy. Even more so when the user has previous experience with another program from the same category (e.g. lightroom).

[paperdigits (Mica)]

@rvietor

I know I’m going to annoy you now. But, probably not intentionally, you come across as very opinionated and arrogant, in this thread and in others; both in your assumptions and in how you react to questions/criticism.

We need to keep the conversation objective and judge the ideas, not the person.

At the same time, @KristijanZic should keep in mind that the timing of this criticism feels like a swift kick to the junk to anyone who’s just spent a large chunk of time working on darktable.

[KristijanZic]

@rvietor

The problem is the “uninformed” part. Where do you communicate the logic behind the interface, when it goes beyond grouping modules by function? In this case, the pipeline order. It is explained in the manual, but new users have to read at least part of it. But then they are no longer “uninformed”.
And getting users to read a manual is hard, which is perhaps why camera manufacturers don’t bother anymore beyond the bare basics (of course, not providing a paper manual being cheaper as well, might have played a role…)

Christ, well then we have an onboarding problem. Let’s work on that then.

Blaming the users can’t ever be an answer. You can blame one or two, but not most of them. The user will just leave and tell everyone he had a bad experience. And good luck then shaking off that perception.

@paperdigits

At the same time, @KristijanZic should keep in mind that the timing of this criticism feels like a swift kick to the junk to anyone who’s just spent a large chunk of time working on darktable.

It shouldn’t, we’re slowly moving this to maybe a more immediate matter which should be the onboarding experience which transpired from the initial discussion. (that is if you filter out all the unnecessary discussion).

@paperdigits

@KristijanZic

Here we are venturing into onboarding which is non existent in Darktable. omg, I have so much more ideas right now to address the issues you’ve raised

Great, write it down and let’s get it into an issue.

You and I came to that conclusion in like 5 minutes. But everyone decided to overlook that and everything else of substance.

Anyway, I’ve expressed my regret about the timing multiple times, and I really mean it.

[paperdigits (Mica)]

@KristijanZic

Anyway, I’ve expressed my regret about the timing multiple times, and I really mean it.

Yes, thank you. I’ll leave it at that.

[PhotoPhysicsGuy (Bob)]

@rvietor

In this case, the pipeline order.

I’d say this is exactly what he tries to adress.

@rvietor

And getting users to read a manual is hard,…

Indeed. I would go so far as to claim that a software where you do not have to read the manual is one with a ‘good’ UI.

@rvietor

and I’ve seen some “nice” ones on expensive scientific equipment I had to get along with…

Oh trust me, I did too. But from that I also know the experience how defensive someone can get who just put hundreds of manhours of work into a interface that is…let’s say ‘full of possibilities’…and who cannot understand how someone else is confused by it. And that’s my experience, which leads me to believe that in many many cases, this

@rvietor

But in case someone finds an interface suboptimal, there are at least two possibilities:

• the interface is bad;
• the way the user thinks/works doesn’t fit with the logic behind the interface.

boils down to option1 and not option2 (If you give me just the two). A good interface for a progam with lots of options is a very rare thing. Most get only acceptable by hiding stuff from you.

With all that said:
I am sure the new Interface in dt3.4 is better than the old one and I think that is a really good thing.

[KristijanZic]

@PhotoPhysicsGuy

A good interface for a progam with lots of options is a very rare thing.

The thing is, it doesn’t even offer many customization options right now. You can assign groups and assign modules to those groups. That’s it. It’s not a spaceship, it can be made user friendly. It shouldn’t be a complicated interface for that many options. In a perfect world you wouldn’t need any customization options, the defaults would work just fine for anybody. And that’s what most people end up doing anyway.

And the work that has been done for the current UI is a great step in that direction. Let’s just not stop here.

[rvietor]

Looking at your mockup again, made me wonder how many modules (including multiple copies of e.g. exposure) you typically use. And how they would split in functional groups.

It makes a lot of difference is you have 15-20 modules in a list (which comfortably fits on screen without scrolling) or 2-3 x that many. Also having more than 3-4 lists will probably be hard to handle.

For the typical images I work on, I don’t need more than 20 slots in any one logical group, and that includes inactive modules. So the current interface of customisable groups works very well for me and does not feel clumsy. Complicated, yes, but dt is not a simple program.

[Silvio_Grosso (Silvio)]

Hello everyone,

Complicated, yes, but dt is not a simple program.

I fully agree
I am extremely grateful Darktable is more and more “complicated” these past months. It means it is steadily reaching the amount of features currently available with other commercial softwares (Lightroom, Capture one etc).

In all truth, I have read with great interest the whole thread because there have been very constructive suggestions

I my view, most of the frustration about every GUIs is due to the fact that most users have a previous experience with some commercial standard sosftware and they usually expect to have the same workflow with the open source softwares they try. In my opinion this is 100% normal behaviour and it should not be criticised. The only big problem with these “expectations” is that quite often the commercial softwares have plenty of full-time developers to work full time on the GUIs and even so it took them many decades to reach their standards (think about Photoshop, ArcGIS, AutoCAD etc)

[KristijanZic]

For a scene-referred global edit I use about 15-30 modules without duplicates. It’s usually around 20-25.

But when I go doing local edits that’s when every issue comes up. Multiple duplicates of multiple modules, multiple masks multiple modules using the same mask (that’s also a hardpoint but I do not dare to say anything, yet). When doing local edits only the sky is the limit to how many modules you can have on the image. (I guess gpu cpu and ram would be more limiting than the sky ).

That said, even when just doing global edits, I have a lot of modules in the “unactive” groups b/c while I may not use every single one on any particular image. I do use all of them regularly for different images that require different editing approaches.

@Silvio_Grosso

I my view, most of the frustration about every GUIs is due to the fact that most users have a previous experience with some commercial standard sosftware and they usually expect to have the same workflow with the open source softwares they try.

Believe me, I just want a node editor, but then we can forget any new users or converts from other photo editing software

[peterdb (peter)]

Imho the issue isn’t the actual GUI. Works fine for me.
Whatever is proposed to modify the GUI, the issue will remain : it’s the onboarding and the expectations new users have coming from other software.
A great introduction video would be great, since people indeed don’t wanna RTFM. Or a message on first start-up linking to the (great new) manual and youtube or whatever.

Please don’t touch the GUI.

[rvietor]

@KristijanZic

For a scene-referred global edit I use about 15-30 modules without duplicates. It’s usually around 20-25.

But when I go doing local edits that’s when every issue comes up. Multiple duplicates of multiple modules, multiple masks multiple modules using the same mask (that’s also a hardpoint but I do not dare to say anything, yet). When doing local edits only the sky is the limit to how many modules you can have on the image. (I guess gpu cpu and ram would be more limiting than the sky ).

Right… We’re clearly not playing the same game here. For global edits I usually top out at 15 modules in scene-referred, and that includes the defaults I never need to touch… and for quite a few others I have defaults that work most of the time, so 5-6 that I have to adjust per image…

[KristijanZic]

@rvietor

And how they would split in functional groups.

The groups I did in the mockup are just placeholders. I don’t know for sure what groups would be needed and how many.

I just think (talking for the mockup still), it should be sorted in more groups because currently everything is sorted by the way module works on the algo level as I understood. And that means nothing to an ordinary photographer. It means something to those who Aurellien would call full stack photographers.

So I would either abstract the naming of the groups or make it even more precise. But I wouldn’t have a group called technical for example. I’d separate that in a few groups: calibration, reconstruction, correction or however else. It would (to me and on paper) make more sense.

I also wouldn’t hide any modules. I’d try to guide a user, but eventually I’d like him to learn by trial and error. That’s a good way to learn I think.

@rvietor

Right… We’re clearly not playing the same game here.

I live of photography and videography and do all kinds of stuff to put food in my mouth and unfortunately I live in a country where the standard is so low that if it wasn’t for the FOSS software, I wouldn’t be doing what I do at all (I’d probably pirate it like everybody else but that’s beside the point). That’s the main difference hehe
Like, if I had to pay for all the software that I use (OS, Office, various software for multimedia etc) that would be it, my life would be ruined xD
So since the price of photography and videography is very low here and the price of equipment is >30% higher than in the US, I have to be able to produce incredible volume of images on a crazy pace and every bit helps. When you also account for running costs like gas etc (the more you do the more you spend) at that point any advantage you’ll give me I’ll take.

end of personal stuff (thanks for reading), real answer bellow

The thing about local edits is that in DT you need many masks and modules, what would be a few modules and a painted raster mask. But that’s a whole another game that VKDT will hopefully solve.

Like I have images, where the edit looks nothing like what was originally shot. You can even tailor your scene in a studio in the way that will make it easier for you to edit or mask something etc.

And I need to do crazy editing because I don’t have enough money to invest in crazy equipment let alone keep up with it. And I don’t need it, if it can be done trough editing.

[paperdigits (Mica)]

@rvietor

Complicated, yes, but dt is not a simple program.

Someone recently described it as complex but not complicated.

[paperdigits (Mica)]

@peterdb

it’s the onboarding and the expectations new users have coming from other software.

please read the new docs and make PRs and/or suggestions.

[peterdb (peter)]

Reading the manual was the first thing I did some years ago when I started using dt. Now and then, especially after updates, I read some parts again. But we all know not all (new) users are willing to spend some time here.
Since the new manual is so great and up-to-date now, my point is : lead new users to it with for e.g. a message on start-up. Once a new user has some basic understanding of the way dt handles things with it’s pipepline, he/she will adapt dt’s GUI imo.
With the great options possible now to customise the GUI, my point is I see no reason to change it for now. I wish to thank the devs for all new implementations. Keep up the good work.

[afre (Alan)]

There is also the option of forking. Look at what @agriggio did with ART. (Much more than UX.) An example of rejiggering from ground up is vkdt by @hanatos. The beauty of FLOSS.

I mentioned Photivo. It allows you to sort the modules by pipeline, alphabetical and favourite orders. I know dev has stopped for a very long time, but it is good to look at from time to time.

PhotoFlow allows to you to add the layers/modules you need and you can group them, etc.

[KristijanZic]

@afre

There is also the option of forking.

No no no hehe
This is just brainstorming and hopefully having fun with designs.

Well, it’s a debate club also apparently but all in good spirit.

[guille2306 (Guillermo Rozas)]

@peterdb

Since the new manual is so great and up-to-date now, my point is : lead new users to it with for e.g. a message on start-up. Once a new user has some basic understanding of the way dt handles things with it’s pipepline, he/she will adapt dt’s GUI imo.

More than a simple message with a link, I would suggest something like the on-boarding experience that Siril has now: a series of ‘bubbles’ pointing to the different important parts of the interface (like an interactive in-place version of the user interface section of the manual). And then finish with a suggestion to specifically read the basic workflow section of the manual.

[priort (Todd Prior)]

You sound like you want a graphics illustration program or Davinci Resolve like editor not a raw editor…

[KristijanZic]

hah, it kinda does sound like that. But it’s actually really where DT is going anyway. It’s pretty much that already. With a flexible pipeline someone will eventually create a node graph editor. And dtvk will solve the painted raster masks. And there you go, a software that can do everything raw. If it could give the user a massage too, it would.

I’m not gonna say there aren’t many things that need improving but only way up from there is AI/ML. Everything else is already good enough.