Wordy title sorry, but wasnāt sure how else to put it.
Iāve got all my images meticulously tagged with hierarchical tags, using them for pretty much everything (and avoiding other forms of āpeopleā tagging) which means photostructure is great.
But there is a visual issue that is causing me headaches as I work through some small imports for testing:
when i browse a keyword, e.g.:
Keywords > Animals > Sealife
I see the sub-tags under their own headings, but at the end every single image is just blobbed on, attached to the bottom most category. This is identified as a ul of gallery leaf (the āproperā navigation above are a div of class tag-gallery)
I understand WHY they are there, my issue is with the lack of visual separation between the ālastā child keyword and the list of all images matching the current one. Visually it becomes very difficult to discern where one ends and the next begins, especially for keywords with a large number of images (common higher up the tree!)
I have two solutions in mind, but curious to know if Iāve just missed something somewhereā¦
The simplest solution to me is to have a heading as per the existing style with something indicating that it is showing all images containing the current tag, and that this overlaps with the images above. This is somewhat visually redundant, with the purple bar at the top showing the same thing.
My strong preference, though presumably more difficult, would be to do the same as 1. to ensure visual demarcation, but ONLY show images that are not already in a child keyword list above. This feels like a more natural alignment to the logic behind hierarchical structures and would resolve the visual redundancy above, as you could put the images without any further child tags at the top.
Iāve attached an example where hopefully you can see how the current state makes finding images without child tags nearly impossible and is ambiguous about where one thing ends and the next starts. Having the āurinal artā image at the top on its own would highlight that it is a form of art that I am not able to categorise further, wheras grafitti is fairly clear cut and they are grouped together in a child tag
hmmā¦ Iād be surprised if this was the intended behavior. I think if youāre under āsunsetā you should only see pics tagged with sunsets. Not everything else blobbed at the end, with or without separation.
Having said that, I also use hierarchical tags to organize my pics, especially people, where I use
ok, so the second option above āsolvesā the issue of the excess number of items at the bottom, (which is fine, as itās cleaner and changing my tagging approach is ā¦fine) but not the issue itself - as per example above, anything with the art keyword (and no child tag) gets weirdly lumped underneath the last child tag rather than making it clear that THESE are the photos that are tagged with this keyword, and no children.
Screenshot shows graffiti followed by a urinal on a wall as art, that Iāve left as āartā as iād rather not try to classify it, but the visual delineation is ā¦bad:
Same issue for me when browsing by folders. I would expect photos NOT in a subtag/subfolder to be at the very top of the list with no heading breadcrumbs, not at the very end. Note Iām on the latest stable which is pretty old at this point, so this behavior may have already changed in the latest beta/alpha.
Hereās my PhotoStructure on the left, actual folder structure on the right.
sorry for the late reply. Youāre correct I only tag the last item in the hierarchy.
So on the remaining issueā¦ I agree this is not good. If youāre in graffiti, you should only see graffiti pics.
That seems like a bug (and not a feature) to me. Thatās for @mrm to resolve.
Howdy @davidr , welcome to PhotoStructure! Thanks for the additional context, @nuk and @avdp.
I completely agree that the current rendering needs a demarcation between child tag āsamplesā and the actual directly-associated assets, so I changed this from āsupportā to ābugā.
Background
In case you missed it, I wrote up how PhotoStructure extracts keywords:
And how PhotoStructure handles hierarchical tags:
Specifically relevant:
PhotoStructureās tag hierarchies apply implicit inheritance.
In other words, all path elements within a hierarchical tag must apply to the asset.
If an asset is tagged with Camera/Canon/EOS 5D, PhotoStructure also associates it to Camera/Canon and Camera, via inheritance.
An asset tagged with Where/France/Paris/Louvre must have been taken in Paris, and also taken within France.
Also note:
The assets for child tags are āsampledā, meaning a random selection of relevant assets, and that sample set actually changes size based on thumbnail size.
The assets directly associated to the current tag are not sampled, so you can actually see all the assets.
Issue 1: lack of demarcation between child tag samples and directly-associated assets
If there are child tags and directly-associated assets, I add another ābannerā that duplicates the top gradient banner contents to separate the child tag samples and the directly-associated assets
(if any of yāall think of a better approach, Iām all ears!)
Issue 2: handling implicit vs explicit hierarchical tagging
@davidr, if you want to tag everything explicitly, I think that should be handled gracefully by PhotoStructureāshould PhotoStructure ācollapseā or āaggregateā all āduplicateā tags, so assets tagged with a/b/c, a/b, and a would simply be tagged with a/b/c?
AlsoāI feel like this should be the default behavior, but happy to discuss.
Issue 1: your proposal would solve my issue, though Iām not sure if iād prefer the directly associated assets at the top or bottom. Top seems more logical.
Issue 2: Iām torn a bit - the reason for originally including all parent tags was that if I wanted pictures of ācarsā i could filter on that. I think the option as described makes lots of sense but Iād want to have the option of not aggregating also. Well, actually I want both!
I think my ideal would be
Directly Associated, with no child tags (Your proposed ācollapsed/aggregatedā view)
Child Tag 1
Child Tag 2
ā¦
Child Tag N
All photos with this tag, regardless of child tags (the current behaviour, though better visually separated)
OK, on issue 1, I actually misunderstood @davidr, I thought he was seeing /Keywords/Art pics while browsing /Keywords/Art/Graffiti which would have been a bug. Looking at the screenshots again, I see thatās not the case. So yeah, itās one of those cosmetic issue that essentially renders the view a bit uselessā¦
Update: I poked at the code to add the banner, and, embarrassingly, Iād fixed this last Octoberāitās been in the v2 alpha builds.
Iād tried it at the top and the bottom. Hereās my thinking:
I have a bunch of child tags to show (and if there are more than what shows on the screen, they are fetched via lazy-loading)
I have a bunch of assets to show (again, lazy-loaded).
Worst case, I suspect much higher cardinality of assets than tags, so scrolling through the handful-or-two of child tags to get to the next section should be easier than scrolling through the possibly-tens-of-thousands of assets.
The other solution could be to āpartitionā the window into āpanesā of child tags, and child assets, but I think that results in an ungainly UX.
The issue of getting to the child assets if a tag also has a ton of child tags will be reduced if you switch to smaller thumbnails, or, in the next build, tap the new āexpandā or ācompressā buttons in the child tag headers. Reduce them to 1 row, and then scroll to the child asset section.
Concerning issue 1, weāre all in agreement another banner is needed for visual separation. Thatās a quick bugfix you already implemented!
I think more time is needed to sort out the rest of the questions/comments, as I think they point to a larger user experience problem. Hereās my first stab at resolving it.
First, a summary of the UX concerns I see above:
@mrm notes that currently assets without children are not sampled (all assets are displayed) but assets with children are sampled (only some assets are displayed). Important because in regular browsing, you always want some way to display all photos.
Display childless assets at the top or bottom? If there are relatively few assets, @davidr and I agree that top is more logical. But if there are very many, it makes more sense to display childless assets at the bottom. In @davidrās example, if he wanted to look at Honda but had 1000 generic cars, he would have to scroll down 90% of the page before he was able to click on Honda to see those children.
Collapse/aggregate explicit hierarchical tags?@davidr added explicit parent tags in order to see all assets in a group regardless of children, which is only possible in the current PhotoStructure version by adding explicit tags then scrolling to the bottom of the list.
Show/ignore sub-tags?@davidr says sometimes he wants to look at all assets in a group regardless of children, other times he wants to look at all assets in a group separated by children. I definitely want this, too. For example today I might want everything lumped together from my trip to Japan and without differentiating between the 20 cities I visited. But tomorrow I want to see only stuff from my time in Tokyo.
Thinking about all those items as a whole, I think we could satisfy everyoneās wants/needs here with three changes:
No difference between implicit and explicit hierarchical tagging. PhotoStructure treats an asset tagged with a, a/b, and a/b/c as simply tagged with a/b/c.
New āChildrenā button on the UI next to the existing Small/Medium/Large buttons. Show the current PhotoStructure view when on by default. Disable to mix all photos together at the current hierarchy level regardless of children ā ignore both which child the asset has, and whether the asset has any children at all. When disabled, the separate banners for each child tag are removed and all available child tag are listed in a single banner at the top.
New āShuffleā button to show the current PhotoStructure view when on by default. Disable to stop all sampling/aggregation/shuffling of assets, so all assets are shown and in order. Note assets at the current tag without children are still never sampled, so you can still actually see all the assets at that level, matching the current behavior.
With those new UI buttons, @davidr would no longer need explicit hierarchical tags (but also doesnāt have to delete them if heās already added them everywhere). To view pictures of ācarsā, he sets Children=OFF and leaves Shuffle=ON. He also wants the option of not aggregating, so for that he sets Shuffle=OFF (and either leaves Children OFF or turns it back ON depending on his desires for that day).
When dedicating time to organizing my photos, I would turn Children=ON and Shuffle=OFF. When focusing more on enjoying my photos, I would turn Shuffle=ON and toggle Children depending on mood/area of interest/etc.
Hereās a mockup with Shuffle=ON and Children=OFF, and the proposed tag bar that appears with children=OFF:
Issue 1:
Glad to hear itās in the next version - I heeded the warnings and didnāt experiment with the beta/alpha this morning. Iād be ok with the āall/no children tagsā at the top if it was in the same form where you can ādive inā, but that would break the existing paradigms, so bottom probably makes sense. Maybe a toggle to collapse/uncollapse child tags for people that have too many?
Issue 2:
Perhaps a simpler version of this issue would be a UI toggle in the āallā header at the bottom where toggling would switch between:
āa car tag with no childrenā (Default)
āeverything with a car tagā
e.g.:
Cars/Honda
Cars/Toyota
[Cars with no children|All Cars]
Iām not keen on the using āChildrenā or āShuffleā in any labels though, as children is bad for ānormal peopleā to parse (imagine this under the āwhoā tag!) and shuffle has connotations that this doesnāt deliver to. I am bad at coming up with good (non-verbose) names though.
@nuk: as an engineer, I like the shuffle and child tags visibility toggles!
I suspect @davidr is correct though, about those adding cognitive complexity. Iāve never seen that sort of thing in an image gallery before. Yes, I know PhotoStructureās tag gallery is already unique, but I (hope) that people āgrokā whatās going on (ish), at least enough to click around to get to the photos they want to view.
Another approach could be to add the āchild toggleā functionality as a different thumbnail size, something like:
or
If you just want to view child assets, know that you can click the search icon in the header which will pre-populate the search field with that tag. You can then sort by captured-at time in ascending, descending, or last-imported time.
Iāve implemented a new omitAncestorTags setting that defaults to true. Hereās the description:
PhotoStructureās hierarchical tags assume implicit inheritance: that is, if you tag an asset with ānature/skyā, ānatureā is implicitly assumed.
If this setting is true, PhotoStructure will omit tags that are already inferred from deeper descendant tagsāthat is, if an asset is tagged with ānature/skyā and ānatureā, and this setting is true, the ānatureā tag will be omitted.
I didnāt think too hard about the particular buttons and labels ā itās the functions themselves that I think are important. The functions to toggle sampling and to toggle grouping.
The omitAncestorTags setting makes sense to me.
@mrm, Good point that searching already lets you toggle off grouping. In @davidrās example, clicking the search icon prepopulates search with kw:cars to show all assets ignoring children. Modifying to kw:=cars shows only assets with no children. Modifying to kw:cars/* shows only assets with children. Perfectly functional already, with reasonable documentation to figure it out and plans for a better search interface in the future.
But your child toggle looks good to me, too. A āchildā icon could certainly be confusing, where your ātagā icon is less ambiguous. And if someone clicks it, I think the difference is immediately obvious and intuitive.
I still think itād be nice to be able to toggle sampling/shuffling in regular browsing and in searching. For when Iām enjoying vs specifically organizing. Bulk asset modifications would be easier to do with sampling disabled. But I guess thatās a different feature request than what this thread is about.
Iām totally sold on the value of showing child tags as a list of ābubblesā like you prototyped. This would be quite handy for very large child tag cardinalities.
Iām not sold on toggling sampling, though. What assets would I show for a given child tag? The N most recent, or N oldest? Or are you thinking that the sampling toggle would only impact the assets directly associated to the current tag?
(I had that edit in draft mode with the UI sample, but then I saw your replyā¦ and that I hadnāt clicked āsaveāā¦)
Toggling sampling off would show all assets for all children, so you can actually see all the assets regardless of children. Or maybe just show the first X assets for each child then include a + button to expand and show assets for only that particular child.
Considering a personal example, I have a āfamilyā folder (tag) with a mix of subfolders (children) arranged variously by event, date, and other less-than-ideal stuff. I recently wanted to find all pictures of my mom. To actually see all of the assets under āfamilyā, I clicked through every single child separately, since thatās the only time PhotoStructure doesnāt sample.
It never occurred to me to search as you taught me today. I think thatās because Iāve only gotten about 50 photos tagged so far, and searching feels completely useless until all my photos actually have keyword tags on them.
Consider another case as well, although this one is weaker imo. Should the proposed ātagā/āchildā button show assets as sampled or not? Iād prefer sampled when walking down memory lane, but if I suddenly notice some photos where Iād like to update some tags, Iād want to immediately disable sampling so I can see all related assets and start organizing.
Those are interesting use cases for the find-your-mom case. Iāll think about that.
Youāre correct about the hashtag icon. This may be a case where I want to use an icon that hints at something recognizable, but is still something new. Maybe this?
Itās a mashup of the gmail label icon and a very simplified view of ālabel bubblesā (the dots in the middle). The iconography might be a bit too obscure though.
This icon is toggling off the child tag sample galleries/toggling on āonly see child tag namesā, so the tree seems like it might not be quite the correct iconāitās certainly descriptive of whatās being changed, but it doesnāt lean into whatās changing. Hereās the mockup:
I could see people arguing that it should toggle child tag visibility, rather than just how the child tags are being rendered.
Concerning the sampling, on/off could be done with a dice icon instead of the shuffle icon. (Assuming you do decide to try adding it, and put it on the main header rather than a submenu somewhere). (@davidr didnāt like shuffle due to other connotations it suggested to him).
Concerning the child display, do you think your mockups indicate whatās changing? To me, your tag/label icon variations scream āclick me to edit tagsā.
But Iām just one person, and whatās in my head doesnāt always match reality for the general public. Maybe you could use the label and reduce my association with editing by showing two icons.
As you have three buttons to toggle between small/medium/large pictures, you could have two buttons to toggle between a single tag and multiple tags. Sorry Iām not at a computer where I could make a mockup, but these are the two icons Iām thinking:
I realized that the child-tag-rendering toggle canāt be part of the thumbnail size button groupāthumbnails are shown both for child tag samples and for directly-related assets.
Iām going to put the āshow child tags as bubblesā feature on hold for a bit, at least until v2.1 is released. Iāll think more about a shuffle toggle, too.
icon instead of the shuffle 
icon. (Assuming you do decide to try adding it, and put it on the main header rather than a submenu somewhere). (