PM+ Filter tool and Sublocation

[ejhutch]

Hi,
I was exploring the PM+ Filter tool and was confused by how Location Taken and Location Shown seem to be presented in the menu.  Screenshots are attached.

When the "Location Taken" "Sublocation" is shown, it appears in the Filter Menu as "Sublocation".

When the "Location Shown" "Sublocation" is shown, it also appears in the Filter Menu as "Sublocation".

This is confusing if I want to display both as separate filters at the same time.

I searched the docs, manuals, and forums, but couldn't find any information on the difference in the filter menu, but I assume that they're the difference between the "*taken" variables (sublocationtaken, citytaken, statetaken, etc.) and the "*shown" variables (sublocationshown, cityshown, stateshown, etc.)

If that's the case, then the UI menu entries are ambiguous and confusing.

Or I'm missing something somewhere.

I know I can change how some things are named in the accessibility settings, but if the two types of locations ("taken/shown") in the filter menu really are different, then the default display in the filter menu should reflect that.  And anywhere else they appear ambiguously like that, also.

THanks,
Ed

[Kirk Baker]

Ed,

I was exploring the PM+ Filter tool and was confused by how Location Taken and Location Shown seem to be presented in the menu.  Screenshots are attached.

When the "Location Taken" "Sublocation" is shown, it appears in the Filter Menu as "Sublocation".

When the "Location Shown" "Sublocation" is shown, it also appears in the Filter Menu as "Sublocation".

This is confusing if I want to display both as separate filters at the same time.

I searched the docs, manuals, and forums, but couldn't find any information on the difference in the filter menu, but I assume that they're the difference between the "*taken" variables (sublocationtaken, citytaken, statetaken, etc.) and the "*shown" variables (sublocationshown, cityshown, stateshown, etc.)

If that's the case, then the UI menu entries are ambiguous and confusing.

Agreed.  I'll see what I can do to fix that.

-Kirk

[Kirk Baker]

Ed,

So I can disambiguate it (the parent menu text is available), but in the case you're showing, the parent text is very long (Location in which the image was created) and using it with a slash between it would be much longer than the available space:

Location in which the image was created / Sublocation

What do you suggest that I do?  What would be reasonable?

I could truncate the leading text:

...created / Sublocation

But I'm open to other suggestions.

-Kirk

[Kirk Baker]

How about this?

[Kirk Baker]

I think I'm going to go with this instead.  The rightmost data is more important than seeing the start and end with truncation in the middle.

[ejhutch]

Did my post suggesting SublocationTaken and SublocationShown not make it out?

It may not have posted.

[Kirk Baker]

Ed,

Did my post suggesting SublocationTaken and SublocationShown not make it out?

It may not have posted.

It did post.  I split the topic because the variable names have nothing to do with the display of the popup menu.  Keeping topics well-defined and not mixed with other concerns makes my life easier.

Here is the link to the other topic: http://forums.camerabits.com/index.php?topic=14672.0

-Kirk

[ejhutch]

I get why you split them. It makes sense, and I must have been unclear in what I was trying to say.

I was trying to end up suggesting SublocationTaken (SublocationCreated if you use the IPTC naming convention) and SublocationShown for the Filter dropdowns instead of truncating.

I like that you named the variables intuitively for the user, and was trying to resolve in my mind, while I was posting, my rationale for naming the filter dropdowns similarly.

I've browsed the IPTC standards docs here:
https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#location-structure
and here
https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#location-created
and am trying to use their terminology for clarity and consistency.

I don't like the IPTC naming convention of calling both sets of subfields of the two different Location property data structures the same thing, ie.

Location Created
   Sublocation
   City
   State
   etc.

Location Shown
   Sublocation
   City
   State
   etc.

which leaves you with ambiguity and the conundrum of how to present the subfields in a case like this. Do you do what you did with the variable names for the filter dropdowns, and other metadata fields? Or do you replicate the IPTC naming convention and leave the filter dropdowns and other metadata fields as the IPTC named them, but potentially presented to the user in an ambiguous way, which is what happened with the filter dropdowns.

The other sub fields of the two (three if you count the legacy Location property) Location Created and Location Shown property data structures are ambiguously named as well in my opinion.  I'd prefer if they were all presented to the users in an unambiguous way such as the way you did it with the variable names, and even your table names in the catalog database.

I think it comes down to differentiating the names that the user sees of all of the location structure subfields in a more unambiguous way.

I'd suggest all UI presentations follow a format something like this:

Location Created
   SublocationCreated
   CityCreated
   StateCreated
   etc.

Location Shown
   SublocationShown
   CityShown
   StateShown
   etc.


I'd also not be surprised though if there were other implications to doing this that I haven't thought of.

Ed,

Did my post suggesting SublocationTaken and SublocationShown not make it out?

It may not have posted.

It did post.  I split the topic because the variable names have nothing to do with the display of the popup menu.  Keeping topics well-defined and not mixed with other concerns makes my life easier.

Here is the link to the other topic: http://forums.camerabits.com/index.php?topic=14672.0

-Kirk

I checked, and I actually did not post it.  But it was even more unclear than the post I did send.