antialiasis / favorite-picker

A tool to sort things in order of preference.
MIT License
128 stars 148 forks source link

Select from related groups #20

Open The-furf-of-July opened 1 year ago

The-furf-of-July commented 1 year ago

While using the software, I frequently encountered situations where I would know exactly what I wanted to compare something with, and not get the chance to convey that information to the software.

For example, I told it I liked victreebel better than beedrill, but mega beedrill continued to show up for the next several rounds because I never got the chance to say I liked beedrill better than mega beedrill. The same happened with Venusaur and Mega Venusaur, I wanted to compare them to each other directly, but one got disqualified first. This is relevant for similar entries, especially relevant with forms enabled.

What I think would help is having a button or field to allow manually inputting a set of entries to compare. This way users can manually input data they feel would significantly impact the sorting.

For example, you could tell it you like a certain flavor of alcremie better than the default. Or sort vivillion colors in advance without ranking the species too high. Or tell it you like the 2nd evo of your starter better than the final evo.

The information conveyed by random matches isn't inaccurate, but I feel it would be very beneficial to the user to have the option of deciding what information is the most important to the rankings, and input it without having to just hope RNG gives them that relevant comparison.

antialiasis commented 12 months ago

This is an interesting thought, but having the ability to manually specify an individual comparison feels quite awkward UI-wise without the point being quite obvious enough - my brain is smoking even trying to imagine how to try to succinctly explain to the user what this option does or why they should use it, if I added it.

For the purposes of the rankings, knowing that you like Beedrill more than Mega Beedrill doesn't really give the picker more information than knowing you like Beedrill more than any other Pokémon; you just notice that you're still getting Mega Beedrill more than you would notice other Pokémon you're seeing that you also like less than Beedrill.

What could be more reasonable is some form of optional mode where the first run has you pick from batches of related Pokémon instead of being randomly shuffled - the simplest version of this would be to just order the list in National Pokédex order, a more sophisticated version would unite cross-generational evolution lines and such and possibly make you pick at least one from each family. But also, I should point out this would be the antithesis of the other ticket you made, where you were wishing that your choices were systematically arranged so that you would match a single Pokémon you really liked against others you didn't care for - in this hypothetical we would be systematically matching up Pokémon that are relatively more likely to be close together in people's personal rankings, in order to have a more spread-out list later. It's something that could be done, especially as an optional thing, but everything has pros and cons.

The-furf-of-July commented 11 months ago

The UI issue is very fair. My workaround in the meantime has been to save-edit things in.

I still think even though it's mostly a perception thing, getting info on related or similar entries early on would be extremely beneficial for users like me who aren't entirely consistent in their choices in the long-term. Pokémon like Arceus, Silvally, and Vivillion end up getting pretty scattered. Knowing that the rankings I'm more confident in (like mega-form preferences, or which color to make the butterfly) are locked in rather than leaving it to sort itself out over time would help a lot.

I like the idea of that optional mode a lot. The system already has some potential data it could use for this, with some modification (like the forms, regional variants, evolution chains). It'd take the togglable entries referencing the item they're similar to, though.

As for its relationship to the other ticket, I think the ideal situation is that both are implemented, and this takes priority. That way, it narrows down the related groups first before taking on the larger dataset, but in both cases it could still use a strategic selection strategy.