Live Instruction · JavaScript · OOP · Masterschool
Dinosaur Infographic —
Project Intro & OOP Walkthrough
A live project kickoff session for Masterschool students starting the Udacity Dinosaur Infographic assignment — demoing the finished app, walking the rubric, and mapping the build strategy to OOP concepts covered in the curriculum.
The Session
Start with the finished product, then work backward
The Dinosaur Infographic project is one of the first real-world OOP assignments in the Udacity curriculum — it requires students to build constructor functions or classes, load external JSON data, manipulate the DOM, handle form input, and implement comparison logic across an array of objects, all in one project.
Rather than diving straight into the rubric, the session opened by demoing a completed version of the app in the browser — showing students what they were building before explaining how to build it. Seeing the form input, the tile layout, and the comparison results (you weigh less than seven dinosaurs) gave the abstract requirements a concrete target.
From there the session walked the rubric, the starter code structure, the two approaches to loading JSON data, and the OOP patterns students could use — connecting each requirement back to concepts they'd already covered in the program.
9
tiles · 7 dinos, 1 human, 1 bird
Masterschool Coding Bootcamp
JavaScript · OOP · Udacity Curriculum
International cohort · Group session · Project intro format
The Content
What the session covered
From demoing the finished app to walking the starter code — a complete orientation before students wrote a single line.
Demo First, Rubric Second
Opened by showing a completed version of the Dinosaur Infographic in the browser — the form, the 3×3 tile grid, and the comparison outputs (weight, height, diet). Seeing the end result before reading the rubric gave students a concrete mental model for every requirement that followed.
Two Methods to Load JSON
Covered both approaches: converting the .json file to a .js module and using ES6 import, or requesting the file asynchronously with the Fetch API. Fetch was flagged as a preview of async JavaScript coming later in the program — students could use import now and revisit fetch once they got there.
Constructor Functions vs. ES6 Classes
Explained that both produce the same result — constructor functions with .prototype and ES6 class syntax are two ways to write the same thing. Recommended constructor functions or classes over object literals for this project, since the rubric requires at least nine object instances to be created.
IIFE and the Revealing Module Pattern
Connected the project requirement to use an IIFE back to the Revealing Module Pattern covered earlier in the program — using an immediately invoked function expression to encapsulate DOM references and expose only what the submit handler needs. Mapped the pattern to the comparison logic and tile generation.
Three Comparison Methods
Walked through the three required methods: comparing user weight to each dinosaur, comparing height, and comparing diet. Each method loops through the dino array, runs a conditional, increments a counter, and returns a string — simple conditionals, but the rubric expects at least three of them.
Tile Generation and DOM Appending
Explained how to generate each tile dynamically in JavaScript — creating an element, setting innerHTML with species name, image, and comparison fact, then appending to the grid. Noted that image filenames match species names lowercased, so .toLowerCase() is needed when constructing the image src.
Rubric Checklist Walkthrough
Walked through each rubric item: no console errors on submit, form hidden after submit, nine tiles rendered, facts changing on refresh, at least one constructor or class, at least three comparison methods, human object populated from form data, and the pigeon always appearing last.
JSHint as a Code Quality Tool
Introduced jshint.com as a linter students could paste their code into for feedback before submission — catching issues the console might not surface directly. Framed it as a complement to console.log and the debugger, not a replacement.
Version Control with GitHub
Encouraged students to use GitHub for this project — clone the starter repo, work locally, push to a new repository on their account when done. Clarified the difference between cloning (copying to your machine) and forking (contributing back to the original), since students often confuse the two.
Session Recording
Watch the Session
Live project intro — demoing the finished app, walking the rubric, and mapping OOP patterns to project requirements.
Reflection
A demo is worth a thousand requirement descriptions
Starting with a demo rather than the rubric changes the orientation of the session. Students move from "what does this require?" to "how do I build what I just saw?" — which is a more concrete starting point, especially for a project that combines several concepts at once.
The two JSON loading approaches came up early because it's a common first blocker. Students who get stuck importing the data before writing any logic can spend hours on setup. Addressing it upfront — with both options and a clear recommendation for which to use given their current knowledge — removes that blocker before it happens.
Connecting the IIFE requirement back to the Revealing Module Pattern the cohort had already covered is an example of the kind of bridge that makes requirements feel familiar rather than arbitrary. Students had already built something with this pattern — the project was asking them to use it again, in a new context.
3
required comparison methods
Weight · Height · Diet
Constructor Functions · IIFE · DOM
JSON loading · GitHub · JSHint
Keep Exploring
More from this project
Interested in working together?
I'm open to remote opportunities in technical learning experience design, developer education, and customer enablement.