Identify tools which have been used/changed
Not currently planned
What problem do you see this solving?
When revisiting image edits, and especially when working with layers, it is not easy to identify the tools which I have used for adjustments, I actually have to expand all the tools and check whether or not it has been changed (modified from the default).
It would be a great help if the tools with changed values were (somehow) easily identifiable even in its collapsed state. Many other raw editors have such an indication, and this has a reason.
It would also be good to identify any Tool Tabs which have tools within them adjusted, so thus a better color might be, say, green, because the Tool Tab which is in use is already marked orange; or some other more subtle indication if another color would be too 'screaming'.
It is particularly useful to have the tabs in the Color Editor, Color Balance and Levels tools identified instead of having to click through all the tabs to check which and if they have been adjusted. This is all very time consuming.
When was the last time you were affected by this lack of functionality, or specific tool?
Every time I work with Capture One editing images.
Are you using any workarounds or other solutions to achieve your goals in Capture One?
There is no workaround in C1 other than opening all tools and see if the values changed from the default.
Are you happy to be contacted further about this suggestion or request?
Yes.
-
Hi Mathieu B,
Thanks.
I was thinking about a roadmap which looks almost a year into future, contains only the bigger items, without guarantee that it will be implemented as it is only a plan ("as of now"), send via the same channel as the marketing mails, so,to every user, inviting for a discussion.
Or, even give alternatives for voting.
Regards
0 -
Sorry for missing this BeO - an open roadmap is something we have been considering for a long time, we would really love to do it.
It's however incredibly difficult to do, as requires a lot of expectation management on the customer side.
Plans change, sometimes extremely quickly. Things we thought possible reveal themselves impossible to do. Research that we conduct before commiting to an idea sometimes invalidates completely our initial thoughts. Our visions for the future get shifted by new technology breakthrough, both external and internal.
So at the moment, this forum is the closest we have gotten to an open roadmap. It's not perfect as it's missing all the things that do not come from this forum.
To conclude, our goal is to improve on transparency, and we are slowly but surely taking steps in this direction.
0 -
Thank you for coming back, Mathieu B
Let me share some considerations please.
You mentioned your "visions for the future". That is another topic, on a higher level than a roadmap, that usually spans a longer period into the future and includes target market considerations and competition. Maybe it is formulated on your website and I missed it (in that case sorry for that), but I would love to see that communicated as well.
A roadmap is a plan to implement the vision. (not only, but this is a big role a roadmap fulfills).
You are totally right when talking about customer expectation management, absolutely.
However, in absence of a commincated vision and roadmap you have to manage expectations as well, in hindsight. All the voices from customers who are unsatisfied with the evolution in the more recent releases also need some care/"unsatisfaction management".
Would you have a roadmap (and maybe even a voting system) which reaches a big stake of your customer base, not only the few here in the forum, then you'd have to manage the voices from those who are unsatisfied with your plans too, but prior to decision or implementation, which would give you the distinct advantage to be able to change plans, in case you notice that one or the other feature decision would not be favored or prioritized by your customers.
An example which comes to my mind is the removal of the "process" (now "export") tools in favor of the export dialog, which you earned a lot of pushback for, because you had no idea (apparently) that it is a major feature for a major stake of your customers. You consequently brought it back, which is excellent, but this could have been avoided in the first place.
(This is not the best example for a roadmap item, because roadmap items usually are about new features, not removals, but we don't have a roadmap yet to bring examples to the table).
Similarly, for planned features, you could get a lot of valuable feedback in a very early stage.Don't be afraid of customers reactions, use them to your advantage.
Regarding expectations management.
Plans change, sometimes extremely quickly. Things we thought possible reveal themselves impossible to do. Research that we conduct before commiting to an idea sometimes invalidates completely our initial thoughts. Our visions for the future get shifted by new technology breakthrough, both external and internal.
In this context, it sounds a bit as if you used this as an excuse for not having a public roadmap, but on contrary, in my opinion this statement is already a very good start for expectation management.
And there are always roadmap items which are internal, and others not yet ready for the public (for various reasons), so full transparency it not expected, nor is it needed.
The broader the base of customers is who you let contribute to your plans (i.e. in discussions, but better via a voting system for better statistics and maybe less need for justifications from your side), not only the few forum users/voters and other (assumed few) contacts into the market, the better the software fits the market, will better fulfill existing customers' needs, keeping them with you, reach ex-customers (e.g. if they are still in mailing lists or hear from online communities), and consequently also attract new customers.
Reserve the 'right' to decide or prioritize differently from the voices and votes, and to not put every feature request in the roadmap, as you already do. (but wait, make an exception for my requests :-))
Maybe you'll find some food for thougths and encouragement above.
Cheers,
BeO0 -
Thank you for the detailed post, I appreciate the discussion :) (but we'll need to keep it short to not pollute this topic further)
On a few specific points:
- the voting system is on this section of the forums, as you know you can upvote or downvote any idea posted here
- a pure voting system cannot be our compass, otherwise we're a feature factory doomed to re-create what exist elsewhere - hopefully you have chosen Capture One for some of the things we have done differently. Some of the things we will do in the future will solve real problems in a way that noone else is doing and noone here has requested (hence the emphasis on the problems in this section, rather than on the solutions)
- these forums and other "public" channels of communication where users could vote are not enough to gather feedback from all of our userbase - some of the research we do is in the form of us reaching out, rather than receiving the feedback. A voting system in those cases is not the right tool.
- the process tool mistake was a combination of several factors, the lack of internal knowledge being the smallest one - whatever it was, we're a much different company today, this should never happen again :)
0 -
Hi Mathieu B,
Whilst I appreciate your reply your answers indicate that you did not understand me, I was in no way suggesting a pure voting system for product management, nor a feature factory driven by requests from users and nothing else, on contrary it is important that the product management is the captain of the ship and has a vision and ideas.
But if the users are one of the input channels, and they need to be, then you should broaden the road to you.
Relying on the few voters here, passively, waiting for users requesting and voting, is not sufficient in my book, 98 votes is the highest number for any item for the desktop version and a whopping 7 votes the high-score for the mobile version. And you have how many, 200k+ customers?
And "some of the things you will do in the future which will solve real problems" no one here ever asked and no one else is doing, if they are not a secret could be part of an 'election' process. If no one asks and no other competition is doing it (that's how I read it) then it is questionable if it is not created in an ivory tower.
Anyway, I'm really hoping that I'm wrong and you will be succesful.
0 -
If you want to be the captian, which you should, then you could come up with a roadmap with the items you envision, sourced from many input channels, balancing all stakeholders interest (customer base, program/product management, investor, sales&marketing, development/IT) and bring those items which are of public interest and not a secret to a broad customer base e.g. via a mailing list for voting to test your roadmap and allow some guidance from the outcome, because at the end it must sell and generate revenue. Believe me, I am decades in exactly that business, and if there is something more important than any other, you need to understand (not agree with) your counterpart, whoever this is, and it includes your customer base.
0 -
You are reading too much into my answers :)
The road is broad and this forum is just a fraction of the feedback we get.
With your experience you know that every business and every user base is different. You know that different user groups need to be reached in different ways. You also know that finding a problem and creating a solution are two different activities and that none of them can happen in an ivory tower.Our problems, solutions and roadmaps are tested, even if you don’t see all of that on public forums.
0 -
You are probably right that I read too much into your answers, and I agree with you that I know this all.
Anyway, you said you would love to publish an open roadmap but you are not there yet, it seems that getting feedback for that roadmap from the whole of your user base, as I suggested, is not a reason for you. Maybe the forum contributors are a representative sample and all is good.
Let's go back to normal business.
Regards
0 -
Thanks for today's upvotes.
1 -
And thank you for the upvotes from me too!
This would be a VERY useful feature0 -
I too, would find it very useful to have an (colourful) indication which edits were made. Just highlight the tool's header in bold orange (in closed and open state) if there are values that differ from default.
And maybe a new (ineditable) tool with a "summary" of all edits which I would then pin to the corner of my secondary monitor?
2 -
I wish these would come in future - looking for tools that have been used is very very time comsuming and annoying.
Look at videos from paul reiffer - he is searching nearly every time he looks at picture from other people...
and so i am when visiting "older" pictures.
A simple colour tag in the headline of a used tool could do it.
This should be simple to implement.
Kind regards from Stuttgart
3 -
Colours are distracting, but I am confident the C1 team could find a subtle but clear enough way to implement this requirement.
1 -
I have brought this up in the past as well. As C1 improves I frequently revisit older edits to try a newer tool or tweak an edited photo, and remembering what tool I used in every layer is not possible. It would be such a great help to see at a glance which tools are used in a layer, perhaps by a subtle color change in the tool name.
0
投稿コメントは受け付けていません。
コメント
44件のコメント