Open ALonelyJuicebox opened 1 year ago
xx790
commented
1 year ago This has some related discussions. Everyone comes from different perspective, and I think the eventual implementation should consider some of them.
I'd like to link to
I refer to tag groups as tag namespaces. And I think it can become a part in even more powerful feature set.
echo6ix
commented
1 year ago I kind of like this idea, but I think there a few issues (in my opinion) with the execution.
I would solve this by adding a filter button which lets the user filter his tag dropdown list easily based on the tag category. The user can no go about systematically tagging a scene in a formulaic way. Filter by "action" first, add relevant action tags. Filter by "location" second, add relevant location tags. Etc.
Displaying tags would require physically grouping them together, either with a leading tag category string and/or by using distinct colored chips.
What about tags that have no group? They should probably be displayed first since they require no leading tag category heading.
Idk, maybe this is completely insane, but that's how I would implement "tag groups" if I was going to use such a feature.
xx790
commented
1 year ago Look at how https://oreno3d.com/ displays tags. Looks like they scrape them from iwara (with no additional metadata) and assign groups/namespaces to some of them locally. Then show tags in named groups on the frontend.
But I'd consider this a partial implementation. I'd like this working in combination with custom fields (as discussed in links above), where each field can have a group/namespace attached to it. No need to have everything in a single dropdown/list.
stg-annon
commented
1 year ago I've also been using prefixes to organize tags along with @AdultSun, I suggested another potential solution for this kind of issue in #3108 which would be a "lightweight" way of implementing something like this feature with just one additional sort_name field added to tags and using the existing filter structure to limit the tags that show up for different content-types/contexts
ALonelyJuicebox
commented
1 year ago Had a crazy busy week, sorry for the wait and thanks to all for the responses.
This has some related discussions. Everyone comes from different perspective, and I think the eventual implementation should consider some of them.
I'd like to link to
- [RFC] Stash built for a particular type of conventual studio-produced porn, management of porn outside that could be improved #1028 (comment)
- [Feature] a better tagging system - using tag attributes #3400
I refer to tag groups as tag namespaces. And I think it can become a part in even more powerful feature set.
There's a quote from that OP on how this could be translated from stashDB that I'll reference directly here.
all the example above can be translated to stashdb tags in the following format: tag (value) . i.e. threesome (MMF) is the same as the threesome tag with the value MMF.
I mean my counterargument would be, "what was wrong with the implementation on stashDB?" Why make fundamental changes to further mismatch how Stash works versus StashDB?
With no disrespect to that OP, I'm genuinely concerned about how edge case-y that feature would be for an average user.
For example things like...
percentage of anal to describe how much of the scene is anal
How would you really quantify that? Is this something users want to be able to quantify?
Penis size attribute
Why not attach this value to the performer object?
Stash is already beginning to suffer from UX challenges where certain flows really have to be taught before a user is going to know to use it. This is evident from various repeat questions on our discord server.
I would argue that teaching someone that Tag Groups like this... Tag Groups - For a category of tags (Ex. Actions) Parent Tags - For a Tag that be further specified (Ex. Biking) Child Tag - For a more specific version of a parent tag (Ex. Off road biking)
Is way easier concept to teach users and design UX for than Tag Attributes... Parent Tags - For a tag that can be further specified Child Tags - For a more specific version of a parent tag Tag Attribute - Can be another tag (which can be selected via radio button or check box), a numeric value or percentage in a range, a color, or performer(s)
From a tagging accuracy and tagging speed perspective, I would argue that the complexity of #3400 does not justify the overhead compared to tag groups nor is it a faster tagging experience.
Look at how https://oreno3d.com/ displays tags. Looks like they scrape them from iwara (with no additional metadata) and assign groups/namespaces to some of them locally. Then show tags in named groups on the frontend.
But I'd consider this a partial implementation. I'd like this working in combination with custom fields (as discussed in links above), where each field can have a group/namespace attached to it. No need to have everything in a single dropdown/list.
I unfortunately can't read japanese so this isn't a good example for me but I assume it's very similar to most booru sites out there? Agreed that the UX of a single dropdown list can be improved on, but disagree that #3400 is a step in the right direction.
ALonelyJuicebox
commented
1 year ago I kind of like this idea, but I think there a few issues (in my opinion) with the execution.
- Just adding a prefix to a tag doesn't really solve the problem in the premise. The user is still sorting through a huge list of tags. The only difference is there's a prefix now. If you're not using Stash religiously, you're probably going to forget the meaning of those emoticon symbols. If you're using a full string instead of an emoticon then you're basically adding another column of data to an already massive list.
Agreed, and I really like your filter suggestion to help solve this! Here's another one that can help with tag accuracy. I have some javascript I'm working on that provides additional feedback to the user as to whether or not they've tagged the basics for a given scene.
It works like this. (be kind to my MS paint visuals here lol)
Some tag groups SHOULD have some representation on all tags. For example, all my scenes should have one of the tags in my Number of Performers Tag Group. This could be Solo (Female), Male/Female, MMF, whatever.
By giving the user feedback that the scene they're looking at is missing a tag for one of the tag groups that should be represented on any scene, this can significantly improve on tag accuracy.
- Changing the sort order from alphanumeric to tag category first is kind of counter-intuitive.
Disagree with you here, I think users should absolutely be able to define sort order as it pertains to Tag Groups.
It also helps with tagging process. If my process is...
...or something like that, I can very quickly skim through the dropdown to the Tag Group section that I need to, consistently, without having to think about the alphanumeric sort. This flow could certainly improve with your filter idea, but fundamentally I don't think there's anything wrong with being able to affect the default sort.
Definitely not saying we should get rid of alphanumeric sort though, I'm just saying Tag Group sort should take precedence. Except for maybe tags with no group. I can see that going either way.
xx790
commented
1 year ago My mistake is to point at other issues and even direct links to comments under issues and not putting a bold disclaimer that I want a reader to pay attention to my (linked) comments specifically or the whole discussion. Discussion in #3400 went in various ways from the OP post. I should've probably also brought up the mention of mediachips' "meta" as an example implementation. Or I just should've invested my time into rewriting my whole vision and opened yet another issue.
From my point of view, OP ideas in #1028 and #3400 can't be taken as is and are not great in isolation. But those issues as well as this one should have a common solution. That's what I'm talking under each issue.
I wish stash maintainers would put more effort to have a public roadmap with properly curated proposals in order to guide community effort.
MrX292
commented
1 year ago I wish stash maintainers would put more effort to have a public roadmap with properly curated proposals in order to guide community effort.
do you mean like https://github.com/stashapp/stash/milestones ?
ALonelyJuicebox
commented
1 year ago My mistake is to point at other issues and even direct links to comments under issues and not putting a bold disclaimer that I want a reader to pay attention to my (linked) comments specifically or the whole discussion. Discussion in #3400 went in various ways from the OP post. I should've probably also brought up the mention of mediachips' "meta" as an example implementation. Or I just should've invested my time into rewriting my whole vision and opened yet another issue.
From my point of view, OP ideas in #1028 and #3400 can't be taken as is and are not great in isolation. But those issues as well as this one should have a common solution. That's what I'm talking under each issue.
I wish stash maintainers would put more effort to have a public roadmap with properly curated proposals in order to guide community effort.
Hey, I'm sorry for misunderstanding! 🙏🏿 I did a very basic review of the Chips concept on MediaChips and it looks similar to the Parent/Child concept we have here with differentiation between two types of tags ("complex" and "simple")?
I think that gets really hairy when you add community platforms like StashDB into the mix. I'm also still concerned about complexity for the sake of complexity and what an average user is going to want to be able to do in Stash.
If you have the time (and so I'm not strawmanning your points here) I'd love to see what you're trying to propose maybe in a different issue so it's referenceable?
xx790
commented
1 year ago I wish stash maintainers would put more effort to have a public roadmap with properly curated proposals in order to guide community effort.
do you mean like https://github.com/stashapp/stash/milestones ?
No, rather https://github.com/stashapp/stash/projects and meta issues owned by maintainers.
Many people open requests with different perspective on the same missing functionality. Devs might have some idea on the development direction to eventually address it. But there is no synergy.
sleetx
commented
1 year ago Good discussion here, but I am not a fan of the prefix or emoji additions to tags AT ALL. I consider it a working band-aid, but it's driven by the pain point of managing parent/child tags. A "tag group" is essentially the top level parent tag. I see a two-part solution here:
The drop-down on a Tag field should contain a two column view. One column being the tag name, and the other being its parent (or top level) tag. No need to manually map emojis or maintain prefixes on each tag name itself.
a UI redesign of the tag association process. Some sort of drag-and-drop heirarchical view on the Tag page that takes a lot less effort to map out the heirarchy of your tags. Here is a basic example: https://github.com/rhwilr/vue-nestable
Alright! I've had manually defined Tag Groups (aka Tag Categories) for over a year now and I've received a bunch of questions on how it's accomplished. I've even written a guide that instructs users on how to do it using emojis and spaces.
Tag Grouping has absolutely become a "killer app" feature of Stash for me. But I completely understand that not everyone is going to want to go through all their tags and add spaces and emojis like I did to group tags manually. Let's get this feature added the right way!
Challenge
There is currently no built-in method of grouping tags in Stash. The problem is, as your list of tags grows it becomes more and more unwieldy to properly tag your scenes with all the appropriate tags for that media.
Speaking frankly, scrolling through dozens or even hundreds of tags that are sorted in alphanumeric order in a dropdown list looking for applicable tags just doesn't scale! We can do better!🙂
Proposed Solution
Allow users to create Tag Groups. Some examples of Tag Groups might look like...
There are three key subfeatures of this request I want to highlight.
1 - Users should be able to order the Tag Groups.
Users may want to customize the order of tags in order to streamline their tagging flow.
For example, I know all my scenes should have a "Scene Type" Tag Group. After all, any given scene in my Stash is going to be "Amateur", "Professional", or whatever.
Since this Tag Group is the most common Tag Group in my Stash, I want all tags that are associated to the "Scene Type" Tag Group to show up first in any tag dropdown list or when viewed on the Tag page.
That should happen even though the "Action Tag" group should alphabetically be first!
For example instead of this... (normal, alphanumeric order) 1 - Action Tags 2 - Location 3 - Scene Type
Let me custom define the organization of those tags like this 1 - Scene Type 2 - Action Tags 3 - Location
You can see an example of this customization in the image above where my tags are alphabetical within the Tag Groups I have defined.
2 - Users should be able to define a Tag Prefix
Users should be able to define a prefix that would get applied to the front of any tag that is part of a given Tag Group. I've always used Emoji's but numbers or even the name of the tag group itself should be able to be defined. It is important that the user be able to identify what Tag Group a tag is in at a glance.
For example all of these should be valid Tag Prefixes 😎 - 1 - Scene Type -
And then, again as an example, here's what this would look like when attaching those Tag Group prefixes to a tag. 😎 - Professional 1 - Professional Scene Type - Professional
The image at the top of the request has some good examples here.
3 - Allow users to define 'details' for a Tag Group
Similar to the "Details" field of other objects, let's allow users to define details for Tag Groups. Let me write down the rules for a Tag group I created so I can reference them later if I need to-- I'm a forgetful person! 🙂
Additional Notes
I've seen some discussions about where the concept of a Tag Group and a Parent Tag intersect. I think these two features can and should coexist.
It should be perfectly reasonable to have
🏃🏿♂️ - Action Tag
(This is the Tag Group)🏃🏿♂️ - Running(This is the Parent Tag)🏃🏿♂️ - Running (Sprinting)(This is the Child Tag)I think there's real benefit in being able to relate tags together without them being tied to the parent/child tag concept.
Thanks for reading!