In-Class Group Exercise

Form a team of four or more. Pick any dataset from Kaggle, decide what dashboard a real business would build on it, then build it in Streamlit, deploy it, and justify your choices in writing.

You already know how to build and deploy an app from the Data App Tutorial and the Data App Lab. This exercise is about the decisions behind the code, not the code itself. Anyone can put ten charts on a page; the hard part is deciding which two deserve to be there, what goes at the top and what goes at the bottom, who will look at them, and how fresh the numbers need to be. On a dashboard, more is not better: every extra chart makes the important ones harder to find. You are graded mostly on those decisions and justifications, not on how much the app does.

Step 1 — Pick a Dataset and a Decision-Maker

Choose a dataset from Kaggle that has a believable business behind it: sales, orders, customers, bookings, support tickets, deliveries, marketing campaigns, inventory, prices. A few rules:

• Tabular and small. One CSV under about 25 MB keeps GitHub and Streamlit Cloud happy. If the file is bigger, sample or aggregate it in a notebook first and commit the smaller file — and say that you did.
• Not a teaching toy. No Iris, Titanic, or the world cities and California housing data from this lecture.
• Read the dataset page. Know where the data came from, what period it covers, what one row is, and whether it is real or synthetic.

Then name the one person the dashboard is for — a role, not "everyone": a store manager, a hotel revenue manager, a marketing lead, a hospital operations director. A dashboard built for everyone ends up useful to no one.

Step 2 — Justify the Dashboard

A dashboard is not always the answer. A one-off question ("which region grew fastest last year?") is better served by a single analysis or a slide. A dashboard earns its place when the same person needs to look at the same questions again and again and act on what they see.

Answer these as a team and write the answers down:

1. Who looks at it, and how often?
2. What decision does it support? Complete this sentence: "If [person] sees [something] on this dashboard, they will [do something]." If you cannot finish it, you do not have a dashboard yet.
3. What do they do today without it — and what does that cost them in time, money, or mistakes?
4. Why a dashboard rather than a weekly email, a report, or an alert?

Step 3 — Decide What Matters

Do a quick EDA in a notebook with Pandas and Matplotlib, the way you did in Assignment 1: shape, data types, missing values, distributions, and the relationships that look interesting. Then use what you found, together with your understanding of the business, to decide what goes on the dashboard:

• At most three headline numbers — the KPIs your decision-maker should see within five seconds of opening the page. Show them with st.metric, side by side in st.columns.
• One or two supporting charts that explain why a headline number moved — a trend over time, a breakdown by segment, a comparison against a target.
• Only the filters the person actually needs — if a store manager only ever cares about their own store, a store selector matters more than ten sliders.

Just as important, write down:

• Two things you chose not to show, and why. Something that looked interesting in the EDA but would not change any decision is a good candidate.
• Anything in the data that could mislead the viewer — missing months, outliers, a column whose meaning you had to guess, a metric that is easy to misread. Say how the dashboard handles it, even if the answer is a caption that warns the reader.

Ask yourselves of every element: if this disappeared, would the decision-maker notice? If not, cut it.

Then decide the order. People read a dashboard from top to bottom, and many never scroll. So the order of the page should match the order of importance:

• Top: the headline numbers, the answer to "is anything wrong right now?"
• Middle: the charts that explain why a number moved.
• Bottom: detail for someone who wants to dig in, such as a table of the underlying rows. Leave it out if no one will use it.

Sketch the page on paper, top to bottom, before you write any code, and be ready to say why each element sits where it does.

Step 4 — Decide the Refresh Frequency

A Kaggle CSV is a frozen snapshot. In the real business behind it, new data arrives all the time. Decide, for the real-world version of your dashboard:

1. How often should the data be refreshed — real time, hourly, daily, weekly, monthly? Base it on how fast the underlying numbers actually change and how fast the person can act on them. Refreshing every minute is pointless if the decision is made once a month, and expensive if the data has to be pulled from several systems.
2. How often should someone review it, and is that the same thing? Sales data might refresh nightly while the manager reviews it every Monday morning.
3. What should be tracked over time, and what should trigger action? Pick one metric and say what change or threshold should make someone pick up the phone.
4. What does stale data cost? What goes wrong if the dashboard is a day — or a week — out of date?

For calibration, here is a weak answer and a strong one about a retail inventory dashboard:

• Weak: "Daily, because the data changes every day."
• Strong: "Sales refresh nightly from the point-of-sale system; the store manager reviews the dashboard every Monday when placing restock orders. Real-time refresh would add cost without changing any decision, because orders are only placed weekly. The one exception is stock on hand for the top 20 products — when it falls below 3 days of average sales, the manager needs to know the same day, so that becomes an alert, not a dashboard check."

Because your data does not update, put a line on the dashboard stating the data period (for example, Data: Jan 2019 – Dec 2021, Kaggle snapshot) and the refresh frequency you would use in production.

Step 5 — Build and Deploy

Keep the app small. A clean page that does what you planned in Steps 3 and 4 beats a crowded one. Your app must have:

1. A title with your team name.
2. A one-line caption saying who the dashboard is for and what decision it supports.
3. A row of headline metrics with st.metric.
4. At least one supporting chart.
5. At least one filter your decision-maker would actually use.
6. The data period and intended refresh frequency line from Step 4.

Create a new project with uv init as in the tutorial, publish it to a public GitHub repository under your own account, and deploy it to Streamlit Cloud following Deploy the App. Remember to set the Python version to 3.14 under Advanced settings.

Add a README.md to the repository with your written answers to Steps 1 to 4 — the dataset and its link, the decision-maker, the justification, what you showed and cut and why, and the refresh decision. This is the most important file in the repository.

Submit

You work through the exercise as a team, but everyone submits individually on Canvas. You can build on your team's dataset or choose a different Kaggle dataset you like better. Either way, the app, the repository, and the README.md must be your own.

Submit:

• The deployed app URL
• The GitHub repository URL, with the README.md from Step 5