Common Student Struggles

This document identifies 20 recurring difficulties students encounter throughout the course, along with concrete intervention strategies. These struggles are drawn from the most common failure modes in data visualization education. Anticipating them allows you to address issues proactively rather than reactively.

1. The matplotlib Learning Curve

Struggle: Students find matplotlib's API overwhelming. The distinction between pyplot and the object-oriented API confuses them, and they mix the two approaches in the same script, producing unpredictable behavior.

Intervention: Enforce the object-oriented API from the first matplotlib session. Provide a boilerplate template (fig, ax = plt.subplots()) and require students to use it for every assignment. Ban plt.plot() in favor of ax.plot() from day one. The initial friction pays off within two weeks.

2. Color Choice Paralysis

Struggle: After learning about perceptual uniformity, color blindness, and color theory in Chapter 3, students become afraid to choose any color palette. They spend excessive time on palette selection and sometimes default to grayscale to avoid making a mistake.

Intervention: Provide a short list of approved safe defaults: viridis or cividis for sequential data, RdBu or coolwarm for diverging data, and Set2 or tab10 for qualitative data. Tell students to use these unless they have a specific reason to deviate. Reduce the decision space.

3. Skipping the Sketch Step

Struggle: Students jump directly from data to code, skipping the paper-and-pencil sketch that Chapter 33's workflow recommends. This leads to hours of code iteration that a 10-minute sketch would have prevented.

Intervention: Make sketching a graded deliverable for the first three assignments. Require students to submit a photo of their hand-drawn sketch alongside the final code. Once the habit is established, they will continue voluntarily.

4. Fear of Critique

Struggle: Students take design feedback personally. When told their chart is misleading or cluttered, they hear criticism of their abilities rather than constructive guidance about a specific artifact.

Intervention: Establish a critique framework early: feedback targets the chart, not the person. Use structured critique forms with specific categories (color, layout, annotation, data-ink ratio) rather than open-ended comments. Model constructive critique yourself by critiquing published charts before critiquing student work.

5. Default Acceptance

Struggle: Students accept every library default without question. They do not change the figure size, the font size, the color cycle, or the axis limits because "that is what matplotlib gave me."

Intervention: In early assignments, require students to justify every default they keep. A one-sentence annotation per chart --- "I kept the default x-axis range because it spans the full dataset" --- forces conscious evaluation. After a few weeks, the habit of questioning defaults becomes automatic.

6. Overplotting Without Awareness

Struggle: When plotting large datasets, students produce scatter plots where thousands of overlapping points obscure all structure. They do not recognize that the chart is hiding information.

Intervention: Show the same data plotted naively vs. with alpha transparency, jitter, hexbin, or density contours. Make overplotting identification a specific checklist item in the design critique rubric. Teach students to check the point count before plotting and to choose an appropriate strategy for their data size.

7. Confusing Chart Types

Struggle: Students confuse bar charts (categorical comparison) with histograms (distributional shape). They call plt.bar() when they mean plt.hist(), or they produce histograms of categorical data.

Intervention: Teach the rule explicitly: bar charts have categorical axes, histograms have continuous axes with bins. In early exercises, present datasets and ask students to classify whether the visualization question calls for a bar chart or a histogram before writing any code.

8. Inconsistent Scales in Small Multiples

Struggle: Students produce small multiple panels with different axis ranges, making cross-panel comparison impossible --- the very thing small multiples are designed for.

Intervention: Teach sharey=True and sharex=True as mandatory defaults for small multiples. Show a side-by-side comparison: inconsistent scales vs. shared scales on the same small multiples figure. The distortion in the inconsistent version is immediately obvious.

9. Over-Annotation

Struggle: After learning annotation techniques in Chapter 7, some students label every data point, every bar, and every axis tick. The chart becomes an unreadable wall of text.

Intervention: Introduce the "annotate the insight" rule: if the purpose of the chart is to show that Q3 was an outlier, annotate Q3 and nothing else. Count the annotations in the chart. If there are more than 5 on a standard figure, the student should justify each one.

10. Pie Chart Overuse

Struggle: Students default to pie charts for any part-to-whole relationship, even when there are 10+ categories or when the comparison between slices is the primary question.

Intervention: Establish a class policy: pie charts are permitted only when there are 4 or fewer categories and the primary question is part-to-whole. For everything else, use a sorted horizontal bar chart. Show side-by-side comparisons to make the readability difference clear.

11. Seaborn Figure-Level vs. Axes-Level Confusion

Struggle: Students do not understand why sns.histplot(ax=ax) works but sns.displot(ax=ax) does not. The figure-level/axes-level distinction is a major source of confusion.

Intervention: Draw a clear diagram: figure-level functions create their own Figure and Axes; axes-level functions draw onto an existing Axes. Provide a reference table listing which functions are figure-level and which are axes-level. Use this table in class and post it on the course website.

12. Ignoring Accessibility

Struggle: Students choose color palettes without considering color vision deficiency, use low-contrast text, or rely solely on color to distinguish categories.

Intervention: Make accessibility a graded rubric item on every assignment. Require students to run their charts through a color blindness simulator at least once during the course. Teach redundant encoding: if categories are distinguished by color, also distinguish them by shape, line style, or direct labeling.

13. Dashboard Feature Creep

Struggle: When building Streamlit or Dash dashboards, students add every possible widget, chart, and interaction. The result is a cluttered application that answers no question clearly.

Intervention: Require students to write a one-sentence purpose statement for their dashboard before writing any code: "This dashboard helps [audience] answer [question] by showing [key metrics]." Every widget and chart must trace back to that purpose. If it does not support the purpose, remove it.

14. Neglecting Figure Size and Resolution

Struggle: Students submit charts at matplotlib's default 6.4x4.8 inches with 100 DPI, producing small, blurry figures when printed or projected. Text is unreadable at presentation scale.

Intervention: Provide recommended figure sizes for common output contexts: slides (10x6 or 12x7 inches), print (7x5 inches at 300 DPI), web/notebook (8x5 inches at 150 DPI). Make figure size specification a required line in every script.

15. Narrative-Free Presentations

Struggle: Students present their capstone projects as a sequence of charts without narrative structure. They describe what each chart shows but never state why it matters or what the audience should conclude.

Intervention: Require students to outline their presentation narrative before making slides. Each chart must be accompanied by a one-sentence takeaway that would appear as the slide title. Practice the "so what?" test: after showing each chart, the student must answer "so what does this mean for [the audience]?"

16. Copy-Paste Code Without Understanding

Struggle: Students copy code from the textbook or Stack Overflow without understanding how it works. When the code needs modification, they cannot adapt it because they do not understand the underlying API.

Intervention: On early assignments, require students to add inline comments explaining each line of their plotting code. Ask them to predict what will happen if they change a specific parameter before running the modified code. Build understanding before fluency.

17. Mixing Exploratory and Explanatory Visualization

Struggle: Students submit exploratory analysis charts (pair plots, raw distributions, debugging outputs) as their final deliverable. They do not distinguish between charts they made for themselves and charts they make for an audience.

Intervention: Teach the exploratory/explanatory distinction explicitly in Week 1 and reinforce it throughout the course. Exploratory charts are rough, fast, and numerous. Explanatory charts are polished, few, and annotated. The capstone should contain only explanatory charts, with exploratory work documented separately.

18. Inconsistent Styling Across a Report

Struggle: When students produce multi-chart reports or dashboards, each chart uses different colors, fonts, and styling. The result looks like a patchwork rather than a cohesive document.

Intervention: Require students to define a style dictionary or style sheet at the top of their notebook and apply it to every chart. Grade consistency as a rubric item. The theming chapter (Ch 32) addresses this directly, but the habit should start earlier.

19. Date and Time Formatting on Axes

Struggle: Matplotlib's date formatting produces overlapping labels, ugly defaults, and timezone confusion. Students spend disproportionate time fighting with date axes.

Intervention: Provide a ready-made date formatting snippet that handles the common cases (yearly, monthly, daily). Teach mdates.DateFormatter and mdates.AutoDateLocator as the standard solution. For the climate project specifically, provide a pre-formatted date column.

20. Premature Optimization of Aesthetics

Struggle: Students spend hours perfecting the appearance of a chart that answers the wrong question. They polish a chart type that is inappropriate for their data because they already invested time in styling it.

Intervention: Enforce a two-pass workflow: first pass gets the right chart type with default styling, second pass polishes the appearance. Require students to submit their first-pass chart alongside the final version. If the chart type changed between passes, the two-pass process worked. If the chart type was wrong from the start and never corrected, the student was optimizing prematurely.