Wow, very cool response, and thanks for all the detail. I definitely have some thoughts and ideas about the points that you mention, but before I go there, I’m going to be a bit of a jerk and pull way back into some more conceptual talk
There is a lot of really good theorizing here for what the technical solutions can or could be, but if you’ll indulge me, I’d like to have a quick go-round from the opposite end of the project- the user. The reason that I’d like to push on this a little bit is because your goals will have an impact on some of my suggestions to the items that you raise. So, I’ll put on my “product champion” hat and ask some of those annoying questions.
Who is the user?
Who are you targeting this tool toward? Is this something that is a general purpose tool for anybody, or is this more biased towards new users with limited fitting knowledge and fitting flexibility, or veteran users who have more ability to make tradeoffs due to experience, skills, and wealth? If you had to pick one (the noob or the vet), who is more important?
What is the pain that you are trying to solve?
This is probably the most challenging question and the one that will have the biggest impact on the direction of the project. This is likely where choices will have to be made as well. For example, are you:
Trying to give users a starting point with a fit that is optimized to their role and skills (based on your skills, heres a template for you to tweak for this hull and role-think “Wizard”)?
Trying to let users take an existing fitting and see how they can improve or optimize is based on their role and sills (based on your skills and the hull attributes, you should change those passive resists to active-think “Optimizer”)?
Trying to teach how module tradeoffs work in a more easy-to-understand way while fitting, so users can more transparently see how adding a given module for one attribute affects others (beyond raw stats like DPS or EHP) and show what kind of role a given fit is most appropriate to (i.e. those blasters won’t work on a sniper, so you’re now a brawler and you better add some tanks as well- think “Comparator”).
What is the context of use for the user?
I see that you mention Osmium above (I’m a PYFA girl and that team might be an interesting one to reach out to, but nonetheless…). But what is the environment and workflow that you imagine the users operating in? For example, when I do a fitting, here is my general process:
- Think about what I am trying to do and what role I am going after
- Identify the skills that I have (or will need) to fulfill that role
- Search for ships that generally align with that role and my skills
- Search for fitting ideas online, wade through the silly ones, look for patterns, and find something that looks like a good starting point,
- Drop that into PYFA (and get depressed that I’m not as cool as the people online and the fit isn’t as good for me as it is for them)
- Assess what I see as trade-offs that I can make (i.e. I can drop that mag stab to add an AR)
- “poke-and-hope” with different modules working with the results in PYFA since I can see all of the attributes at work and changing (*BUT-I have experience and know how to do that fairly well, noobs certainly will not)
- Go to sleep
- Wake up and think, “Huh- maybe I can live without that AR if I add a better AB for more speed for kiting and escape…”
- Tweak the fit again. Get depressed again.
- Identify some skills and better modules that I can train for/buy to make things better.
- Tweak the fit again.
- Build/buy everything
- Take it out and try it. Learn what works and doesn’t (paper vs. reality)
- Tweak the fit again, swap modules, test revised fit.
- Be (relatively) happy with the result
Now, I’m sure people will read this and think I’m a complete moron, but I suspect that this is not an uncommon sequence for a lot of new players. There are a lot of pain points in that sequence, so what do you see as opportunities to create “pain killers”?
Will this be a stand-alone tool, or something that can integrate with another tool (Osmium, PYFA, etc.)
How will you present information to the user?
Another hard one. One-number ratings are attractive because they are simple, but they are usually TOO simple. For example, if I look at a 1000W loudspeaker that doesn’t actually tell me anything useful beyond how much power I can put into it. What I really want to know is how loud does it get? To know that I also need to know impedance, sensitivity, frequency response, etc. Same with things like “horsepower” -cool, but what’s its 0-60 time? Towing capacity? One-number metrics are easy but frequently not helpful.
At the same time, being too atomic in your metrics gets messy and confusing- see the current situation with other fitting tools. I can see all the specs and stats, but it’s difficult for the new user to see correlation and tradeoff relationships. It can become “data” rather than “information”.
I think again, this gets to a fundamental question of what information you want to convey to the user- do you want to tell a user “A is better than B” or to help them understand why and how to improve it?
What is your MVP?
What is the least you can do that will provide a significant enough benefit to the user? How will that be built upon in later versions? What will you consciously not add? I like that you are looking at starting with a set of basic role archetypes as constraints for the project, but what other constraints do you want to add so you aren’t boiling the ocean on the first stab at this?
OK, that’s probably enough- and I’m sorry to answer your questions with a bunch of other questions, but I do hope that this is helpful! I’m not trying to troll you or be pessimistic or anything like that, just trying to add some additional considerations and framing for the discussion that can inform the technical solution.