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!
-
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.
-
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
)
- 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).