Default values

[buah]

In my wildest dreams I couldn't imagine that after just 5 months of using it PVD would be my sole movie database, that it would have 5764 visible movies (in collection), with the database size of 1,5GB running smoothly on my 8 years old desktop, and it rapidly growing further.

And it feels like I use PVD for ages. I have never been so committed to any piece of software.

It is hard today to suggest anything that it isn't already implemented, or on TODO list, so perfect I find it. At the moment, I only see a room for improvements regarding time saving.

So, considering the fact  that I use PVD intensively, let me suggest one more possible improvement. In fact, I found it pretty handy if it could be possible to define default values for as much as possible fields (including custom fields). In such a way future improved multiple editor would be unburdened since lot of values would be assigned during process of adding, not to mention the process of scanning files.

Any thought would be appreciated.

I felt this was the moment to suggest it because v1 is appearing on the horizon. If I'm late for it, well, time ain't passing by any slower. You snap, a year elapsed, and here we are discussing v2.

Thanks

[nostra]

A couple of users have already suggested such a thing, but I really do not know why would you want all new movies to be created same values??? For which practical situation is it helpful?

[rick.ca]

I don't know what you have in mind for the v1 MME, nostra. But the more I think about it, the more I like the simplicity and versatility of my edit bar suggestion. The main point of that would be to allow any field to be edited, and to make it more accessible—like the existing search bar is.

I don't know what use-case buah is alluding to, but it might satisfy that need as well—if it had the ability to save searches. The saved searches could be listed in a drop-down box (i.e., [field name] = [value]), and a simple MRU list might suffice.

[nostra]

I have your edit bar in mind , but it has not much to do with default values or am I getting it wrong?

[buah]

First of all, thanks for you didn't forget this suggestion.

If I import/scan 10 movies that all will have the same category, quality, subtitles, language and especially custom field values, it would be easier to define those values before import/scan (just like "seen" status for example) than to define them through multiple editor after importing/scanning
I have custom fields which values are same for large continuous groups of movies, but for each one by one I have to manually edit them and choose those values after importing/scanning, such as:
DVD Case #
In Collection
To Watch
Playlist
Collections (Criterion, 1001 movies... KINO Video...),

etc

[rick.ca]

I have custom fields which values are same for large continuous groups of movies, but for each one by one I have to manually edit them and choose those values after importing/scanning

Okay, now let's assume we have an "edit bar" that can save searches and consider how that might work...

First, there's there's no difference in the efficiency of entering the default values before or after the movies are added. In the more general case, it would be safer and easier to apply values after—when you can see the records it's going to be applied to. I don't know if the new tool will do this, but it would be very helpful (again, in it's general use) if it could display a drop down of the unique values currently existing in the field for the selected records. This makes it much easier for changing values, and makes it more difficult to do so when the intent is to fill fields that should be empty. So if it worked that way, entering default values after the movie is added (and perhaps updated) would clearly win.

Second, being able to apply default values to a set of fields all at once might be helpful if a the same set of fields/default values is commonly used, and such sets can be saved and edited. I wonder if that's not a tall order for something not many users would need. But, more importantly, I don't think it would make all that much difference. The "edit bar" might even be more efficient, all things considered. Say a common use is like your example—you need to set four fields. The values for two of them (DVD Case # and Playlist) likely need to be updated from the last use anyway, so running those separately is no less efficient than changing the values in a saved configuration, then applying the edit. The default values for the other two may never change (I may not understand them, but it seems they would always be "true"), but that means they would be easy to pick off a drop-down list and applied. So I visualize being able to apply four separate edits using such a tool in less time than it would take to fiddle with some kind of default settings configuration, then apply the multi-edit.

Third, an equally likely scenario is that for a batch of movies the default values may not be all the same for a particular field, or some may not apply to all movies. The one-field-at-time approach is more versatile and allows such a task to be completed in whatever way is easiest for the user. That might be applying common values to all then changing those that should be different, or simply modifying the selection from field to field. This could be done with the other approach as well, but, again, would require the more cumbersome changing of the default settings for each iteration.

So while the "edit bar" may seem to be more work when there are multiple defaults to be set, I'm not convinced this is the case. Even if it is in some situations, I don't see how that can outweigh the advantages: It's easier to implement, versatile, and would be one easily understood tool that can used for a number of different purposes (e.g., MME, set default values, edit single field without having to put record in edit-mode).

[buah]

Third, an equally likely scenario is that for a batch of movies the default values may not be all the same for a particular field, or some may not apply to all movies.

My logic how to spare time is as follows:

If you have default values, than you'll have to change/correct those values (possibly) only for some of them after importing/scanning. If you don't have default values, unavoidably you'll have to set them all after importing/scanning.

[patch]

If you have default values, than you'll have to change/correct those values (possibly) only for some of them after importing/scanning.
If you don't have default values, unavoidably you'll have to set them all after importing/scanning.

Agree that it would make sense for some fields where an almost always value applies, eg seen, language, quality, some custom fields. In other cases null is more appropriate. The harder question is does the utility justify the programming effort?

ps imo generalization of a multiple record field editor is a different topic.

[rick.ca]

And, please keep in mind, that this idea came from my experience, not theory, since I haven't seen anyone here had more movies than me, meaning no one had more PVD clicks than me.

We're talking about features that don't exist. So both our ideas are from theory, which we are judging from our experience.

It seems clear to me that if the edit bar existed (including the ability to save edits) and we were considering your suggestion, the response would be, "Why don't you just use the edit bar? You could make the changes in the same time it would take you to configure your default field value settings."

Knowing nostra so far, the only question is if he likes the idea or not, regardless needed effort.

It's not just a question of programming effort. It's probably safe to say what you are proposing would be useful to you. But it probably wouldn't be of much use to most other users. By tailoring a feature that is going to be useful to all so it can be applied to the widest possible number of situations—including yours—makes for software that is easier to understand, use and maintain. I'm sure this has a strong bearing on whether nostra "likes" an idea or not.

[rick.ca]

The purpose of this forum is to discuss the ideas raised, in the interests of determining the best design of its implementation—in the context of the application as a whole and all of its users. The objective is to refine the idea or identify a better one, not change minds. It's not necessary to justify the reason why an idea is suggested or why anyone may want to discuss it.

I think nostra shows good judgment in deciding when and how something gets implemented. Thankfully, a suggester's insistence doesn't seem to sway him much. He can't do everything. There are quite a number of good ideas that have been discussed at length and with considerable enthusiasm but haven't yet been implemented. Some will never be implemented. In many of those discussions, no agreement was reached. That doesn't mean the discussions weren't worth having. Some of the most fruitful ones did not change any minds.

[patch]

It seems clear to me that if the edit bar existed (including the ability to save edits) and we were considering your suggestion, the response would be, "Why don't you just use the edit bar?

Having an efficient means of editing is different from having a field for which a default value other than null is most efficient.
That is why "seen" is implemented that way. The concept can be generalized.
Editing needs to be done every time a record is created (batched or not), unlike the value of a useful default which should rarely need changing (but may occasionally need to be altered after importing on a per record basis).

The harder question is does the utility justify the programming effort?

Knowing nostra so far, the only question is if he likes the idea or not, regardless needed effort.

I believe nostra has a very long todo list and is aware he is a limited resource, so is going to daily pass over good ideas in favor of ones that uses his time more efficiently.

[rick.ca]

That is why seen is implemented that way. The concept can be generalized.

Thanks for clarifying, but I believe I understand the issue. If there were other fields like Seen and Wish for which defaults would be useful, I would readily agree. But it's in the generalization of the concept that it becomes apparent the same approach will not work as well as a more flexible one. Yes, some users will add custom fields which are very similar to Seen in this regard, and would therefore benefit from the ability to set a default. But if we're generalizing—and I would argue we have to if there's any point to this—then what about fields for which the defaults vary (like the majority of buah's examples). These need an efficient way to change the defaults on-the-fly. If they have to be set as a usual configuration setting, it becomes more trouble than it's worth (because of always having to check and adjust the defaults). But regardless of how it works, if the defaults have to be set (or even just checked to verify they're set correctly), then it's more effective and efficient to simply set the values using an edit tool.

Editing needs to be done every time a record is created (batched or not), unlike the value of a useful default which should rarely need changing (but may occasionally need to be altered after importing on a per record basis).

While we're being redundant...I don't disagree—if the default value rarely needs changing. But this is not an appropriate solution to buah's use-scenario where most of the fields do change according to the type of item being added. In fact, I think that was the main point of his suggestion—that when a batch of like items are being added, it would be convenient to be able to set defaults.

[rick.ca]

Consider this an aside, not an alternative solution to the issue...

It occurs to me the setting of default values could also be accomplished by using a script. This would be less efficient than a direct edit of multiple files, but it would be easier to build into a work flow. Such a script could be included in a batch file and subject to field overwrite settings, providing some flexibility over the outcome. Different versions of the script could be used for different default "sets."

What I'm thinking of is a script where the default values are set directly in the script using statements such as...

AddFieldValue(mfMPAA, 'Not rated'); and
AddCustomFieldValueByName('Collections', 'Criterion');

...but despite the fact that has to be dirt simple, I can't figure out how to do it. 

BTW, if a script is being used anyway, the setting of any never-changing default values can be done directly by that script.