Hi @HeMan,
Once again, thank you. I can’t emphasize enough how impressive it is, we have a proper disambiguation framework now! Associating a relationship with a marker is also an excellent idea!
With the current version, I see three implications:
- Roles become an alternative way of tagging content in Stash. On one hand, it’s as much satisfying as it is precise, now that attributes can be bound precisely. But on the other, Stash’s native tagging system ends up lagging behind, as it becomes redundant. (See proposal 1 below)
- One may create a very complete and complex role-tagging system, that can accommodate precise and unambiguous descriptions. However, a complex system may become more difficult to organize, as well as navigate when in the process of role-tagging content. (See proposal 2 below)
- Once a vast amount of content is role-tagged using a complex system, it also gets more difficult to search for exactly what you’re looking for. (See proposal 3 below)
Some proposals:
1. Expanding interactions between the role-relationship system and Stash’s native tagging system.
As things stand, Role Tagger is almost like a parallel tagging framework that, unlike Stash’s native tagging system, actually binds attributes to specific participants. You can basically describe not only what a participant does (actions), but also what they look like (appearance), what they look like doing what they do (emotions related to their actions, the situation) and who does what not only to them, but to specific parts of them.
Currently, Stash’s current tagging system isn’t relational: it allows giving a list of attributes for content without binding it to any of its elements. However, this tagging system may seem redundant to one who has taken time to create a precise relational role-tagging system.
I see two directions this may take:
A. Changes in Stash itself–requesting expansion of the tagging system. However, it probably (and understandably) wouldn’t be high on the devs’ priority list.
B. Expansion of the plugin (or a companion one) to improve the tagging framework and its interactions with roles and relationships.
We have a headstart on option B since you implemented @spaceyuck’s suggestion, but I’ll expand a bit on it:
- An idea might be to directly use tags as roles. There may be a list of “Tags” objects within Stash that are treated as “Role” objects by the plugin.
- Another idea might be to do the opposite: make sure roles and relationships are full-fledged objects in Stash’s logic, just like Performers, Images, Scenes, Galleries, etc. (I expand a bit on the idea in proposal 3 below, with flavor C).
That would allow us to use tags for giving attributes to roles and relationships, just like we can currently use tags to give attributes to performers. A role or relationship could be tagged (and filtered on) depending on the broader category it belongs to. For instance, one (or several) relationship(s) could be tagged as “dominant” or “submissive”. All in all, it would help “naming” and categorizing relationships.
No matter which direction is taken, this would not only add these tags to content, but also help browsing roles and relationships (e.g. through filters). Although splits currently do that, they can’t be filtered on, and have no interaction with the tagging system. Generally speaking, it could also help with proposal 2:
2. Improving organization and UI.
The more precise one gets with their roles and attributes, the more complex one’s role system gets. But in case one starts to have an extensive list of actions and/or attributes, I see two consequences:
- Performer cards may end up cluttered when assigned several roles.
- Navigation becomes quite complex, because of (i) a potentially quite long drop-down menu and (ii) labels without aliases.
Regarding consequence 1, I see a simple solution: in the Role manager, determine which roles appear on performer cards and which don’t. Another admittedly more difficult possibility would be a pill popup for roles on performer cards, just like for tags.
As for consequence 2, @spaceyuck’s solution only helps as long as you’ve already tagged content before adding roles and relationships, and only as long as the role naming in one’s system is consistent with their tag naming. That’s why I’ve got a few extra possibilities in mind:
- For 2(ii), allowing splits and roles to have aliases might be useful (or turning tags into roles, as suggested in proposition 1, since tags can already have aliases).
- As for 2(i)–the drop-down menu–I suggest either (or a mix of both) the following A or B:
A. Several drop-down menus: one per split.
| Pros |
Cons |
| Each menu would be shorter. Also, having an overview of all splits is useful to consider the most important aspects of a scene or picture. |
If you have a lot of splits, that makes a lot of drop-down menus. |
B. Conditionality for drop-down menus to appear.
We could get inspiration from the Fast Tagger plugin, where menus can be configured to only appear under specific circumstances (e.g. Performer is male / female; performer has tag X or tag Y; performers A and B are related through roles B or T; etc.).
| Pros |
Cons |
| Very precise. Avoids cluttering in case of complex and extensive splits/roles distribution. |
Takes a lot of time setting up conditions for each drop-down menu to appear. |
3. Improving searches.
Currently, there as a few types of queries one may want to make, but that neither Stash’s native UI nor the plugin’s accommodate (except for type 1, I just suggest improvement). I narrowed them down to four:
| Query type |
Explanations and/or use cases |
Improvement suggestions (as per flavors A or B or C listed under this table) |
| 1. Any one role, no matter which performer has it |
Find any performer such as it has role A, or B, or C, etc.; we currently can by clicking the role on the performer’s card from a scene or picture. |
A. Patching Performer cards so that, no matter where they appear, there always is a clickable “Role” pill menu with all their roles. It would let you access each role just like you currently do from a scene or picture. // B. Clicking on the role in other places, such as the Role and / or Relationships tabs. // C. Creating a dedicated page, from which each individual role could be accessed. |
| 2. Any set of roles / relationship for a specific set of performers |
Finding any performers X and Y (and Z, etc.) such as X has role A, Y has role B, Z has role C, etc. Optionally, specify which is linked with which. |
A. Patching Stash’s UI in the “Appears With” section of a Performer page, adding a menu that would let you specify which role or relationship your Performer must have with another performer they appear with. // B. Fuse the Role and Relationships tabs so that, for one of a performer’s roles, you may specify which other performer it must be linked to, and what is this other performer’s role. // C. Creating a dedicated page with its own search engine: define each Performer’s roles and whether they are linked. |
| 3. Any set of roles / relationship for one specific performer, no matter with whom |
If performer X has role A, find cases where his role is linked to any performer who has e.g. role B. For instance, if Performer A “Gives oral” to Performer B, it would indeed make sense for Performer B to have a “Receiving oral” role, and thus link A and B based on that; but not to link them based on some other unrelated role of B’s (such as “Protagonist” or “Antagonist”). However, one may want to find Performer A giving oral and any case when it’s with another performer doing / being something unrelated to “Receiving oral” (such as an “Antagonist” or “Protagonist” role). |
B. Fuse the Role and Relationships tabs so that, for any of a performer’s role, you may specify which other role it must be linked to. // C. Creating a dedicated page with its own search engine: define the Performer’s role and which other role it must go with (whether linked or not). |
| 4. Any set of roles / relationship no matter which performers are involved. |
Find any content where, no matter who are the performers, there is a link between role A and role B. |
A. Filtering from Performers using Custom fields. // C. Creating a dedicated page with its own search engine: define two roles that must be linked. |
UI-wise, I reckon it may be implemented through one of at least three flavors–either:
A. Patching Stash’s native UI.
I know depending on which part of the UI, it may currently be a no-go. For the Edit UI, as you mentioned, there are no plugin patch points in the Edit UI and Filter UI. I’m suggesting other parts of the UI, but I don’t know whether they’re patchable.
B. Using the plugin’s Role tabs.
The Relationship section in a performer’s page Role tab could be even more precise by adding two (e.g. dropdown) menus: (A) a “Filter by relationship” and / or (B) “Filter by partner”. In which case we may even consider fusing the Role and Relationship tabs. Filtering by relationship would imply defining the two roles that are supposed to be linked.
C. Creating a whole new “Pairing” page dedicated to roles and relationships.
That may be a stretch, but it might be worth it; many other plugins create their own dedicated page (AudioTab, Ascension, Stashgifs, etc.). That’s where treating Relationships and Roles as their own kind of object (as mentioned earlier, at the end of proposal 1) might be interesting. It would also be more ergonomic to migrate the Role manager in this page.
End note: suggesting a ghost performers framework to Stash’s devs
We mentioned the idea of ghosts performers in previous replies. Using your plugin urges me once more to bring it up to Stash’s devs. We’ve got a great headstart on relational tagging, but as soon as one or two unidentified participants are in the picture, if you want to link them through roles, you have to associate them to a Performer object in the database anyway.
An option is to create “Unknown” performers to act as placeholders that may be linked through the plugin’s Relationship framework. However, this disambiguation is still much too complicated and not precise enough. It’s roughly the equivalent of using a Performer object as a tag (too general, lots of wildly different things listed under it). Moreover, it takes creating several numbered “Unknown Male” and “Unknown Female” performers–as much as needed to accommodate all possible parameters (threesomes, foursomes, orgies and so on).