Creating a tool to manage scorekeeping for Fantasy Survivor League

2

Nice! I think you’re on the right track, though there are a couple things that give me pause.

There are a couple of situations where you’re leaning heavily on columns in a way that feels correct in the world of spreadsheets, but less-optimal for Coda (which is a bit more in the world of databases):

  • column per week in the scoring table
  • column per choosable character slot

These design choices aren’t the end of the world. Their main drawbacks are:

  • They don’t scale well (but you don’t care, cause you know already exactly how long the season is for example)
  • They make for long, tedious formulas (someone’s score is Week1+Week2+Week3+...)

I would say, it’s perfectly reasonable to continue on your current path; it should work fine for you in this situation (and has the benefits of seeing things in a spreadsheet layout, e.g. everyone’s points for each week, which you probably want).

Buttttttttttt if you want to build it in more Coda-y way (a more Nick-y way? but I think a Coda-y way haha), whose patterns will serve you well in future docs that are more complex / dynamic…

Aim to use tables and filtering rather than hard-coding columns

I actually helped someone else earlier today with a similar situation - this might be a good read to see what I mean. But basically the idea is that you create tables for things like transactions, or connections between people and contestants.

Let’s look at the contestant points. Instead of having a column per week, my instinct would be just to have a table of Weeks, and then a Points table with 3 columns: Contestant, Week, Points. While not as ideal from a visual perspective, the data is easier to work with in formulas (you can also group that table by weeks which helps a bit).

The benefit of structuring things this way is it’s easier to slice the data in different ways:

  • Points.Filter(Contestant=Brando).Sum() for all of Brandon’s points

Or more abstractly, in the Contestants table you could have columns for

  • contestant’s total points: Points.Filter(Contestant=thisRow).Points.Sum()
  • or contestant’s point history: Points.Filter(Contestant=thisRow)
    • This one is great for showing as a subtable in a detail view of a contestant

This architecture lets you arbitrarily add new weeks as needed without changing any formulas (which again, I know you don’t need here, but in theory it’s nice haha)

And if you move all a user’s picks into a single column, you can do things like Points.Filter(MyPicks.Contains(Contestant)).Points.Sum() for a total of all the points of all your picks.

Back to your original questions!

  1. This is kind of answered above, though again, I think you can get by with what you have because of the well-defined, static nature of the problem space here.

  2. If you go with my architecture, you can select a week from the dropdown, and then those buttons will be like

AddRow(
  PointsTable,
  Week, [WeekToEditDropdown],
  Contestant, thisRow,
  Points, 3
)
  1. Sometimes the value a user derives from a contestant is more than the contestant derives and we need to account for this somewhere. Does the Power Player change each week? If not, you could hard-code a user’s point total with like Picks.Points.Sum() + PowerPlayer.Points (I forget the exact rules - maybe it’s only certain kinds of points that you get bonused on, so like PowerPlayer.Points.Filter(type="immunity"), if you were to add a points type column to the points table).