Tag-based filtering of cards

[honstar]

For commerce card collections, we are currently building a filter block that allows a user to filter cards by categories. We'd like to leverage tags stored in a metadata block of card fragments to apply the filtering logic on.

In Milo, we have an authoring tool for adding tags: https://github.com/adobecom/milo/tree/main/libs/blocks/tag-selector

This currently loads CaaS tags by default and provides support for consumer tags based on an Excel sheet. However, the latter is based on authored tag titles that are used as tags eventually. Whereas the CaaS ones originate from AEM with a full fledged data structure including localized titles and stable tag-ids.

I'd like to see what the community thinks of extending the current tag-selector and usage of tags in general in milo using more stable tag-ids than just tag titles.

[yesil]

As long as the consumption of the tags doesn't require to load all the CaaS stack in the page, I support consolidating all tagging features in this tool.

[JasonHowellSlavin]

@meganthecoder will have valuable input on this since she built the tag selector tool.

I can speak to our current usage of tags and the taxonomy.xlsx for our bacom-blog migration.

One of the issues we've faced is an authoring disagreement between tags in the metadata, and tags in the taxonomy, causing a mismatch that effects functionality. When these pages were authored the tag selector had not yet been built, and it would have solved these issues by pulling tags directly from the taxonomy.

We've already seen quite a difference in tag use and tag structure between the brand blog and the dx blog that may make it hard to stabilize tags across consumer usages. A boon of the current tag selector is that it relying on the taxonomy sheet allows projects to set up their own tag structure.

[auniverseaway]

IMO this is overdue and welcome. I think Tag Selector needs to be expanded in scope where its not only a selector, but an input mechanism.

The current data model in Excel leaves a lot to be desired. Usually I'm pro-Excel authoring, but I think having an SPA that uses Excel as a dumb storage conduit makes more sense in the long run.

The current tag / taxonomy structure is limited to something like 3 levels because the Excel authoring is so tedious. If we can leverage Excel Graph APIs (we do this in loc), you can easily read/write with Excel, but have a fully usable authoring system that could have feature parity with AEM.

The other option is to move this into an IO Runtime service and use that for storage, but I don't think the 99.99% uptime exists for something visitor facing.

Somewhat to @JasonHowellSlavin's point, if we start treating tags in metadata as keys (they're not really right now), I think this expands what we can do for lookups, renaming, localization, etc.

[honstar]

The current tag / taxonomy structure is limited to something like 3 levels because the Excel authoring is so tedious. If we can leverage Excel Graph APIs (we do this in loc), you can easily read/write with Excel, but have a fully usable authoring system that could have feature parity with AEM.

I think this is an excellent idea 👍 Would be great if you (or @sukamat @jenssingler) could point to an example where this is used to get some inspiration.

The other option is to move this into an IO Runtime service and use that for storage, but I don't think the 99.99% uptime exists for something visitor facing.

Theoretically, I could imagine leveraging an App Builder app with a rich UI based on react spectrum on top of a backend I/O runtime service: https://developer.adobe.com/app-builder/docs/guides/

This would mean offloading the tag management piece to an external app hosted on experience.adobe.com while the consumption part would stay within milo. Downside is the onboarding overhead for consumers.

[meganthecoder]

The current tag / taxonomy structure is limited to something like 3 levels because the Excel authoring is so tedious.

That's true for the old version of taxonomy.xlsx used by the Blog to Milo blocks, which require the columns "Level 1", "Level 2" and "Level 3". @auniverseaway If you recall when we discussed the tag selector architecture, the idea was to consolidate those into a single cell, hence the new column "Name" where levels are broken up by pipes ("Creativity | Animation | 3D & AR"). This new "Name" version is used with the tag selector and can have as many levels as we want.

That being said, I think there's a lot of potential for improvement. I'd love to see this built out to be more robust because clearly there's a use case for it. Maybe this is a good candidate for a story mapping / brainstorming session since we'd like to solve for several cases (Blog to Milo block taxonomy, tag selector tool, commerce card collection, helpx, etc).

[auniverseaway]

I know the HelpX folks would love a more robust tagging system. What we have today will not cut it for them.

[yesil]

We could imagine a fixed three column based structure where the first column is the tag label, the second column is the technical name, and 3rd column is the parent's name. Thus we can create tag hierarchies with as many level as we want.
If we introduce a 4th column for the ordering, then, we can sort based on the parent name and explicit order to always have an ordered, easy to edit tags.

[geri-w]

Thanks @npeltier currently the third level categories on the catalog (categories/creativity-design/photo) are the same as the second level on plans (categories/photo) - I think it will stay aligned, but if in the future there were differences, for instance an additional category on Plans that isn't on the Catalog, would that cause an issue?

[npeltier]

not if we have taxonomy in a place and list of used ids in catalog sidenav / plans sidenav in another one, so

• taxonomy defines photo, video, pdf
• catalog says video, photo
• plans says photo (+icon), video (+icon), pdf (+icon)

as opposed to

• catalog taxonomy saying video, photo
• plans taxonomy saying photo, video, pdf
• plans mapping of tag to icons

cc @honstar @yesil

[meganthecoder]

1. remove "Types" column : 👍🏻

FYI, the "Type" column is needed for the Blog2Milo blocks (article feed, recommended articles, etc)

[npeltier]

thanks @meganthecoder, could we deprecate it and consider "type" to be a first level of tag hierarchy?

[meganthecoder]

@npeltier I'm not exactly sure you mean that you want it to the the first level of the tag hierarchy. I'm just pointing out that if you change/remove the Type column, you'll either need to update the Blog2Milo blocks (which are complex/messy) or you're saying that this new taxonomy will be incompatible with those blocks.

[npeltier]

applied discussed changes https://milo.adobe.com/drafts/hwong/taxonomy.json, would love to :

• remove completely Types column ( cc @meganthecoder )
• remove Level 1 & Level 2, and only use the leaf name in name ( |  can be deduced)

what do you think?

[npeltier]

ok, saved a copy of all the above here: https://milo.adobe.com/drafts/hwong/light-taxonomy.json. It's half the size of the original, not sure it matters a lot considering the size of it, but i find it also a bit easier to read, and it will be easier to author consistently.

[npeltier]

ha, and while at it i also lower cased column titles to get standard json key namings