Tool Edited Indicator
Implemented
I would be very helpful to have some indication of which tools have been adjusted such as changing the color of the tool name.
-
Offizieller Kommentar
Hi Michael,
Thank you for taking your time to give us some valuable feedback. I have forwarded your request for highlighted tools internally to our developers.
Best regards,
Jakob -
Yes, yes, yes, I'll vote for this.
I often work with many layers and modify values on several tools. It is not easy to identify the tools which are changed in a specific layer, I actually have to expand all the tools and check it is has been used / modified from the default.
It would be a great help if the tools used were easily identifiable, somehow.
e.g. by changing the color of the tools icon (however this would only be possibile with tools which work with layers)0 -
The only thing which is not easily solved, probably, is the handling of presets/styles. Would a user consider an asjusted value which is adjusted because of a preset as a change which should be indicated, or only if the value of the preset is changed manually. Or, distinguish both by two different colors?
Generally, I dot not like too many colors besides my images as they somtimes distrsct, but if the colors can be set in the preferences a user colud choose the same colors, if he likes, or different ones, or none.
regards
0 -
A trick I often use is to copy adjustments to the cipboard - then I check the clipboard to see what has been checked.
However the proposal here of highlighting the tool name would be much better.
1 -
Yes Eric, C1 knows what tools / sliders have changed. So it should not be a big problem to highlight these tools or even sliders.
0 -
The proposed highlighting could be enabled by consulting a per-image editing history.
Per-image histories have other benefits -- "undo" per image and available at all times & the ability to define "before" states when doing "before/after" comparisons -- and would be a nice way to activate used tool highlighting.
I argue against an unconditional highlighting of tools due to the distraction factor such highlighting would incur.
0 -
The visual distraction factor depends on the actual implementation, I agree it should be subtle. It could be switche off in the preferences and/or color be defined, if the highlighting is color-based.
Per-image editing history is a major effort, visually highligthing should not. I don't argue against this feature but I think it is something different, you could even implement the history without highlighting. If we mix too much we won't get anything... :-)
0 -
@BeO
First, I'm not sure anyone from Capture One is reading comments after a request has been marked "Completed". It could very well be the case that the developers only see an internal record that was created upon "request completion" and is never updated from then on.
Second, I agree that a preferences setting could take care of the distraction concern.
However, I believe there are three important points here:
- Feature creep:
A ton of requests could be handled on their own and preferences could be made to carry the load of making them optional. Ultimately, this would lead to a plethora of unconnected features and preferences that require minutes to scroll through. I maintain that pointing out the strong connection between editing histories and tool usage "histories" is helpful in that regard.
Many users have requested the ability to see which tools/edits were used for an image, expressing them in various ways. In my view, the image-history perspective provides a coherent view on all of them.
I believe it is important to aim at one functionality/tool to feed as many birds with one scone as possible in order to avoid myriad of somewhat related but isolated features.
- Potentially better realisation:
Highlighting tools helps, but if used tools are distributed over many tool tabs, finding all contributing tools remains still a bit of a hunt.
A consolidated tool usage view, as could be presented as part of a per-image history, could potentially be a better realisation of the feature request.
- Per-image histories need all the motivation available:
In my view, per-image histories are overdue for C1 and any further argument that can be brought forward to motivate this functionality should ideally help to reach a threshold, which once crossed, will convince the product managers that it's worth the effort.
In short, it was not my intention to stifle this request by making it hard to realise. On the contrary, I think it could potentially have higher chances to become a reality if it can piggyback on something that is almost too inevitable not to be realised at some point in time.
0 - Feature creep:
-
Hi ClassA,
0. I don't know either, probably it is not monitored, neither the later comments nor the later votes.
We are really not much apart in our opinions usually, as you probably also know, it's just nuances most of the time.
1. "Feature creep, .. unconnected features vs. feed as many birds as possible":
Yeah, but gathering the different requirements, even the small ones, and making a viable and good integrated concept or feature is product management and/or requirements management, and we are not in this role with C1. It is their job, and maybe they are willing to redesign something in order to fulfill many different requests, but maybe they just want to gradually improve in smaller increments. A broader redesign of a feature is not always successful (see exporter/output tools).In requirements management (in an ideal world) you gather all customers requests, extract the actual underlying requirements often by reading between the lines and eliminating the solution proposals from the request which are usually an inherent part of the customers request, and then select a good solution design (from several potential designs you've made) which best serves all or the major stake of the requests (depending on what you want to achieve). A long sentence which details what you have already said in a much simpler way "feed as many birds with one scone as possible". But the point is, you have suggested a solution proposal already, for a simple request.
This approach, and only this, helps to ensure a consistent product long-term. The agile method which is vey popular now tends to improve in smaller steps, shorter time to market, but has a tendency that the software becomes more inconsitent over time.
For me personally, I do not need a history, a simple undo (if it works) is sufficent to me. If I work with other software which offer a history I do not use it. But I see a high value (for me) to have a simple Tool Edited Indicator which represents the current (and only) "version" of a variant.
2. "Potentially better realisation:"
Better realisation across many requests see my point 1.
"A consolidated tool usage view" in terms of a summary is exactly a solution which I do _not_ prefer, it does not meet my requirement (which I made not clear enough maybe).
My request and requirement is to have the indicator exactly there where I did the changes. Because I need them when I want to change more or other or similar things.
E.g. If I return to an image later and I think a tweak with colors would be good then I would like to see easily that I have used WB and the Skin Tone Editor, so I could decide to visit these tool right away instead of going to the Color Balance tool and counteract what I might have done too much in the skin tone editor.Or, if I am working with a layer I don't even think that a color tool has been used and I do not think about looking at a consolidated summary. I am driving with the car and want an indicator that tells me to drive left or right, or that there is a bar close to me.
A consolidated view is something different, it's like planning the route ahead by looking at an analog map. I conciously do this at a certain time. Don't get me wrong, a consolidated view has its benefits as well, but it is something different and I more urgently want a simple tool indicator at the tool itself, to tell me there is a bar close to me.:-)3. "Per-image histories need all the motivation available:"
Maybe yes. But then it is better to list these motivations there, not here...
Cheers,
BeO0
Post ist für Kommentare geschlossen.
Kommentare
9 Kommentare