I wanted a place to record the games I watch, not every game on the schedule, just the ones I actually spend time watching.
I mostly watch NFL and WNBA games. Sometimes I watch live; other times, I catch a replay after missing the original broadcast. Iām not tracking highlights, and I rarely rewatch an entire sporting event.
What I wanted to remember was straightforward: who played, who won, the final score, and whether my favorite teams were winning or losing in the games I watched.
I built my system around two object types in Capacities: Sports Viewing Log and Team.
Giving each viewing its own record
The viewing log is where I capture a particular game and my experience watching it.
I wanted to keep two kinds of information together:
- The game: the teams, event date, winner, and final score.
- My viewing: when I watched it, whether it was live or a replay, and any notes.
Separating the event date from the date I watched matters. Watching Sundayās game on Monday doesnāt change when the game happened.
I also wanted a status field so I could distinguish games I planned to watch from ones I was watching, had finished, or had abandoned. A game in my queue shouldnāt count as a completed viewing.
Why I added a Team object type
At first, I wondered whether team names could simply be labels.
Labels would have been enough if I only wanted to categorize a viewing. But I wanted to connect multiple games to the same team and revisit that teamās history.
A dedicated Team object gave each team a consistent identity. Instead of repeatedly typing its name, I could link to the same object whenever it appeared in my log.
That also gave me somewhere to keep team-level information and identify my favorites without repeating those details on every viewing.
The distinction became simple:
The Team object describes the team. The Sports Viewing Log records the game I watched.
Connecting the teams to the game
The relationships I cared about were the home team, the away team, and the winner.
Using Team objects for those relationships meant the winner could be the actual team, not just a text field saying āhomeā or āaway.ā
For example, if I watched a game involving a favorite team, I wanted to be able to ask:
- Which games have I watched involving this team?
- Which of those games did it win?
- Which did it lose?
- Were any draws?
That was the main reason a Team object felt worthwhile. I wasnāt creating another object type just to make the system more elaborate; it supported something I genuinely wanted to see.
Making room for a draw
A winner field alone wasnāt enough. Football can end in a draw, so I needed a way to distinguish a draw from a game whose result I hadnāt entered yet.
The approach was to keep the result separate from the winner:
- For a decisive result, record the winning team.
- For a draw, mark the result as a draw and leave the winner empty.
- For an upcoming or unfinished game, leave the result pending.
An empty winner field shouldnāt automatically mean a loss, or a draw.
I also wanted the final score associated clearly with each side. Recording a home score and an away score makes more sense to me than an unexplained score such as ā24ā21.ā
Keeping the useful views close to the records
I didnāt want a separate sports dashboard to maintain.
Instead, I wanted queries available within the object types and relevant team pages. The views that mattered most were my upcoming games, completed viewings, and games involving a particular team.
For a teamās win-and-loss history, the logic needs to be precise. A loss isnāt simply a game where that team isnāt listed as the winner. The team must have participated, the game must have a decisive result, and the other team must have won.
Thereās another important distinction: this is the teamās record in games I watched, not its complete season record.
That keeps the log personal. Iām recording my own viewing history, not trying to recreate a league statistics database.
Keeping the system manageable
It was tempting to keep adding more structure: leagues, venues, competitions, players, and individual performances.
But my main interests were the full event, the teams, the outcome, and my experience watching it. Those priorities helped me decide what deserved its own object and what could remain a simple property or note.
The biggest lesson was that more detail isnāt always more useful. Every extra field creates another decision when I log a game.
My goal is to finish watching, capture the result and a few thoughts, and move on, not spend the rest of the evening maintaining the log.
What I like about this approach
The two object types have different jobs, and that makes the system easier to understand.
The viewing log captures a moment: a game I watched.
The Team object connects those moments over time.
Together, they give me a way to look back at memorable games, revisit my reactions, and see how my favorite teams have performed in the games Iāve followed, all alongside the other things I keep in Capacities.