INSTRUCTIONS
This chart shows the blood glucose levels of 16 patients throughout the 5th day of a study.
If you click on one patient using the legend on the right, you can see the food log for that patient. Try selecting
patient 1. Notice how when they ate a high-carb meal at 21:00, their glucose levels spiked. This is a common pattern across all patients
You can hover over the vertical food annotation to see what they ate and the nutrients of their meal.
You can also select multiple patients, though it won't show the food log for each patient to avoid cluttering
You can also filter by gender, and reset the selection at any time.
Note: patients 7, 13, 15, and 16 don't have food logs because their food log dates are mismatched with their blood glucose tracking dates. This might have been an error in the study.
Design Rationale
Visual Encodings:
- Line Chart for Glucose Trends: We chose a multi-line chart to show glucose levels over time for each patient. This allows for easy comparison of trends and outliers across individuals.
- Color for each Patient: Each patient is assigned a unique color, making it easy to distinguish between lines. The legend reinforces this mapping and allows for interactive selection.
- Food Log Annotations: When a single patient is selected, vertical bands are overlaid on the corresponding time to indicate food log entries. This way users can easily see and compare the time a patient ate to their glucose level after they ate.
- Food Log Annotation Color: The annotation bands are colored on a blue-to-red gradient, with blue representing lower total carbs and red representing higher total carbs (also makes sense because blue is commonly associated with good and red is commonly associated with bad). This is so users can easily get a sense of which are high-carb and low-carb meals at a glance and intuitively.
Interactions:
- Patient Selection/Filtering: Users can click legend items to focus on specific patients, so they can more easily identify trends
- Gender Filtering: Checkbox UI so users can filter by gender and compare blood glucose levels by gender
- Reset Button: A reset button restores all selections and filters, making it easy to return to the default view.
- Hover Tooltip: Hovering over the line and/or a food annotation reveals a tooltip with the time, food(s) eaten, and nutrient breakdown.
- Carb Legend: When only one patient is selected, a color legend appears to explain the carb gradient. If not one patient is selected, this legend is irrelevant and so it doesn't show.
Alternatives Considered:
- Our initial idea was to plot all 10 days, but we figured it was too much information for the goal of our visualization. We just wanted users could get an idea of how their glucose levels would typically change throughout the day depending on their breakfast, lunch, dinner, snacks, etc. So one day is enough.
- We thought of having all the patients be in multiple charts, but this makes comparison across patients hard and takes up a lot of screen space. A single chart that you can filter is much better.
- We originally had dots to indicate food logs, but the vertical bands provide a much clearer visual signal.
- To visually encode the carb content of a food log, we tried out varying the opacity, saturation, setting a threshold (if it's below 50g it's blue, else red), but a gradient from red to blue encoding provided the most intuitive sense of "more" vs. "less" carbs.
Development Process
Motivation:
We were interested in examining how food intake drives glucose level fluctuations, so we plotted continuous glucose readings over a 24‑hour period, highlighting the timing and magnitude of post‑meal spikes. We also included a macronutrient breakdown for each meal for every patient to allow readers to identify how certain types of foods affect glucose levels.
Teamwork:
We all worked on the visualization together on the same device. This way we could instantly voice concerns/ideas for the plot.
The project took approximately 12 hours in total.
- Data cleaning and normalization: ~2 hours (handling inconsistent date/time formats was especially time consuming. We tried a lot of things before realizing that some of the dates were straight up outside the range of the study)
- Visualization and D3.js coding: ~4 hours
- Interactive features and UI polish: ~4 hours
- Testing and debugging: ~2 hours (a lot of considering what is considered "intuitive" behavior". Like if I click on a selected legend, I "intuitively" expect it to deselect. So it should deselect)
Challenges:
- Deciding "intuitive" user interaction behaviors. For example, when I've selected something and hover over something else, I expect the selected item to still be highlighted along with the hovered patient. Before this, when the user hovered over another patient, their selected patients wouldn't be highlighted anymore, which didn't seem like very intuitive behavior.
This part required a lot of back and forth discussion and sending it to other people to test and give feedback. By sending it to other people, we discover how interactions should behave so users can have an intuitive experience.
- Related to the above point, a lot of users didn't "know" you could do certain interactions. They didn't know you could hover over the food logs to get more detailed information, or filter patients by legend, for example. So we decided to put a big unmissable instructions box at the top.
- Handling the dates in the csv files took quite a long time. We were so confused why it wasn't working only to realize some of the date formats were different and the column names are also slightly different. Some dates in the food log are also straight up different from the glucose tracking dates (One patient
had their food logs a year after their study period?).
- Designing the filtering for both individual (selecting patients) and aggregate filtering (based on gender) took a lot of time to figure out. Also needed to decide what was intuitive behavior again if users used both filters at once.