show brew system tags on user page brew items

[ericscheid]

From #240

I know there has been talk of tagging/grouping, but in the meantime it would seem that the selected game system for a brew could be represented on the .brewItems. I envision either small color coded labels below the current .info div listing the system and other tags, or using the game system to determine the entirety of each .brewItem card's background color.

I enisage tags similar to GMB, but for the standard tag groups have an additional tint .. e.g. all system tags are green, all type tags are blue, all user-custom tags are white.

• output an extra line in the .brewItem div.info to show the system tags (if any)
  • <span title="System: 5e">5e</span> or similar
• provide css styling as desired.

UPDATE: implemented via brew.tags

[ericscheid]

Hold off unless there is an obvious and simple incremental PR.

There is work in progress on brew.tags, of which brew.systems is arguably a subset of. That's a much bigger piece of work though, so maybe don't hold off.

[calculuschild]

I'm reviewing @G-Ambatte 's PR #2330, and all the work on sprucing up the User page is looking great. I just had some thoughts and want to see what the consensus is:

As @ericscheid points out, Systems are kind of a subset of Tags, so I ask you all:

• Do we actually need/want a whole separate property for Systems? It has no real function yet, so now would be the cleanest time to dismantle it before adding it to the user page.
• If yes, is there any concern for the added space it will take up in the User Page brew items? It's already getting pretty crowded. Could they just be merged into the "tags" area?
• If we remove Systems, and just let them fall into standard tags is it worth the potential inaccuracies as far as "Brew search" is concerned? Purely user-created tags would result in duplicate tags (users looking for 5e content would get different results searching "5e" vs "5th edition"), but we would not have to maintain an ever-growing list of systems ourselves or cater to individual requests.
• If we really wanted to, would it make sense to maintain a predefined list of tags that will be treated as "systems" (for search purposes, etc.) but otherwise are just normal tags? Maybe they display differently or show up as "suggested" when a user starts typing a tag?

@ericscheid @G-Ambatte @jeddai @AlexeySachkov ?

[ericscheid]

is it worth the potential inaccuracies as far as "Brew search" is concerned [because user generated content likely inconsistent]

Not worth letting that happen. Implementing a <datalist id="tag:systems" /> is pretty easy, do that first.

In approximate order..

• allow entry of custom terms for system:, type:, and meta:
• allow entry of & in tags Tweak tags schemas #2333
• implement UI for tag entry that presents pick-lists of pre-coordinated terms for system:, type:, and meta:
• advise /r that System checkboxes UI is going away, advise data will be migrated to tags
• hide the Systems UI in the meta-data panel
• migrate system tags to system:D&D 3.5e, system:D&D 4e, system:D&D 5e, and system:PathFinder
• schedule in deletion of system tags after sufficient time to allow for feedback/blowback/panic

[AlexeySachkov]

I'm reviewing @G-Ambatte 's PR #2330, and all the work on sprucing up the User page is looking great. I just had some thoughts and want to see what the consensus is:

As @ericscheid points out, Systems are kind of a subset of Tags, so I ask you all:

• Do we actually need/want a whole separate property for Systems? It has no real function yet, so now would be the cleanest time to dismantle it before adding it to the user page.

I would say merging them into tags is better approach. It is more extendible than having separate property for each potential brew properties. I suppose that tags should be easily searchable, so we should be able to setup some filters over properties-as-tags without them being separate properties.

• If yes, is there any concern for the added space it will take up in the User Page brew items? It's already getting pretty crowded. Could they just be merged into the "tags" area?

I honestly don't know how that area looks like now and haven't looked in there yet, but I suppose that we could show only a couple of tags by default and add a button to toggle it into a full list.

• If we remove Systems, and just let them fall into standard tags is it worth the potential inaccuracies as far as "Brew search" is concerned? Purely user-created tags would result in duplicate tags (users looking for 5e content would get different results searching "5e" vs "5th edition"), but we would not have to maintain an ever-growing list of systems ourselves or cater to individual requests.
• If we really wanted to, would it make sense to maintain a predefined list of tags that will be treated as "systems" (for search purposes, etc.) but otherwise are just normal tags? Maybe they display differently or show up as "suggested" when a user starts typing a tag?

I think that we might want such property-as-tag tags to have special format (something like "property:value", for example). That coupled with an auto-complete over most used values should prevent the list of possible values to grow too huge. Plus, I suppose that maintaining a list of supported property-as-tags is a less burden than also maintaining a list of values allowed in there. With auto-complete, users should be able to define "a standard" version of property-as-tags values themselves simply because that the most used one will show up in auto-complete more and therefore it will be used more often, eliminating less popular spellings.

[ericscheid]

I think that we might want such property-as-tag tags to have special format (something like "property:value", for example). That coupled with an auto-complete over most used values should prevent the list of possible values to grow too huge. Plus, I suppose that maintaining a list of supported property-as-tags is a less burden than also maintaining a list of values allowed in there. With auto-complete, users should be able to define "a standard" version of property-as-tags values themselves simply because that the most used one will show up in auto-complete more and therefore it will be used more often, eliminating less popular spellings.

We already support <category>:<value> syntax for tags, but only for system:*, type:*, and meta:*. This special formatting and acceptable categories can be revealed/discovered via adding a <datalist/> to the input. See #2335.

Tags that have the syntax of <category>:<value> are rendered as <span class="category">value</span> in the user page. This opens the future possibility of styling these tags slightly different if we want.

NOTE: styling of tags per category can be achieved vis CSS:

.brewItem .brewTags span.system { border-color: red; }
.brewItem .brewTags span.type   { border-color: blue; }
.brewItem .brewTags span.meta   { border-color: green; }

[ericscheid]

Btw, if we're looking at merging the brew.systems object into brew.tags, can we take care to be more explicit with the literal values. Having system:3.5e and system:5e without specifying that those are versions of D&D will lead to confusion.

For example: I use HB for my AD&D 2e stuff, but I won't tag those brews as 2e as that will only annoy Pathfinder 2e users to no end. (And they me in return). Meanwhile there are also 2nd, 3rd, and 4th editions of WFRP. Best to include the base system in the tag value: (e.g.) system:D&D 2e, system:PF 2e, system:WFRP 2e, system:D&D 5e.

Also, we need to add & as a valid character in tags before we go creating system:D&D 5e tags. (see #2333)

[ericscheid]

Styling of tags per category is now possible, though not yet deployed to production.

#3165