Suggestion: Categories/Folders for storing fits of multiple different ships (e.g. for a doctrine)

[Seismix]

Hey there!

I've been sorting out my steam library the past week or so and while doing that I figured being able to save fittings into folders or arranging them according to certain categories could be a nice addition to pyfa as well. You'd be able to right click on a certain fit and assign a category to it, for example a caracal doctrine. You could then add all the fits you/your corp uses for said doctrine. I pictures something along the lines of this:

Clicking on one of your categories will open all fits you have added to it, behaving much like the standard pyfa:

This way you can keep track of similar fits and quickly compare them (e.g. nanocruisers), keep track of fleet concepts and more. This can also be used to group certain fit groups togehter, like "Tackle", "Probing", "POS Bash" and countless other examples.

Let me know what you think!

[ghost]

I like this idea and have wanted to start to work towards it for a while because the fittings window can get difficult to navigate once you have hundreds of fits for a single ship. Adding tags to fittings seems like a very useful feature even outside of arranging by doctrines, you could have tags like PVE/PVP/Shield/Armour etc.

[blitzmann]

Yes, a tagging feature has been on the radar for years (#18 it's currently the earliest open issue in GitHub lol). I have a very old branch with this feature kind of halfway implemented - sets it up in the database and displays it, but no way of adding/removing tags from a fit - the UI aspect is the piece that I got stuck on.

@burnsypet if you want to get with me via email I can take a look at the branch I currently have and see if any of the old code is viable. I have some ideas surrounding this feature that may make it a bit more functional than a simple tag feature.

[jdrusso]

@blitzmann Hey, have you made any headway on this? Happy to help work on the code if you could use a hand or don't have the time to do it yourself, I've seen that dev branch with partial tagging implemented mentioned a few times

[blitzmann]

@jdrusso I have not, this is unfortunately one of those things that I always say I will get back into and never do :P

I am not sure where my local tagging branch went, and frankly it's years out of date at this point so might as well start fresh lol. Here's my thoughts on it:

• Tags are a many-to-many relationship with fits
• Need to determine the format of a tag:
  • Tags can only be a continuous alphanumeric string without spaces. This would mean that it functions more like a "tag" rather than a "category / doctrine" as you might see in places like stackoverflow. The nice thing about working it this way is that we would be able to implement support for it in the fit search via something like a hashtag (#lolfits to search for all fits tagged as lolfits). This would allow us to avoid a separate section for for tag "navigation". The problem with this is that it might not be intuitive enough for folks to pick up on it (although once they know of it, I think it would be easy to remember). When creating fits, if the name has #<whatever> we can automatically create tags for it. This might also prove easier to integrate into some sort of third party export if we ever decide to do that.
  • Tags can be any string, and are navigable the same way you navigate the ship browser (there would either be a separate tab for "tags" or "doctrines", or there would be some toggle / switch on the current view, kind of like how there's a meta toggle on the market). This would involve more work as you would have to develop a new view for this (or rather, copy and tweak a current view).
  • personally, I like option 1 better, but of course I'm open to discussion on this :)
• Should be a place to add / remove tags for a fitting. This is the part I got stuck on many years ago as I didn't have a good place to do that. My immediate thought it to take over the Notes section of a fitting and rename is to "Meta", and this is a place where we can store various metadata about the fit (tags, notes, etc to be determined :P)

[jdrusso]

Thanks for the reply!

What would you think about having tags appear in the ship browser under the ship name, combined w/ what you're saying about using the Notes section? Sort of an extension of your option 1. I definitely think it's better not to have a separate tag navigation, if we can integrate it into the existing ship browser.

To explicitly describe this in terms of (at least my, but probably most people's) use case, I'd want two main things out of this:

• Be able to navigate to a flexible hull, like a Phoon, and be able to see tags to distinguish between "armor", "shield", "nano", "fleet", etc. Color coding A+, but one thing at a time.
• Be able to filter existing fits by tags, i.e. type "Armor" into the ship browser search and filter out any hull classes that don't have anything matching that tag. That behavior should be consistent across the levels of the browser.

I like option 1, are you thinking a # in the name, once the fit is created, gets scrapped from the name and re-assigned to a tag? Personally, I know I sometimes have actual ship names with # characters in them, but that's probably an edge case that losing wouldn't be the end of the world. That said, changing existing behavior of something like that might not be the friendliest thing, I imagine I'm not the only one with a #YOLOSWAG drake saved.

I think option 1 still leaves open the option of later adding a third tab for tag navigation, but we wouldn't have to do that immediately.

[blitzmann]

are you thinking a # in the name, once the fit is created, gets scrapped from the name and re-assigned to a tag?

I guess in my mind, yeah, but you bring up a good point, so I think we could keep it there and auto create tags (or maybe set it as an option in preferences).

What would you think about having tags appear in the ship browser under the ship name

In general I like the idea, however I feel like it might become too crowded. I like the fact that they would be visible in the show browser for easy identification, but what if a fit has multiple tags that don't all fit? We could have the discussion of removing the current last modified timestamp, but... eh. I'm open to suggestions on this :)

[DarkFenX]

I think that tags are much more useful than last modified timestamp. Personally, I haven't used timestamp much at all.

[blitzmann]

That is true, and that is something that could potentially be moved to a "meta" section anyway. But replacing the timestamp with the tags only gives us x pixels more in space - we would still run into issues displaying tags if they run off the panel...

ofc, without seeing such things in action, it's hard to say. if we can get a simple example going, we can work off that to determine what feels right :)

[jdrusso]

My thinking is sort of a list of tags right below the fit name, where it'll stick to the width of the browser. The "width of the ship browser" part may end up being nontrivial to adjust to, though, but if someone wants to add 300 tags for a fit and fill up 2000 pixels of vertical space in the browser, that's on them IMO

I've just been familiarizing myself with the source a bit so I don't butcher your code while I work on my branch -- would this require a database migration + a new "Tags" column? I was thinking of adding that column with just comma separated tags.

Also +1 for I don't use the timestamp ever, I'm a turbonerd that has spent some time on Pyfa more or less every day for a few years theorycrafting shit and I wasn't even aware that existed. Sample size of 2 isn't the most significant thing ever, and removing features can be a questionable call, but that's my .02 ISK

[blitzmann]

so I don't butcher your code

ha. haha. The code is already bloody and slaughtered 😛

would this require a database migration

The proper way would be to have two new tables: tags and fitTags. When the user adds a tag to a fit, we would first check to see if it exists in the database. If not, create it and obtain the new ID, otherwise we use it's existing ID. fitTags is simply a M:M relationship between tags and fits, and would contains two columns: tagID and fitID (actually, probably also a created column as well).

The reason we would want them in another table is because it's easier to query. Comma-delimited string column could work to find all the fits that have "lulz" as the tag name, but it's would have worse performance, would rely on wildcard searches (WHERE tags LIKE '%lulz'), would break standard convention of database normalization.

Since they would be two new tables, and not changes to existing tables, migration script is not needed. 😄

[blitzmann]

I'm okay with getting rid of timestamp, tbh. I've never used it myself. it might be good to include it for the "recent fits" list, but otherwise hide it