I was watching this video about the development of audacity and at some point Tantacrul talks about the conflict between improving the software for new users and alienating your existing user base with too many changes. He then explains how they’re planning to use a pop up window the first time you use Audacity to help the user set some defaults (“classic” vs “modern” look, plus some layout choices based on user case). A very simple pop up with two or three steps (if its too complex it will put new users away).
Since the choice of a tone mapper is something every user will eventually run into or hear about, wouldn’t it make sense to let them choose it the first time they run darktable, while providing a brief explanation of each one (that they will inevitably look for elsewhere at some point)? Something in the lines that filmic is somewhat a legacy option, more for backwards compatibility with older edits, then sigmoid and agx, with one of the two being the actual recommendation. And some message like, “don’t worry, you can change this at any time at etc etc…”
From a new user’s perspective, it cannot be overstated just how useful it is that the program emphasizes one option over the others, or describe their different user cases. I think it helps with feeling secure (literally in a psychological level) with your tools and with establishing a workflow faster; and just setting one as the default doesn’t convey a clear enough message about this.
I’m not a developer or a designer, I just caught the idea from the video, so I’m sorry in advance if this idea has some obvious flaws that I cannot see.
Along the same line of training, I would advocate that 90% of the users probably never need to touch 90% of the configuration options.
If this can be verified, it would make a lot of sense to consolidate the remaining 10% of the options in a single preferences panel and move all the rest behind an “Advanced options” panel that most users would never need to see. This would go a long way towards making DT fell less daunting for new users.
As an example, the current default workflow is sigmoid scene referred. New users should just start using that, without having to wonder about the difference between sigmoid, filmic and display referred workflows, which for a profane must be (understandingly) very arcane.
Why not? Sigmoid gives a pretty nice look out of the box. If a new user sees a decent starting point, is that not what is wanted?
I think the defaults that are in the current panel are pretty good, and a new user shouldn’t touch any of them unless they’ve used darktable enough to have a preference.
I’m not convinced that we are trying to make a tool that will attract every photographer. That are already tools for that and they have gigantic budgets, designers, and all that stuff. If you want ultimate ease of use, this is probably not the tool for you.
I know every new user has this fantasy that dark table will suddenly want to start targeting them directly, but I don’t feel this is true at all.
Further, we are at the point where we need actionable feedback. “Hide 90% of the preferences” isn’t actionable.
Frankly, what dark table really needs to be approachable is to show like 10 modules by default and that’s it. To say to the user “these are the best, most flexible modules we have, learn these” would clear up a lot of things.
Feedback is always great and thank you for taking the time to share, but we need actionable feedback that a Dev can take action on.
I would agree and at the same time argue though that they should review them all…I can’t imagine using software in a serious manner without going throught the tabs, panels or however the “settings” for the program are presented… Otherwise you could be fighting against a setting or assuming something or really missing a feature that might fit better with the way you want work…
I have seen a ton of posts from people that clearly are not even aware of the preferences or have never ventured in there…even at times complaining about something that can be changed suit them if they just looked…
Also whenever we make comments like ten percent of this or ninety percent of that who determines what falls into those groups…I don’t think we have usage stats to back anything like that up…
Im sure a fancy startup routine that walked people through the basics would help guide some users but someone would have to have the time, skill and desire to do so…
Agreed, but before coming up with an actionable proposal one should understand if there is an idea worth pursuing.
Well, yes and no. I would guess that almost everyone wants to configure the path to the library root, or how to name the directories created when new photos are imported.
If the devs think that there is value in this idea, one possibility would be to add to the UI an allowance for users to share with the devs the ids of the options that they edited. After collecting done days we could have a clear idea of which options most people generally change.
Of course not, but I think that we all agree that the more the merrier. More users, more ideas, more contributions, more progress. User base stagnation is the beginning of the end for every product, software included, and I think we agree that this is not what we want.
if you would show too many options to new users when they first time enter the program they might not even know what to pick.
the prompts in a the moment of first time doing an action like “ripple or non ripple mode” example shown in the video might be useful but also need to be used not too often
also the “remember the path used last time” (from the new score wizard in Musescore) could be useful in some places.
I am also like that, but we are also clearly not the average potential user. And when I say “we” I mean almost everybody who reads this forum.
It would be a mistake to assume that only technically proficient users are interested in DT. On the contrary, there is a lot of anecdotal evidence that many potential users try DT and then give up.
I think we shouldn’t try to tend only to the technically savvy, because this can create a detrimental feedback loop. Every software needs a solid user base of more simple minded users because they are (1) the vast majority and (2) the ones that force you to keep complexity under check.
This has come up so many times…at the module level and the DT UI level…
You can see where it often goes…
DT could have any number of things if the “we” dive in and participate…
Recently @kofa dove in to try and take a journey of learning with his work on bringing the AGX module to DT and I think it is going to take the same thing to happen for something like this…people proposing ideas need to take the ball and run or as @paperdigits noted put an actionable item in into a feature request and see if anyone bites… I think its often hard with limited resources to stir up people to do UI stuff. I do see amazing things done with lua scripts…someone might be able to create a module where you could add selected or key configuration settings and have them readily filtered accessible or maybe lua could do a sort of initial config set up. For sure I don’t have the programming chops for it or at this point the time or desire but someone might…
I can’t thank enough the devs for the time, effort and knowledge they put into darktable. I didn’t mean it as a complaint in any way, and I don’t think the suggestion comes from a fantasy that the devs will target me directly, on the contrary. I have a great enthusiasm for the software and really like it the way it is. I just wanted to voice an idea I saw in a video, which I thought was actionable enough, and see what people think. I even put a question mark in the title of the post.
As a side note, I don’t understand how it is not in the interest of the developers to expand the user base - obviously this interest has to live with many others. You seem to imply that I want the project to shift its focus entirely to a different kind of user who likes ease of use above all else. All I suggested was a pop up with some information and choices the first time the program runs.
As I said, I’m not a dev or a designer, so I have no idea how much work would go into this, nor if it would be as effective as I think it would. If you guys think that it would be ineffective or would go against the principles of the project, I’ll gladly change my mind.
Commenting in this forum is participating. Raising issues that have already been raised is contributing, as it may steer the devs to reassess priorities and reconsider choices.
I find that the argument that the only way to contribute is to come up with concrete plans or implement something is misleading. The endgame is a software project in which a group of devs only writes code for themselves without listening to the user base, which I am sure it’s not something that anyone wants.
Point in case, I do not have any means to collect statistics from DT users. I can come up with an arbitrary proposal, but I would prefer a data driven approach.
Unfortunately I m do not have free cycles to learn a new code base, implement the required instrumentation and go through all the required approvals. So I am just hoping that enough people will support the idea di that some dev might decide to go ahead and do it
More people > more noise > more support issues. In theory that is all good and well, as long as a proportion of those “new” people put in the effort to do support, triage bugs, respond to the people who demand an answer without trying to solve their own problem. At some point it just doesn’t scale. How much more time are the people who are here willing to put in? I don’t have the answer to that, but I’m pretty much at max.
I’d still like an answer to this.
The idea is good. But to be honest I’m not sure that as our numbers has grown that we have seen an uptick in repeat developers.
When people say “I can’t code how can I help?” We say “write the manual! Translate! Test the software!” But the manual is still out of date (big props to the few people who are stepping up!) But it is still not enough to have an up to date manual. Writing the manual is boring, and people want something more glamerous I suppose.
Personally at this particular moment in history I am really happy that darktable collects nothing. I understand what you’re saying as well, and agree in theory its a good path, but its a path we have never done and I’m not sure we have the appetite for it at this point. Of course I don’t speak for the project, just sharing what I’ve seen in dt’s history.
I am also against telemetry. But you could show a popup una tantum that says (conceptually, ux refinement pending)
“It looks like you have changed N options in the preferences. Would you mind sharing the names of the fields (not their values) with the devs so that they can come up with s better settings panel?”
Two suggestions:
Forward lookig (probably in place already, but maybe not enforced from the beginning): code submissions are only accepted if they come with comprehensive, high quality user docs.
Backwards looking: for the next point release the only accepted submissions are user facing docs.
Probably you already considered them, just in case
I don’t see an easy answer to please everyone. However, I agree with Mica
Maybe, somehow encouraging new DT users to master certain modules first before exploring deeper would help people adapt to a new program. I strongly recommend Sigmoid for a new user and they should stay away from Filmic or AgX until they are more experienced. Even trying to discuss the differences in these modules is likely to lead to confusion and turn new users off.
When a new user looks for external resources, workflow videos, documentation etc., they will inevitably find out there are other tone mappers besides sigmoid. They might see cool edits that have been done with filmic over 4 years ago, or brand new edits with agx, or videos comparing all of them and so on. Then they’ll try to learn what each one does differently and they might fall in a rabbit hole. If there is an intended default, wouldn’t it be good that the dev team has the first word about this default, and why it is the default? Like, laying the first step of the learning curve? A simple thing that reflects the developer’s present vision of how processing with darktable works, and yet let people know that they are choosing something (that can obviously be changed with a couple of clicks).
I did want to try and contribute to this but I found the process challenging to master and felt my attempts to help were more of a hinderance than a help. I guess I should revisit this and try to contribute in some way. Is there a guide or useful source of information on how to correctly contribute to the user manual?
