Please, please, let us name variants!
This seems like would be a very simple thing to implement. Create a variant and be able to label it.
Now that I am printing it seems even more obvious. Let's say I make a clone variant and make a few small adjustments to it for a certain paper. Then I print. So now I have a variant that looks very similar to the original, and I will completely forget what it was for a year from now.
Am I missing something? Is there a good way to keep track of variants?
Now that I am printing it seems even more obvious. Let's say I make a clone variant and make a few small adjustments to it for a certain paper. Then I print. So now I have a variant that looks very similar to the original, and I will completely forget what it was for a year from now.
Am I missing something? Is there a good way to keep track of variants?
0
-
At the very minimum, you could add some keywords for commonly used varians. Like "print" or "extra sharpening" or "black and white" 😊 0 -
In addition to Glogg's suggestion you also have the possibility to use the IPTC fields - pick one specifically for your printing intent purpose and then set that to be a displayed filter option perhaps?
Grant0 -
If you want to suggest the feature as a future enhancement it would be best to create a Support Case and put "Ehnhancement Request: <summary description>......." in the title line and your suggestion in the body of the text. 0 -
Thank you all for the suggestions. I will definitely put in a request. It just seems like such a simple thing. 0 -
[quote="joshkuhn" wrote:
Thank you all for the suggestions. I will definitely put in a request. It just seems like such a simple thing.
It does seem simple doesn't it.
At face value is might be.
I bet making use of it in all the ways people would expect may not be so simple to deliver.
If you could not have used naming in any application you have ever used, how would you have dealt with the challenge?
Is there another way of working that you could have adopted?
Grant0 -
[quote="SFA" wrote:
[quote="joshkuhn" wrote:
Thank you all for the suggestions. I will definitely put in a request. It just seems like such a simple thing.
It does seem simple doesn't it.
At face value is might be.
I bet making use of it in all the ways people would expect may not be so simple to deliver.
If you could not have used naming in any application you have ever used, how would you have dealt with the challenge?
Is there another way of working that you could have adopted?
Grant
Not exactly sure what you are saying.
It would probably be harder to implement than what it would be worth?
I should just figure something else out?
That is all fine, but there are reasons software gets better and easier to use over the years, not?0 -
There is a downside to naming variants, too. If I have an image called DSC1234.NEF, and I make a second variant and call it Narrowboat B&W.NEF I have no way of knowing from the name what the second variant is a variant of.
Ian0 -
[quote="Ian3" wrote:
There is a downside to naming variants, too. If I have an image called DSC1234.NEF, and I make a second variant and call it Narrowboat B&W.NEF I have no way of knowing from the name what the second variant is a variant of.
Ian
That is one thing that had crossed my mind.
To overcome that one keeps the original file name and adds a secondary name one may as well do that for all variants so that one can see all files and variants by either (or even both) names.
Pretty sure there is an IPTC field for that when used by photo libraries.
However, making all of the C1 functionality work by using either (or both?) naming conventions may be a lot if work and a lot of testing even if not especially difficult.
If enough people create support cases we could expect the suggestion to be considered in detail. I suppose it is possible that it already has been through that process.
For a Support Case to be most useful for enhancement suggestions it really needs to make it clear how the user would expect to be able to make use of the function. So in this case just suggesting the use of a different name for a variant is probably not enough to make the Case useful. It would need to indicate how and where that additional name could be used in the opinion of the requester. Only then could the generic idea be converted into a use concept with some degree of user expectation associated with it.
All just my opinion of course.
Grant0 -
For a Support Case to be most useful for enhancement suggestions it really needs to make it clear how the user would expect to be able to make use of the function. So in this case just suggesting the use of a different name for a variant is probably not enough to make the Case useful. It would need to indicate how and where that additional name could be used in the opinion of the requester. Only then could the generic idea be converted into a use concept with some degree of user expectation associated with it.
Eloquently put. Additionally, the extra detail as to where it would "fit" into a workflow would give us the opportunity to suggest alternative and currently available options.0 -
[quote="Ian3" wrote:
There is a downside to naming variants, too. If I have an image called DSC1234.NEF, and I make a second variant and call it Narrowboat B&W.NEF I have no way of knowing from the name what the second variant is a variant of.
Ian
This isn't how I was thinking of it.
Not renaming anything, but only labeling the variant. Then if you want to rename on export that would be fine.
My workflow would be "create variant", "right click, name variant", "type in a name".
You could choose to have it show the variant name under the thumbnail or in the photo information. That is really all I want.
I could very well just be naive, knowing very little about coding software, but I really don't see this being complicated.0 -
Josh,
Indeed that sounds very reasonable.
The problem for developers (in my experience in completely different markets) is that every other person has a different idea of how the functionality (yes, even something as simple as that which you describe) should work.
So you want a field for an alternative name and the ability to choose that field or the original when viewing and naming.
The display selection would have to be applied to all places where the name might be displayed or otherwise used.
It would likely be required in the "token" naming facilities.
It would probably have to be the basis for some sort of Album/Collection facility.
I doubt people would accept it if it was not included in search routines.
Or filtering in some way.
Some people would surely want dual display of names.
Proof prints would likely need to be adjusted.
Keyboard short cut would be required to toggle the field on and off.
If a new field was introduced to the database to accommodate it the database definition and structure would need amendment and some form of conversion and updating of existing catalogues and albums would be required - something that all users would have to run too when updating no matter whether they had any desire to use the new facility.
Back when I was involved in implementing business systems and clients were paying for adaptations they felt they really needed (which then became part of the standard system at a later release) we reckoned that one in ten clients used the functionality they had instigated and only half of them used it as originally intended. But once we had included it all customers had the opportunity to dive in and suggest how it might be improved - at least as they saw things.
It was easy to see resource being drained away for no benefit whatsoever to anyone.
It's not all one way traffic though.
As a "user" of system I have been party to a number of development ideas, some of which have been widely adopted when they were released without anyone realising how popular they had become. Others, which were clearly of huge potential benefit as everyone agreed when the specifications were being developed, seem to have never been used at all and were dropped during later versions due to lack of development time leading up to a release.
After a while the developing company started to realise that no one was asking where the functionality had gone. They put this down to users not always updating to the latest version. After 3 more versions had come and gone they finally heard from a client who actually used the functionality a little - but not so much that if stopped than upgrading due to the loss of the features.
The time and effort that went into that part of the program were entirely wasted and could have been much better deployed in other areas to the advantage of all for several years.
It's situations like that which have led me to be cautious about expectations of users when new functionality is suggested for any software.
Firstly one should seek to discover exactly what is the intended use and can it be satisfied already in some way or with very little change (basically what you expect, Josh). If it can, great. If it satisfies a wider user base as well, even better.
But if it opens up the apocryphal "can of worms" of expectations, or might have the potential to do so, then a very careful assessment should be undertaken before committing to anything.
All just my opinion of course. Others may take a very different view.
Grant0
投稿コメントは受け付けていません。
コメント
11件のコメント