Poll: The Diffuse or Sharpen UI

Software
1

OK, here is a multiple-choice poll to gather sentiments about the diffuse or sharpen module’s UI. You can pick up to 4 items. I think this will be a fun poll. Hopefully you enjoy. Let’s be nice :slight_smile:

  • The UI is not technical enough
  • The UI is too technical
  • The UI is good as it is
  • The UI does not need a rework
  • The UI does need a rework
  • Future module UIs should be like D or S
  • Future module UIs should not be like D or S
  • darktable should prioritize: technically accurate UIs 1st, user-friendly UI/UX 2nd
  • darktable should prioritize: user-friendly UI/UX 1st, technically accurate UIs 2nd
  • darktable should prioritize: both technically accurate UIs and user-friendly UI/UX equally
  • darktable should prioritize: no GUI, only CLI
0 voters
3 Likes
2

“future module UIs should be like D or S” :smiley:

If anyone actually thinks this, I think they should be studied, for science.

7 Likes
3

Do I get paid?

4 Likes
4

Yes, here is twelve brownie points. They are invisible and don’t get you any closer to any brownies. But their yours. :laughing:

4 Likes
5

I know this poll has a lot of options. For that reason…

You can select up to 4 options.

6

I am not a good one to respond to this poll (even though I did), because I don’t actually use the UI, just the selectable presets. I suppose that means the UI is too technical for me.

8 Likes
7

Man. They were not kidding when they said funding for basic research has really fallen off. :laughing:

In all seriousness: I actually voted for it, because I appended a non-controversial (i think?) caveat. Module UI should be like DoS, if and only if, the complexity of the module control surfaces require it.

I would add that every effort should be made to create labels which are understandable by non-technical users, if and only if, doing so does not mislead/misinform/obfuscate things for a technically minded user.

4 Likes
8

I think it is well and good how DoS was designed. Its first implementation was technical and precise. Just like filmic, I did expect it would then go through several iterations and slowly arrive at a compromise between user-friendliness and accuracy.

Alas, AP left before that refinement could take place.

3 Likes
9

It is amazing how little they are willing to pay for research in the FOSS domain :joy:

I didn’t mean any options as a joke (except maybe the CLI option :wink:). And I agree with your caveat. I am not sure that I agree that DorS actually requires it’s choice of highly technical naming, but I agree in theory that some processes require technical jargon to make themselves useful/safe.

I agree partially. I think the experience of the technically minded user is not necessarily more valuable than the experience of the non-technically minded user. Because of this, I think decisions need to be made about which complexities to hide and which to expose. Those that are hidden, should be hidden to clarify/distill the usecase of the module. Those that are exposed should try to be accurate and user-friendly.

1 Like
10

I think everyone should respond, as long as they have looked at or used DorS.

I wasn’t around during those discussions, but I would love to go back and read some of the thoughts circulating at the time.

We could still do the refinement, as a community.

2 Likes
11

AP replied to the DorS UI change PR with a link to reference documentation describing DorS. At the end he had a perspectives section which said changing the names of things would only cause confusion and prevent understanding.

After a good nights sleep and lots of thought I realized that if we change the names and reorder the controls we then have

  • no useful technical documentation
  • no useful user manual for DorS
  • no useful DorS how to videos
  • no useful edit videos where DorS is used

Modules exist in an ecosystem so changing controls may not be a good idea unless all the supporting items change also.

9 Likes
12

I think this makes sense.
One thing that this poll hopefully shows is how future module UIs should be thought about and developed in the future. The vast consensus is that the current DorS UI is too technical. While it might not be possible to change that due to the points you bring up, we might be able to use it as a guide of what to avoid, going forward.

1 Like
13

Bill, your point puts everything in perspective. It is clear that the majority of people here wish the controls in DorS were named differently, but acting on that wish would render a lot of supporting resources obsolete.

A couple of ideas to possibly let us have our cake and eat it too:

  • (easier) Leave the layouts and names of the controls alone, but change the tool tips to provide more layman-friendly descriptions.
  • (more work) Provide a switch to allow users to swap control names between the technically accurate but challenging versions and an alternate set of names that more people understand.

But I also understand if the devs don’t want to change anything.

2 Likes
14

If the module is changed, we should work with some of the dt youtubers and help them make some updated videos. With enough prep work, they should be able to give clear instructions so we can avoid those videos which come out after a module is released where they have a good go at explaining, but then have to admit that they don’t really understand.

1 Like
15

We dont you propose improved tooltips. Explaining for the foto-friend,

4 Likes
16

That was already proposed in the PR and I think that’s probably what’s going to happen.

I also thought it would be nice if someone wrote a tutorial with publicly available images so that a user could follow the tutorial with the images on their own screen and understand what happens, but also be able to experiment.

The biggest thing that came out of this for me was realizing there’s more to a module than just the module. Sometimes we get so focused on the details that we lose sight of the bigger picture. There is an ecosystem around the modules, PR docs, user manual, YT videos, other resources, and it’s often an after thought

6 Likes
17

Rather than a poll why not make up some names as you think they should be, imagine you put sticky notes over the current ones, and then try using the module…I’m speaking to everyone not Tim specifically. Maybe we need a playDorS topic challenge… No presets allowed you must start to use the sliders to apply the adjustment…

Are there any users that use the module that way??

If so it would be good for them to share.

I basically only use the module to sharpen though I could I suppose find other uses.

I have about 6 presets that I came up with over time as derivatives of the provided ones and they are mostly tweaks of the lower edge protection/threshold/sharpness sliders mixed with adding a few iterations here or there and or opacity when the effect is strong.

They are versions on a theme as I find with this module, a preset that nails it for one image is not so great or pulls up noise and artifacts on another image… I seem to have about 3 or 4 favourites so I try each sometimes if my first choice is not great and then I will use sliders to fine tune that result

Some real world interaction from the user base might actually pull out what does or does not need to be done based on what people discover or share…

If you look at Aurelien’s recent documentation that has been mentioned a few times you can see how he summed up what might work and it was not a simple renaming exercise… He points out the nature of the many combinations of direction, speed, order and the magnitude of each slider used would likely require some sort of solver or ML to come up with a more predictive effect that could be summarized by maybe just 4 sliders…

This exercise may happen at some point but some UI changes if they work are more likely for now…

So given any set of names the challenge should be to go and try to use it in a targeted way starting from scratch and see how far you get and what issues or roadblocks are there…

I’m stuggling to keep up with things these days but if I can start something I will but others can perhaps jump in if this sounds like something of merit

This diagram I was able to extract is pretty decent in showing the terms in context but how would that translate to practice…

DorS Summary.pdf (623.0 KB)

2 Likes
18

this seems a good compromise. The names themselves are not important, but our ability to understand the controls is paramount.

2 Likes
19

I differ on this. The names are important. I hate the idea of having to step through sliders with incomprehible names to find out what they do from the tool tips!

And… tool tips themselves, although vital, are a bit of a pain. I’m grateful for them and absolutely use them when I’m having a bad a bad day, just need reminding, or doing something new. Otherwise I disable them for aesthetic reasons.

20

Why not just map the same parameters to two different UIs? Could have a simplified and an advanced tab and the user just picks whichever he prefers. Sure it’s a little more to maintain but we are only talking about sliders and tooltips, nothing that major.

It is very obvious that some users, myself included, just don’t want to learn how to use the current UI. I personally just use the presets, if I need any extra work I bump the iterations on existing presets and that’s it, if it doesn’t work, I use a different tool. I just don’t think it’s easy to form a mental model of what is going on as it is. We have users educated in the maths required to understand it and even they struggle, let alone the common folk. If the UI was reworked I would at least give it a try. This is not to say that we shouldn’t learn difficult things, but ultimately there are always some barriers which aren’t worth the effort, and this is one of them.

I don’t really get why I can use any other sharpening/diffusion tool on earth, unsharp mask, richardson lucy, contrast eq, etc, but not this one? I don’t buy the argument that changing its interface in a way that controls are not 1:1 to physical processes ruins the module. Since the dawn of mechanical and electrical engineering we have had simplified interfaces for very complex machinery and processes and it was never a problem.

4 Likes