Analyzing My Garmin Data
My Garmin history contains years of activity records, but individual workout summaries tell only part of the story. I wanted to step back and ask questions about the pattern: when do I start activities, how do Saturday workouts vary, and how do different activity types connect to recorded calorie ranges?
This project grew out of my MIDS coursework. It gave me a chance to apply data visualization concepts to a dataset I know through experience, using Python and Jupyter notebooks for analysis and Altair for interactive charts. Familiar data made it easier to ask useful questions, while also making it necessary to check the assumptions I brought to the analysis.
Explore my Garmin activity visualizations.
Translate the question before choosing the chart
An activity record is an observation. A useful view of training behavior requires decisions about how to group those observations. Start timestamps can become day-of-week and hour categories. Workout durations can become one-hour bins. Activity types and calorie ranges can become two sets of connected categories. Each transformation changes the question the display can answer.
That is where the course connected with my design practice. Choosing the unit of comparison is already an interface decision. A weekly total, an individual workout, and a distribution across years offer different ways to understand the same history.
Describe the visual idiom, marks, and channels
Tamara Munzner's visualization framework gives me a vocabulary for explaining these choices. A visual idiom is a pattern for representing data. Marks are its graphical elements; channels control properties such as position and color. The task explains why that representation is useful.
- Activity start times: a heatmap idiom using rectangular marks. Horizontal position encodes weekday, vertical position encodes hour, and sequential color encodes activity count. The task is to compare timing patterns across the week.
- Saturday durations: a binned heatmap with activity type on the horizontal axis, one-hour duration bins vertically, and color for count. It shows a distribution within the selected 6 a.m.–2 p.m. start-time window.
- Activity types and calorie ranges: a bipartite node-link idiom. Point marks represent the two sets of nodes; line marks connect them. Color hue distinguishes activity categories, and tooltips expose counts. The task is to explore relationships between the sets.
Different questions need different views
The start-time view covers 2022–2026 and aggregates repeated day-and-hour combinations. It makes a recurring schedule easier to see, but combines different years. A bright cell says that more activities started in that slot; it does not say whether those activities were longer or more intense.
The Saturday view narrows the question to a subset of the history. Its bins help compare duration patterns, while grouping together workouts that differ within an hour. Reading it requires keeping both the filter and the aggregation in mind. Tooltips help recover some detail without filling every cell with a label.
The bipartite graph shifts attention to connections. Its lines show which activity types occur in which calorie ranges. The current lines use a constant width, so they indicate relationships rather than their frequency; the counts are available in tooltips. That distinction is easy to lose if I describe every connection as a measure of volume.
From a notebook to a web experience
Altair lets me specify charts declaratively in Python, mapping fields to marks and encodings. It builds on Vega-Lite, which describes the visualization in a portable JSON specification. The published project uses Vega-Embed to render those specifications as SVG inside a Next.js and React site.
Python and Jupyter provide the analysis workspace. Altair and Vega-Lite carry the visual specification. Vega-Embed brings the result into the browser, where someone can inspect values through tooltips. This connects the analytical work to a product surface without making the reader open a notebook.
What this changed in my design practice
The most useful outcome was learning to explain a chart as a set of decisions: what data it represents, what question it supports, and what its encodings make easy or difficult to see. That is a stronger basis for critique than whether a chart feels visually impressive.
My own activity history made those tradeoffs tangible. I could recognize a routine and then ask how the display constructed it. The same habit applies to product analytics: understand the transformation, read the encoding, and keep the question close to the evidence.