The header comparison column really should say something like "Click on a team to the right to show their players and stats", i.e. something to convey what action the user needs to take to populate that column. But, since I'm unsure what the UI will be for clicking on teams, this is a TBD.

Or maybe the header can be something like "[similar team]" and the cells beneath it can contain more text to explain what action can be taken to populate that column. It could even be the case that instead of showing cells, we just show a blank white area of the correct height which includes that text. Just spitball-ing ideas now.

Currently each column of the player comparison region only is a vertical list of names, but it's necessary to also see the pertinent stat values next to those names.

My kNN algorithm currently only looks at the top 10 players in games played, to help account for injuries and in-season trades when attempting to accurately describe a team's roster. But in some cases (e.g. J.R. Smith and Timofey Mosgob in the 2014-15 Cavs), there's a tie for 10th place in games place, and right now that tie is settle by selecting the first player in alphabetical order by first name. This is unintuitive -- it'd be better to break the tie based on minutes played. Potential fix: sort primarily by games, and then do a secondary sort based on mp_per_g. If this is too much of a perf hit, think about settling ties only when they occur, i.e. not just performing this secondary sort for EVERY team.

Currently, the early 2000s Seattle Supersonics are referred to as OKC, because I don't make any distinction. Same for the New Jersey Nets and BRK. Might be worth storing alternate names/colors in a dictionary specifying different aliases for each team.

Ensure that players that had, say, 1 game player with 18 rebounds, doesn't show up at the top of his team's list, because he only played 1 game. I.e. account for games played in kNN.

Ensure that number of rows in list of neighbor players is same as that of chosen players, and make sure that this is reflected in the calculations in routes.py. If neighbor has more, remove players from it, else remove players from chosen team (this reflects current calculations in routes.py)