Another newbie question on catalogue

[krubin]

Luiz,

What is the difference between Browsing and Filtering in PM6? They seem identical.

Browse is a tree that shows you everything that the Catalog knows about, metadata-wise.  Filter is a stack of criteria that helps you narrow down what you're interested in seeing.

Is it possible to browse/filter by two categories at the same time, for example location and model or a certain keyword and capture time?

Filter, yes.  Browse, no.

In the Filter tab, you'll see (by default, a single filter 'stage' or criteria) usually a 5-star filter.  It should have a button on the right of its header with a '+' (plus symbol) on it.  Clicking it will add a new filter stage which act as an "AND" criteria for the overall filter.  On its header is a popup menu button.  Clicking on it will reveal a list of all of the available criteria to use to narrow your search.  Selecting one will change that criteria to the chosen criteria.

Selecting one or more items in a filter stage will be an "OR" of each of those terms (which would expand or widen the criteria of that filter stage).

Does that help?

-Kirk

I think this feature is counterintuitive.  If you look at classic websites and software packages, when you have multiple selection criteria from different categories, the expected behavior is a logical AND.  When you multi-select items within a category, the expected behavior is a logical OR.

By example, if I'm "browsing" dates and I select two different months, I would expect to see images from the union of those months.  For discussion sake, let's say I choose Jan and February.  If I were to select something from another metadata category, I would expect that to be the intersection.  For instance, choosing a particular location.  Since each metadata category/field is a different dimension about the image, that is a more natural behavior IMHO.

This is the way ecommerce sites (Amazon, B&H, Adorama, etc.) work as well, as do other catalog products. 

Thanks for the outstanding work on this.  Very excited about where PM+ is going.

[Kirk Baker]

What is the difference between Browsing and Filtering in PM6? They seem identical.

Browse is a tree that shows you everything that the Catalog knows about, metadata-wise.  Filter is a stack of criteria that helps you narrow down what you're interested in seeing.

Is it possible to browse/filter by two categories at the same time, for example location and model or a certain keyword and capture time?

Filter, yes.  Browse, no.

In the Filter tab, you'll see (by default, a single filter 'stage' or criteria) usually a 5-star filter.  It should have a button on the right of its header with a '+' (plus symbol) on it.  Clicking it will add a new filter stage which act as an "AND" criteria for the overall filter.  On its header is a popup menu button.  Clicking on it will reveal a list of all of the available criteria to use to narrow your search.  Selecting one will change that criteria to the chosen criteria.

Selecting one or more items in a filter stage will be an "OR" of each of those terms (which would expand or widen the criteria of that filter stage).

I think this feature is counterintuitive.  If you look at classic websites and software packages, when you have multiple selection criteria from different categories, the expected behavior is a logical AND.  When you multi-select items within a category, the expected behavior is a logical OR.

By example, if I'm "browsing" dates and I select two different months, I would expect to see images from the union of those months.  For discussion sake, let's say I choose Jan and February.  If I were to select something from another metadata category, I would expect that to be the intersection.  For instance, choosing a particular location.  Since each metadata category/field is a different dimension about the image, that is a more natural behavior IMHO.

This is the way ecommerce sites (Amazon, B&H, Adorama, etc.) work as well, as do other catalog products. 

Thanks for the outstanding work on this.  Very excited about where PM+ is going.

The way you have described it is how Filtering works.  I think you may have misunderstood me.

-Kirk

[krubin]

The way you have described it is how Filtering works.  I think you may have misunderstood me.

-Kirk

I don't think we are quite on the same page yet.  From an expected behavior and functional view of filtering, it sounds like we are on the same page, which is wonderful.  From a user experience, my recommendation is that they approach you have taken with the "Browse" tab is much more intuitive and effective than the "+" option on the filter tab.  The ability to look at Browse and multi-click options from different categories to provide an intersection/join of the topics is fast and easy, and would not require replication of each of the fields in the filter.  You might even be able to collapse the two tabs into one. 

For example, at present you allow me to chose color-tagged and starred fields, and then add IPTC specific criteria and populate values.  For example, to choose a State I would "+" and enter the state code.  With the browse/select method, I can just click on the state of interest (or multiple states), the camera body I like, or lens I used, etc. etc.  They are all there in a breakout, also giving me current counts of images in each bucket.  Providing that as text entry in "Filter" is less user-friendly IMHO.

Thanks for considering.

[Kirk Baker]

The way you have described it is how Filtering works.  I think you may have misunderstood me.

-Kirk

I don't think we are quite on the same page yet.  From an expected behavior and functional view of filtering, it sounds like we are on the same page, which is wonderful.  From a user experience, my recommendation is that they approach you have taken with the "Browse" tab is much more intuitive and effective than the "+" option on the filter tab.  The ability to look at Browse and multi-click options from different categories to provide an intersection/join of the topics is fast and easy, and would not require replication of each of the fields in the filter.  You might even be able to collapse the two tabs into one. 

For example, at present you allow me to chose color-tagged and starred fields, and then add IPTC specific criteria and populate values.  For example, to choose a State I would "+" and enter the state code.

I'm not sure I understand this point.  There is no entering a state code.  You select it in the filter by clicking on its row in the Filter.  Where in the UI do you enter a state code?

-Kirk

[Kirk Baker]

I don't think we are quite on the same page yet.  From an expected behavior and functional view of filtering, it sounds like we are on the same page, which is wonderful.  From a user experience, my recommendation is that they approach you have taken with the "Browse" tab is much more intuitive and effective than the "+" option on the filter tab.  The ability to look at Browse and multi-click options from different categories to provide an intersection/join of the topics is fast and easy, and would not require replication of each of the fields in the filter.  You might even be able to collapse the two tabs into one. 

For example, at present you allow me to chose color-tagged and starred fields, and then add IPTC specific criteria and populate values.  For example, to choose a State I would "+" and enter the state code.  With the browse/select method, I can just click on the state of interest (or multiple states), the camera body I like, or lens I used, etc. etc.  They are all there in a breakout, also giving me current counts of images in each bucket.  Providing that as text entry in "Filter" is less user-friendly IMHO.

The Browse tree does not lend itself well to filtering.  It doesn't maintain the selection of rows in branches that have been collapsed so you'd have to scroll a lot (say to get past a massive Keywords branch) in order to get to your next criteria.  This is a limitation of the tree control itself.

If the Browse tree were to be made into a filter, how would the user define what selections are AND and what selections are OR?  The only thing that would make sense to me is that each major branch's selections would be an OR with their items, and an AND with every other major branch.

We could overcome the loss of selection state of collapsed branches by storing our own information about what was selected prior to the collapse and restore it on expansion.

-Kirk

[krubin]

I don't think we are quite on the same page yet.  From an expected behavior and functional view of filtering, it sounds like we are on the same page, which is wonderful.  From a user experience, my recommendation is that they approach you have taken with the "Browse" tab is much more intuitive and effective than the "+" option on the filter tab.  The ability to look at Browse and multi-click options from different categories to provide an intersection/join of the topics is fast and easy, and would not require replication of each of the fields in the filter.  You might even be able to collapse the two tabs into one. 

For example, at present you allow me to chose color-tagged and starred fields, and then add IPTC specific criteria and populate values.  For example, to choose a State I would "+" and enter the state code.  With the browse/select method, I can just click on the state of interest (or multiple states), the camera body I like, or lens I used, etc. etc.  They are all there in a breakout, also giving me current counts of images in each bucket.  Providing that as text entry in "Filter" is less user-friendly IMHO.

The Browse tree does not lend itself well to filtering.  It doesn't maintain the selection of rows in branches that have been collapsed so you'd have to scroll a lot (say to get past a massive Keywords branch) in order to get to your next criteria.  This is a limitation of the tree control itself.

If the Browse tree were to be made into a filter, how would the user define what selections are AND and what selections are OR?  The only thing that would make sense to me is that each major branch's selections would be an OR with their items, and an AND with every other major branch.

We could overcome the loss of selection state of collapsed branches by storing our own information about what was selected prior to the collapse and restore it on expansion.

-Kirk

Thanks for bearing with me.  We are getting somewhere now and very close.  I think there are three behaviors that would address the concerns you cite:

1)  To go from a browse/navigate to a "selection" would require clicking on a terminal node.  For instance, in your browse tree, whenever I select the (number of images) icon on the right, those images would, in effect, be "filtered".  For example, if I start with the full catalog of images, and select "January 2018" only January 2018 images are being seen.

2)  Within a category, adding other images would be an "OR".  So, if I click on "January 2018" and then Control/Cmd Click on "February 2018", I would get the union of images across both January and February.  This behavior would only be within a branch of the browse. 

3) . When I click an item from another Category/Branch, it would be "AND" behavior.  So, continuing the example above, if I were to browse down the Ratings tree (after having selected and currently displaying all Jan 2018 + Feb 2018 images), and subsequently Control-Click on "5-Star" the result would be 5-star images taken in either January 2018 or Feb 2018.   Similar to above, if I were to Control-Click on "4-Star", the result would ADD all of the 4-star images from January 2018 and Feb 2018.   

To deviate from the above, if I am exploring the rating branch and choose to click "4-Star" without the Control/CMD key, in effect it would be a new browse, and show me all 4-star images in the catalog (effectively clearing prior Date selections)

- Ken

[Kirk Baker]

Would you find it odd if the counts of later branches did not change to reflect the partial filtering that was going on?  For instance in your example you chose two months and then went on to Ratings.  When nothing is selected the Ratings counts reflect the entire catalog(s) being searched.  When something is selected like your two months, the number of 5 star and 4 star items would very likely need to decrease in order to reflect how many are left in order to be "correct" for the filter so far.

-Kirk

[krubin]

Would you find it odd if the counts of later branches did not change to reflect the partial filtering that was going on?  For instance in your example you chose two months and then went on to Ratings.  When nothing is selected the Ratings counts reflect the entire catalog(s) being searched.  When something is selected like your two months, the number of 5 star and 4 star items would very likely need to decrease in order to reflect how many are left in order to be "correct" for the filter so far.

-Kirk

If I recall correctly, you maintain counts on the bottom of the screen reflecting the total images in the selected set.  I would think it perfectly fine if the count of images in the tree view reflected the entirety of the catalog, and the count on the bottom of the screen reflected the number of the images in the selected set.  That way you wouldn't even need to alter your current logic for counting, and to me that is logical as the browse/select is on the union of catalogs within the search. 

It might be prudent to have a hover-over feature to indicate what is sourcing the count number, but that is a nice-to-have and not an essential need in my view.