Catalog Filter: Differentiate or separate Smart Albums and maybe a renaming?

[KLE-France]

Second of two resulting from this question:

The Smart Albums feature was added to the Catalog Filter as a node.

However, it does not behave like the other nodes do. The various choices on these other nodes (Rating, Date, Properties, etc.) can be combined via the AND/OR and Ctrl, Shift and Alt modifiers, but "Smart Albums" cannot.

JLM kindly explained why that is in the source post above. Indeed, this makes the presence of "Smart Albums" among the other nodes somewhat incoherent. Everywhere therein, the user can mix and match to surface images with certain characteristics. But this is not the case for Smart Albums. This latter always overrides any other choices made in the other nodes.

So, I would like to suggest one of two things:

Either

1) put the Smart Albums node in a visually separate compartment located at the top or bottom of the Catalog Filter,

or, better I think

2) make Smart Albums its one panel. This seems like the most coherent thing to do. The user can, of course, stack panels into a tabbed interface, so, that would keep the similar functions together (if the user wants) while also clarifying that they are nonetheless not the same.

EDIT: I would also add that any future Smart Albums panel should function as a Source Panel (i.e., responds to View > Panels > "Show source panels" button).

Also, while I'm here, should "Albums" or "Smart Albums" be renamed? I do fear that new users will find that similarity in naming confusing, especially as they are really two very different functions.

How about "Collections" and "Smart Albums"? Or "Albums" and "Smart Searches"? Surely greater minds than mine will find better terminology, but you see what I mean: it would be advantageous, I think, to clearly differentiate the two functions.

As always, thank you for your consideration.

[jkm]

Sorry, but I don’t think this is a good idea.

It’s odd you’re complaining that Smart Albums is out of place, but not Albums.

Everything you’re saying about Smart Albums is also true of Albums. Never noticed?

The reason these things are in the Catalog Filter pane is two-fold:

-They are creatures of the Catalog. They are organizing and finding mechanisms, that have no existence outside the catalog and would not exist if the catalog didn’t exist. It’s a way to find images with certain characteristics in a single click, and that’s what the Catalog Filter pane does.

-Because the Catalog Filter pane is already there. Creating a new pane just to house albums and smart albums would be very wasteful of screen space.

The placement of these things in the Catalog Filter is entirely coherent and reasonable. Expect to see more enhancements in future versions that make additional use of the Catalog and appear in this pane.

The relevant suggestion, and the one I thought you would make based on your previous post, is to enhance Smart Albums and Albums so they can be combined with the other filters in the Catalog Filter.

THAT would actually be a good thing to do, and it is under consideration for a future release.

[jkm]

Also, while I'm here, should "Albums" or "Smart Albums" be renamed? I do fear that new users will find that similarity in naming confusing, especially as they are really two very different functions.

How about "Collections" and "Smart Albums"? Or "Albums" and "Smart Searches"? Surely greater minds than mine will find better terminology, but you see what I mean: it would be advantageous, I think, to clearly differentiate the two functions.

A follow-up on your addendum.

Smart Albums is an accepted term in the industry. Many applications use this term, including Apple products and Adobe products (Lightroom). When the feature was added to XnViewMP, the name was chosen because of its familiarity and widespread acceptance. To everyone except you, it seems.

It also dovetails nicely with "Albums" which are simple and obviously not "Smart". Smart Albums are an evolution of Albums. Using the same root conveys to the user that they perform the same basic function (present a bunch of pre-selected images) but that they do it in different ways. I disagree entirely that they are "very different functions". They perform them same function, but they use different mechanisms to do it.

Adobe uses the term "Collections" for Albums. Apple uses Albums. Lots of applications use "Albums". Some, like ACDsee, use Collections like Adobe. There will never be a universal nomenclature. The term that all this springs from, the little books of photos we had since decades ago, were called Photo Albums, not Photo Collections. So I think that gives "Album" the better provenance and makes it the more intuitive term.

There was consideration of renaming "Albums" to "Collections" to make adoption easier for Lightroom users, but this ultimately was not done. The term Albums has a long history with XnView, and preserving that is a good thing.

The naming was not done without thought.

[KLE-France]

To address some of your points:

Sorry, but I don’t think this is a good idea.

That's your right. No problemo.

It’s odd you’re complaining that Smart Albums is out of place, but not Albums.

Everything you’re saying about Smart Albums is also true of Albums. Never noticed?

No.

I don't use Albums (although I do understand how they work) so never notice they don't mix with the others either.

-Because the Catalog Filter pane is already there. Creating a new pane just to house albums and smart albums would be very wasteful of screen space.

Not necessarily. First, panels can be grouped into tabbed interfaces, so how much room a new panel would take up can be managed. Also, I proposed two things, but there are surely many others as well. For example, the Catalog Filter renamed to "Catalog and Albums" with two internal tabs (or a dropdown menu), one "Catalog Filter" one "Albums," each part offering consistent function.
--> Note too here that by "function" I am speaking of the actions used to interact with a system, not the output resulting from that interaction. "Functionality" might be better and I'll use that hereafter. Thus, the functionalities used to interact with the Catalog Filter overall do not work with the Smart Albums (and Albums apparently).

The placement of these things in the Catalog Filter is entirely coherent and reasonable.

I agree that they should be together (or at least able to be put together), I argue only that the differences in functionality merit delineation.

The relevant suggestion, and the one I thought you would make based on your previous post, is to enhance Smart Albums and Albums so they can be combined with the other filters in the Catalog Filter.

THAT would actually be a good thing to do, and it is under consideration for a future release.

Indeed, if that is do-able (but see your other post), it would provide consistency in functionality, and in the end, that's what I think would improve the program. I'm very flexible in how to get there!

It also dovetails nicely with "Albums" which are simple and obviously not "Smart". Smart Albums are an evolution of Albums. Using the same root conveys to the user that they perform **the same basic function (present a bunch of pre-selected images)** but that they do it in different ways. I disagree entirely that they are "very different functions". They perform them same function, **but they use different mechanisms to do it**.

So, you're using "mechanisms" where I'm using "functionality," and you're using "function" where I would say "output" or "result."

The entirety of the Catalog Filter is destined to "present a bunch of pre-selected images," so, that is not unique to Albums or Smart Albums, and these latter do indeed give a same output or result: they "present a bunch of pre-selected images."

But their functionalities (or "mechanisms") are very different. The Albums are drag and drop based whereas the Smart Albums are search based.

I would have no real issues nonetheless with those two being grouped together, but if they are to be presented as nodes in the Catalog Filter, the functionalities (or "mechanisms") available in the Catalog Filter need to apply to them.

In the impossibility of that, I stand behind the idea that they should be "separated out" in some way, shape or form--again, you're free to disagree.

[jkm]

I already explicitly said it is do-able. More than once. So since that is not an impossibility, you can safely abandon the idea of separating them out.
It just hasn't been done, yet. So please be patient.

Again, let me assure you, nothing was done without considerable thought. We placed them where they are in the Catalog Filter for a reason. Multiple reasons. Aside from the what I already mentioned, there's also the fact that them being in the same pane facilitates the ctrl/alt click selections that you're talking about. That was considered, and I told you why it wasn't done in the initial release. Even though that is not implemented, YET, it would be foolish to initially put them elsewhere and then move them to where they need to be later. That would cause disruption and confusion. They're where they need to be. The future was considered.

Even the order was considered. Date and Properties were inserted ABOVE the already extant Albums because the nature of the information in those trees was more like Color/Rating, which they nearer. Smart Albums was inserted ABOVE the already extant Categories because it's better for Categories to be at the bottom, as the Categories tree can become EXTREMELY long for some users when expanded. Albums and Smart Albums are anticipated to be more compact in many cases and so are higher up to avoid excessive scrolling to get to them.

I think your focus on drag-and-drop as some sort of differentiator is also misplaced. The Catalog Filter has been littered with drag-and-drop inconsistencies well before Smart Albums. Ratings/Colors/Categories are drop targets. But Date and Properties are not. Some of the Special Items are, and some aren't. It makes sense for Red to be a drop target, because you can assign Red to a file. But should "ISO 200" be a drop target, changing the metadata of an image you drop on it? No, it should not. So do we make it a drop target anyway, or refuse to make Red a drop target, so it can all be consistent? That way lies madness.

Are all the inconsistencies virtues? No, I don't mean that. But let me tell you something... I've spent many years as a developer, and trying to impose absolute consistency on a user interface is a good way to end up with a terrible interface. Human beings are flexible, and interfaces should balance expediency and intuitiveness against systematic rigor.

And screen space is always an issue, and one Pierre is very concerned about. Let me point you at one egregious example: In the Catalog Filter, the Match Mode and Operator are not even labeled. A new user would look at "Global" and "OR" and wonder "WTF is that for"? It's a question of space, and there is only so much Pierre is willing to cram in, clarity be damned. Sure tooltips are available for those, but lots of the UI does not have tooltips at all. It's just another thing that hasn't been done (yet).

You're free to have whatever opinions of the work you want. If you hate what was done, that's regrettable. But we didn't just throw some crap in the air and let it land wherever. Considerable thought was put into how things work, and where they're located, and what they're called. Many things were taken into account, including future development options, past user experiences, and maintaining the character of the application. So it would require a compelling reason to make certain types of changes. I explain this not to dismiss your ideas, but to assure you that these types of things are thoughtfully considered.

Development is always ongoing. Everything won't always be perfect the first time, and some things get iterated improvements over time, intentionally, to get some functionality to the users sooner. So please just be patient, and I think you will see some of what you're looking for addressed. I don't like to talk much about future activities, so I'll just leave it there.

Thanks for your input...

Cheers...

[user0]

2) make Smart Albums its one panel. This seems like the most coherent thing to do. The user can, of course, stack panels into a tabbed interface, so, that would keep the similar functions together (if the user wants) while also clarifying that they are nonetheless not the same.

Also, while I'm here, should "Albums" or "Smart Albums" be renamed? I do fear that new users will find that similarity in naming confusing, especially as they are really two very different functions.

How about "Collections" and "Smart Albums"? Or "Albums" and "Smart Searches"? Surely greater minds than mine will find better terminology, but you see what I mean: it would be advantageous, I think, to clearly differentiate the two functions.

I would change it to match Lightroom, Bridge and Capture One (instead of current ACDSee-like approach)

• add new Collections pane

• move both Albums and Smart albums into new pane
  once both smart and non-smart nodes are in the same pane, their naming is not that important (Collection vs Album vs Search)

Example

other_apps_collection_pane.png

related
Smart album - add filesystem search

[KLE-France]

I would change it to match Lightroom, Bridge and Capture One (instead of current ACDSee-like approach)

• add new Collections pane

• move both Albums and Smart albums into new pane
  once both smart and non-smart nodes are in the same pane, their naming is not that important (Collection vs Album vs Search)

Could 100% get behind that. But, with "pane," are you speaking of what I'm calling a "node?" That is, each of the categories in the Catalog Filter (Rating, Color Label, People, etc.)?

If so, that too is fine by me if they can be incorporated into the functionality of the Catalog Filter. That's my main point. If the Albums and Smart Albums are in the Catalog Filter, I want to be able to, say, choose "And", then click my [Smart] Album, Ctrl+click (Properties > Orientation) Portrait and Ctrl+click (Categories) Bob and have XnView show me all the portrait-oriented photos of Bob in my [Smart] Album.

It has been pointed out to me above that this is do-able and apparently planned to be done, but also that this is very complex to do. If it comes to be, perfect! and even better indeed with Albums and Smart Albums in a single node/pane(?).

But, XnView MP is basically a one-person show if I'm not mistaken, and I would understand perfectly and accept perfectly if Pierre doesn't want to bother with that.

This is where, in this latter case, I think putting Albums and Smart albums in their own panel (as in View > Panels (and maybe this is what you meant with "pane"?)) -- but really as a third source panel -- would be the "ain't nobody got time for that" workaround.

As a third source panel, this would resemble nearly perfectly (functionality I cannot speak for) the screenshot of how Bridge does it, that you posted above.

Thus, with the source panels activated, the user would see an interface with three tabs:

• Folders

• Catalog Filter

• [Whatever is decided to call the tab with Albums and Smart Albums in it]

Each with its own, internally coherent functionality and/or endpoint (this new third tab would continue to have a functional inconsistency (drag & drop vs search based), but the similar endpoints can justify the grouping).

But yes, while we're grouping like things, it would be a solid step forward to group Albums and Smart Albums.

Cheers!

[user0]

This is where, in this latter case, I think putting Albums and Smart albums in their own panel (as in View > Panels (and maybe this is what you meant with "pane"?)) -- but really as a third source panel -- would be the "ain't nobody got time for that"

yes, this is the only correct way of doing it
step 1 - move them into new separate pane(panel)
step 2 - rework filter to work with selected source