Hands-On Prototype: Build a 'Where Should We Eat?' Decision Algorithm with Students
project-basedalgorithmsstudent-activities

Hands-On Prototype: Build a 'Where Should We Eat?' Decision Algorithm with Students

eequations
2026-02-09
10 min read
Advertisement

Turn decision fatigue into a hands-on lab: students build a 'Where Should We Eat?' prototype to learn preference aggregation and weighted scoring.

Stop decision fatigue — teach students to build a fair, explainable "Where Should We Eat?" app in one lab

Groups of students and family meetups often stall on a single question: where should we eat? That hesitation is a real pain point and a perfect classroom hook. In this lab, students learn preference aggregation, weighted scoring, and rapid UI prototyping by recreating Rebecca Yu’s micro-app idea as a learning exercise. The result: a compact, testable decision algorithm that teaches math, computer science, and human-centered design in one project.

Why this lab matters in 2026

By early 2026, the rise of micro apps and AI-assisted "vibe coding" has made it practical for non-developers — and for students — to build small, useful applications in days. These trends make authentic, project-based learning easier and more relevant. Rather than asking "what is preference aggregation?", students implement it and see how different choices change outcomes. This hands-on experience aligns with computing and math standards that emphasize data, algorithms, and human interaction.

Learning outcomes

  • Understand and implement a weighted scoring algorithm for group choices.
  • Compare common voting systems (plurality, Borda, weighted scoring, Condorcet) and measure their trade-offs.
  • Design a lightweight UI prototype that collects preferences and shows explanations for the recommendation.
  • Test and analyze outcomes with datasets and unit-style practice problems.

Classroom setup: materials and timeframe

This lab is designed for a 2–3 class session sequence (90–180 minutes total) but adapts to shorter modules.

  • Devices: laptops or tablets with a browser (no heavy backend required)
  • Tools: plain HTML/CSS/JS or a low-code environment (Glitch, CodePen, JSFiddle). Optionally, a lightweight spreadsheet.
  • Dataset: a short list of 8–12 local restaurants, each with attributes (price, cuisine, distance, vibe). You can use anonymized sample data to protect privacy.
  • Optional: LLM/code copilot to help scaffold prototype code (teach prompts and validation).

Step 1 — Design the decision model (20–30 minutes)

Begin by modeling how the app should make recommendations. Introduce students to the concept of features and weights.

Define features

Each restaurant should be represented by a small vector of normalized features. Example features:

  • Price: 1 (cheap) – 5 (expensive)
  • Cuisine match: 0–1 fraction for how well a cuisine matches group preferences
  • Distance: minutes from the meeting point (normalized)
  • Vibe: 1–5 subjective rating
  • Dietary options: count of compatible options (normalized)

Weighted scoring: the heart of the algorithm

Students learn to compute a score for each restaurant as a weighted sum of normalized features. Formally:

Score(r) = w1 * f1(r) + w2 * f2(r) + ... + wn * fn(r)

Where f_i are normalized feature values and w_i are weights that reflect priority (sum to 1 for interpretability).

Activity: choose weights

Split the class into groups and ask each group to choose different weight vectors reflecting different group values (e.g., "cheap-first", "close-first", "vegan-friendly"). Students should justify their choices in one paragraph.

Step 2 — Preference aggregation from participants (20 minutes)

Collect individual preferences from classmates. Use one of these input methods:

  • Ranked list of top 5 restaurants
  • Ratings (1–5) per restaurant
  • Feature adjustments (each person sets personal weights)

Teach how to aggregate personal weights into a group weight vector using mean or median; show how extremes can be smoothed.

Convert ratings to feature contributions

When students submit ratings, these map onto features. For example, a student's rating for "vibe" can be averaged with other students' vibe ratings to produce the restaurant's vibe feature value.

Step 3 — Implement the scoring algorithm (30–45 minutes)

Provide a simple JavaScript implementation so students can focus on logic and UI. Below is a classroom-ready, minimal example you can paste into a code sandbox.

/* Minimal weighted scoring in JavaScript */
const restaurants = [
  { id: 1, name: 'Taco Town', price: 2, cuisineMatch: 0.8, distance: 12, vibe: 4, diet: 0.5 },
  { id: 2, name: 'Pasta Place', price: 3, cuisineMatch: 0.6, distance: 5, vibe: 5, diet: 0.7 },
  // add more
];

// Normalize a feature array to 0..1 by min-max
function normalize(arr, key) {
  const vals = arr.map(x => x[key]);
  const min = Math.min(...vals), max = Math.max(...vals);
  return arr.map(x => ({ ...x, [key]: (x[key] - min) / (max - min || 1) }));
}

// Example weight vector (sum should be 1)
const weights = { price: 0.2, cuisineMatch: 0.3, distance: 0.2, vibe: 0.2, diet: 0.1 };

let norm = normalize(restaurants, 'price');
norm = normalize(norm, 'distance');
norm = normalize(norm, 'vibe');
// cuisineMatch and diet assumed 0..1

const scored = norm.map(r => ({
  ...r,
  score: weights.price * (1 - r.price) + // lower price is better
         weights.cuisineMatch * r.cuisineMatch +
         weights.distance * (1 - r.distance) + // closer is better
         weights.vibe * r.vibe +
         weights.diet * r.diet
}));

scored.sort((a,b) => b.score - a.score);
console.log(scored);

Explain normalization choices: if higher raw numbers mean worse (like price), invert (1 - normalized) to make higher always better. Encourage students to document these decisions.

Step 4 — Compare voting systems and run experiments (30 minutes)

Now broaden the lab to compare your weighted scoring approach to standard voting systems:

  • Plurality: each voter picks one restaurant; highest votes wins.
  • Borda count: each ranked position receives points (e.g., 3,2,1) summed across voters.
  • Condorcet: pairwise comparisons to find a restaurant that beats all others head-to-head (if it exists).
  • Weighted scoring: the algorithm you implemented.

Classroom experiment

  1. Run each method on the same preference dataset.
  2. Record the top choice for each method and the score distributions.
  3. Discuss differences: Which methods favour consensus? Which let strong minorities dominate?

Use a short worksheet with 3–5 synthetic test cases (contrived ties, polarized groups, unanimous preferences) so students can practice. This supports the content pillar of practice tests and problem generators.

Step 5 — Prototype the UI (30–45 minutes)

Students should build a minimal interface where participants can:

  • Select or rank restaurants
  • Adjust weights (group or personal)
  • See the recommended restaurant and a short explanation of why it won

Minimal HTML structure

<div id="app">
  <h3>Where Should We Eat?</h3>
  <div id="prefs">-- inputs --</div>
  <button id="recommend">Recommend</button>
  <div id="result"></div>
</div>

When the student presses "Recommend", compute scores and display both the top choice and a short explanation like:

"Taco Town wins by 0.12 points because it's close, cheap, and has strong vegan options favored by 40% of the group."

Tie-breaking and explainability

Teach tie-breaking rules: prefer higher cuisine-match, then lower distance, then randomly if still tied. More importantly, require the app to output an explanation — this teaches students the value of transparency in algorithms. Explanations should map to the weighted features and show the top 3 contributors to a score.

Extension: personalization and fairness (advanced)

For advanced classes, add personalization: allow students to create profiles (e.g., dietary restriction boolean flags) and adapt scores by re-weighting features per user before aggregation. Discuss fairness concerns: Do majority preferences drown out dietary needs? How might you guarantee constraints (e.g., only recommend restaurants with at least one vegan entree)?

Algorithmic constraint enforcement

In code, enforce constraints as filters before scoring:

// Filter restaurants to only those satisfying hard constraints
const filtered = restaurants.filter(r => r.hasVegan || !groupRequiresVegan);
// Then score filtered list

Practice problems and test generators (content pillar)

Provide sets of problems to cement learning. Examples:

  • Given three voters with ranked lists, compute plurality, Borda, and weighted scores and explain discrepancies.
  • Design weights to make Restaurant A win over B and justify the choice mathematically.
  • Given normalized features and two weight vectors, calculate sensitivity: how much must a single weight change to flip the top choice?

These practice items can be auto-generated from templates. For a test generator, programmatically produce random restaurant feature tables and ask students to compute winners under multiple rules. For prompt examples and templates to feed AI scaffolds, see Briefs that Work to help students craft reliable prompts for copilots.

Assessment rubric and learning evidence

Assess students on:

  • Correctness of algorithm implementation and normalization
  • Clarity of explanation for the recommendation
  • Design rationale for weights and UI decisions
  • Reflection on fairness, sensitivity, and trade-offs

Reference these developments when discussing tools and ethics:

  • Micro apps and "vibe coding": by late 2025 and into 2026, LLM-powered copilots (in-browser AI assistants) have made single-developer web apps common. Teach students how to use these tools responsibly for scaffolding code (and how to validate the output).
  • Privacy-first edge computing: small apps increasingly run locally in the browser or on-device, which is great for student projects — no backends or user data collection required.
  • Interoperable design systems: use accessible UI components and ARIA labeling to make prototypes inclusive by default. For hardware and pop-up-ready kits to demo prototypes in a workshop setting, review field kit options like the Field Toolkit Review or the Tiny Tech field guide.
  • Algorithmic accountability: recent 2025 school district policies emphasize explainability and bias audits for decision algorithms. Have students write short audit notes as part of the deliverable.

Common pitfalls and teacher tips

  • Avoid unvalidated LLM code: if using AI helpers, require students to write tests or manually verify computations. For sandboxing and safe local agents, see guidance on building desktop LLM agents safely.
  • Normalize consistently: inconsistent normalization is the single biggest source of bugs in weighted scoring.
  • Be explicit about units (distance in minutes, price buckets) and transformations (invert where necessary).
  • Use constraints to protect minority needs (dietary restrictions) before aggregation.

Sample timeline (two 90-minute sessions)

  1. Session 1 (90 min): Hook, features, weights, preference collection, implement scoring algorithm prototype.
  2. Session 2 (90 min): UI prototyping, compare voting systems, run experiments, fairness discussion, presentations and reflections.

Classroom-ready starter kit (what to hand out)

  • CSV of 10 sample restaurants with fields: name, price, cuisine, distance, vibe, dietScore.
  • Worksheet with 5 test cases and expected answers for plurality/Borda/weighted scoring.
  • Starter HTML/JS scaffold (the snippet above) with TODOs highlighted.
  • Rubric and reflection prompts.

Actionable takeaways

  • Start small: 8–10 restaurants and 4–5 features is enough to teach core ideas.
  • Normalize inputs and document transformations clearly in the UI explanations.
  • Use pairwise and aggregate comparisons (plurality, Borda, weighted) to reveal trade-offs.
  • Prioritize explainability and hard constraint enforcement for fairness (e.g., dietary needs).
  • Leverage 2026's AI tools for scaffolding but require validation and tests from students.

Why this lab prepares students for real-world decision-making

Group choice problems are everywhere—from product design to public policy. This lab gives students a compact, practical framework to reason about preferences, quantify trade-offs, and prototype user-facing tools that must be explainable and fair. The micro-app approach mirrors industry trends: small, iterative apps solve specific human problems, and students gain experience translating human values into algorithms.

Further reading and resources (teacher's packet)

  • Short primer on voting methods and paradoxes (Borda, Condorcet, Arrow's theorem)
  • Accessibility checklist for small web apps (2026 edition)
  • Sample dataset and test generator scripts
  • Prompt examples for responsibly using AI copilots to bootstrap code

Closing challenge

Ask each group to ship a one-page README that answers: "Under what group preferences would our app fail to pick a fair choice?" This reflection closes the loop: students design, implement, test, and evaluate fairness.

Call to action

Ready to run this lab? Download the starter kit, copy the scaffold into a class CodePen, and assign the practice problem set. If you'd like a printable worksheet, automated test generator, or a turnkey classroom demo we can host for your students, sign up for the educator toolkit and get step-by-step slides and rubrics tailored to your level. Turn decision fatigue into a teaching moment — and let students build the tools that solve it. For beverage pairing ideas to include in a cultural food unit, see Pandan Pairings and other street-food pairing resources like Street Food & Cocktail Pairings. If you plan to demonstrate how short-form media can drive menu choices, check the writeup on Short-form food videos and the Data-Driven Flavor Testing playbook for classroom experiments.

Advertisement

Related Topics

#project-based#algorithms#student-activities
e

equations

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.

Advertisement
2026-02-13T14:27:34.459Z