"Wish" and "Own" are different things

[kozzmik]

I apologize if this has been brought up before, but the way this program uses "wish" as a synonym for "not owned" is very confusing to the user and at a minimum the name of the filter should match the name on the movie screen, whether it be wish or own. Personally I think it should remain as the actual field name, which is wish, since all other possibilities would then still be available.

1. Seen (wish to see is covered by "seen" simply being off)
2. Wish (Means wish to own)
3. Owned (does not need it's own check since it can be filtered based on whether there is a media location or not) (Would be nice to have a preset filter for this though)

whereas if "wish" was changed to "owned", "wish to own" would be difficult to implement for the user, unless they used the owned field as a wish field, which would be a bit irritating.

In summary I think it makes sense that the wish field should just be consistently referred to as wish, and that there should be a preset filter that would filter "owned" or "not owned" based on whether there were a media location or not.

Any thoughts

Update: I see the naming is now consistent in the beta version, but it would still be very handy to have a preset filter for whether there was a media location or not, like there is for whether there is a file path or not.

[rick.ca]

Filters are explained here.

In summary I think it makes sense that the wish field should just be consistently referred to as wish, and that there should be a preset filter that would filter "owned" or "not owned" based on whether there were a media location or not.

I agree the captions could be more concise, and that's why it has been changed in the beta. Otherwise, I think the filters are already the way you're suggesting they should be. Bear in mind the filters are what they are. Each one is simple an precise in it's behaviour. Users can have different kinds of collections (i.e., one might have no "wish" items, another might include only video that exist). There's no need to restrict their meaning and use to one narrow interpretation. If the captions don't "fit" how one wants to use the filters, they can be changed using a custom language file.

[kozzmik]

I did see that the inconsistency between wish and own has been fixed in the beta version, and in the correct way in my opinion, but if we use wish for it's named purpose - to indicate movies we "wish" to own - then there is still no quick filter for movies we own, since simply not having a wish to own, is not the same thing as not owning. We may have seen a movie, not own it, and also not wish to own it. There still needs to be a quick filter for media label or media location in my opinion to quickly filter for movies we own or don't own.

[kozzmik]

Of course the beta version with it's saved filters makes this a very minor issue of consistency rather than function.

[rick.ca]

There still needs to be a quick filter for media label or media location in my opinion to quickly filter for movies we own or don't own.

How would that be any different than the existing filter based on the existence of a File Path?

[kozzmik]

I assume a file path applies to movies that are available for play on an accessible drive. How would this apply to a normal collection that is mostly on DVDs? DVDs have no file path but they do would likely have media type, media label and/or media location.

[rick.ca]

There's not going to be another filter just to accommodate one media type. So if there's only to be one filter, which field most effectively indicates the existence of media for a record. Clearly, File path works very well for the majority of users whose media is online. Those with DVD collections can also use it simply by adding a value to the field. If that's too much trouble, it follows having a filter for that attribute is not very important. It's still possible to "filter" using a simple search of any of the other fields.

Maybe Media Type or Label would have been a better choice. They are, after all, also set when any type of media is scanned. But media isn't always scanned, or may be to much trouble to scan—just to fill those fields. In any case, the existing filter has used File path since the beginning. Existing users are not going to tolerate it being changed just because a case can be made for using a different field.

[kozzmik]

Well as I said it's a rather minor point of consistency and not really that important now that the beta has saved filters but I still would like to respond to what you said.

There's not going to be another filter just to accommodate one media type.

It's not for just a single media type. It's for all media that is not online

Clearly, File path works very well for the majority of users whose media is online.

Well clearly it would work well for users whose media is online. Why wouldn't it? But of course we are talking about users whose media is not online, and I would guess this would be a majority, if not of current users, certainly of potential users.

Those with DVD collections can also use it simply by adding a value to the field.

Like I said the better "Kludge" is to simply add a saved filter for a non NULL Media label. It's cleaner. But then why have a kludge at all. The best solution would be to simply add an "owned" boolean along with seen and wish? This would cover all situations.  

But media isn't always scanned, or may be to much trouble to scan

These fields can be filled in manually, and Media type through a multi edit, so this is not really an issue. but again the correct way is to add an owned boolean.

It's not a major issue, and there are work arounds, but if your argument is that the current system is the best of all worlds, or even adequate, for anyone who cares about software consistency and usability, that simply won't fly unchallenged.


[Ed.] There's a quote tool—please use it.

[rick.ca]

It's not a major issue, and there are work arounds, but if your argument is that the current system is the best of all worlds, or even adequate, for anyone who cares about software consistency and usability, that simply won't fly unchallenged.

I never suggested the status quo was perfect. I said a new filter will not be added, and there are ways to adapt to what we have. You started this topic making a recommendation based on a fundamental misunderstanding of what already exists. I clarified that for you. Had you asked whether Media label might be used instead of File path for that filter—and pointed out the reasons for doing so (it's automatically set when files are scanned and it can be changed with the MME)—I would have agreed that is worthy of consideration. It would still need further consideration, as such a change would potentially inconvenience most existing users.

The point has been made, and further positive discussion seems unlikely, so I'm closing this.