search

Project: Interactive & Data-Driven User Interfaces

Table of Contents:

hashtag
Overview

It's time for your first paired project week! For this project, you and a partner will build an application that interacts with a third-party API. You will fetch data, render the fetched data to the DOM, and then fetch some more data! In the end, you will have a deployed interactive application that connects with a web API.

The main technical goal of your app is to send two fetches and render the fetched data:

  1. First, fetch a collection of resources (GET a set of users, a set of pictures, a set of authors) and render all of those resources.

  2. Fetch more details about a single one of those resources (GET details about a single user, a single picture, a single author, etc…) when the user interacts with the page.

By building this project, you will demonstrate the following technical skills:

  • Structuring HTML with semantic elements

  • CSS layout with Flexbox and Grid

  • Media Query Responsiveness

  • JavaScript form handling

  • Modular Code with ES Modules

  • Event handling and event delegation

Additionally, you will:

  • Develop teamwork skills including communication, problem-solving, compromise, and task management

  • Strengthen your Git workflow fundamentals, managing branches, navigating merge conflicts, and maintaining a repository

  • Practice Agile methodologies by managing a scrum board and by performing daily stand-up and stand-down

  • Deploy a project

  • Practice your technical communication through a presentation

hashtag
Deliverables

Unlike your solo projects where the project itself was the main deliverable, for a portfolio-level project, you will be required to do a bit more. The deliverables below will help keep you and your partner organized and will help keep your Engineering Manager (your instructor) informed on your progress. In the end, all of these deliverables will serve as valuable artifacts that document your work.

Deliverable Resources

Expand each below to see details and examples.

chevron-rightA Deployed Projecthashtag
chevron-rightA Project Spec Sheethashtag
chevron-rightA GitHub Organization and Scrum Boardhashtag
chevron-rightA Professional READMEhashtag

Your README.md should be polished enough that a new engineer can understand and run your project without asking questions.

Example: We Cooked Repository READMEarrow-up-right

At minimum, include:

  • Project title and one-paragraph summary

  • Live deployed link

  • Team members

  • API used (name + endpoints)

  • Features section

    • List your 2 MVP features

    • List your stretch feature(s)

  • Setup instructions

    • npm install

    • npm run dev

  • Tech stack (HTML, CSS, JavaScript, Vite, etc.)

  • Screenshots or GIFs

  • Known limitations or future improvements

Use the same professional writing standards we expect in all artifacts:

  • Clear section headers

  • Correct spelling/grammar

  • Consistent formatting

  • No placeholder text

chevron-rightAI Usage Document (Required)hashtag

Generative AI tools are a required part of this project workflow, but you must be able to explain every line of code you submit.

Make a copy of this AI Usage Documentarrow-up-right and track your usage.

For each meaningful AI interaction, you are required to document:

  1. What you asked for (your prompt)

  2. What you received (the AI response)

  3. What you changed and why

  4. How the final code works (in your own words)

Add a link to your AI Usage Document in your README.md, for example:

chevron-rightA Presentation + Walkthrough Demo Videohashtag

  • The presentation is your "elevator pitch" to tell your audience about the project, how you built it, and what you learned through the process.

  • Examples:

hashtag
Stretch Features: localStorage + AI

Use AI to help you learn and implement localStorage for a real user-facing feature in your app.

Your localStorage stretch feature should:

  • Store user preferences or user-generated state in the browser

  • Persist after page refresh

  • Be loaded on page start and reflected in the UI

  • Include a clear way for users to update the stored value

Feature ideas:

  • Save the most recently selected item and re-render it on reload

  • Save filter/search form values so they persist on refresh

  • Save a favorites list of fetched items

  • Save a theme preference (light/dark) or display settings

Suggested AI workflow:

  1. Ask AI: "How does localStorage work in JavaScript, and when should I use it?"

  2. Ask AI: "Help me implement <your feature> with localStorage in a Vite app."

  3. Ask AI to review your implementation for edge cases:

    • Missing keys

    • Invalid JSON

    • Clearing stale data

  4. Refactor the code to match your project structure and naming conventions.

  5. Document the full interaction in your AI Usage Document.

Quality bar for this stretch:

  • localStorage reads/writes are wrapped in helper functions

  • JSON parsing/stringifying is handled safely

  • UI still works when localStorage is empty

  • The feature is demonstrated in your walkthrough video

hashtag
Milestones

As you work on this project, don't set your sights on the fully completed project from the jump. Give yourself smaller goals that you can reach each day and focus on one goal at a time. As long as your goals build on each other, you will eventually reach your final destination.

For this Art Viewer project, you can see the progress made on each day.

Note: no need to create a new repo for each day - this is just done this way for demonstration purposes.

Eventually, you will need to develop the skill of planning out your objectives. However, for this project we've laid out some daily milestones that you can strive for with bare minimum requirements, ideal progress, and stretch goals. Remember: a feature isn't "done" until it's been reviewed and merged to main via a PR.

  • Bare Minimum:

  • Ideal:

  • Stretch:

  • Note: If you have not submitted your proposal and are undecided about your API by this deadline, you will be assigned an API and product spec sheet by your Engineering Manager.

hashtag
Setup Steps

hashtag
GitHub Organization & Scrum Board

First, we will create the GitHub organization and Scrum Board that will enable you and your partner to collaborate on the project.

  1. Create a new GitHub organization for your team. Only one person needs to do this. They will provide their email for verification and then invite their partner as a collaborator.

  2. Copy the Scrum Board templatearrow-up-right.

    1. Make your organization the Owner

    2. Make sure to check the box that says "Draft issues will be copied if selected".

    3. Remove "[COPY]" from the project name.

    Make a copy of the scrum board

  3. Then, you can get started assigning tickets! We recommend completing the Project Setup and Assign Tasks tickets as a team before assigning individual tickets. When a ticket is assigned, move it to the "In progress" column.

    Assigning tickets

hashtag
Vite Project + Project Repo

Next, we will create the Vite Project that will serve as the starting point for your project.

  1. Both partners should open VS Code and cd into the directory where they plan on working.

  2. One person in your group should run npm create vite@latest to create the project starter code

    • Remove any unnecessary code provided by Vite, but keep the index.html, styles.css, and main.js files.

    • Create additional module files such as src/dom-helpers.js and src/fetch-helpers.js.

  3. Make a new repository owned by your GitHub organization.

    • It should have NOTHING in it.

    • The name should be mod-4-project (you can change it later).

    • Make sure it is public.

  4. It will then provide instructions to turn your existing Vite project into a repo and push to your newly created repo. It will tell you to run these commands:

hashtag
Product Spec Sheet

Before you begin coding, you must align as a team on your project vision by making a Product Spec Sheet.

  1. Make a copy of the Templatearrow-up-right

  2. Update your Share settings to "Anyone with the link > Commenter"

  3. Post your team's Product Spec Sheet on Canvas.

Here is an example of the Art Viewer Product Spec Sheetarrow-up-right

Completing this is your first deliverable!

hashtag
Deployment with gh-pages

As you write your code, your project is considered "in development". When we are ready to share the project with the world, we will deploy it. The main differences between a project in development and a deployed project are file storage, access, and uptime.

In development you use a development server (like Vite) that runs on localhost:

  • File Storage: The files are stored on your computer.

  • Access: Only you can see it. If you send the link http://localhost:5173 to a friend, it won't work for them.

  • Uptime: When your computer turns off, the server stops running as well.

Deployment is the act of moving your finished work to a publicly accessible server which is just a computer whose resources you can access over a network. We'll be deploying our code onto GitHub's servers:

  • File Storage: The files are stored on one of GitHub's servers.

  • Access: Anyone with the URL can see the project and access the files.

  • Uptime: GitHub keeps the servers running. Even if you turn your computer off, your website stays online because its living on their hardware, not yours.

circle-info

A deployment server often refers to both the computer hardware that is "hosting" our files and the server-side application running on it is programmed to wait for incoming requests and sends those files to the user requesting them ("the client").

GitHub Pages is known as a static web server which means that it just stores our HTML, CSS, and JS files and serves them directly to the user. Every user will get the exact same website and user experience.

In the upcoming Backend unit, you will learn how to create your own dynamic server-side applications, enabling you customize what the client receives based on who they are, what resources they've requested, etc. In other words, you will be able to create your own APIs.

To deploy your project with GitHub pages, follow these steps:

Step 1: Create and Update vite.config.js

Create a file called vite.config.js at the root of your repository and add the code below. If you've changed the name of your repository from mod-4-project to something else, make sure to update this file.

Step 2: Install gh-pages

Install the gh-pages package as a dev dependency. It makes it incredibly easy to deploy.

Step 3: Add predeploy and deploy scripts to package.json

Add the following "predeploy" and "deploy" scripts to your package.json file:

Step 4: Add the homepage to package.json

GitHub pages will serve your website at https://{github-organization}.github.io/{repo-name}/.

Add the complete website URL by adding a "homepage" to your package.json. Make sure to update the organization name (keep .github.io) and the repo name

Step 5: Run Deploy

Now, deploy your project! Run the command:

And you’re done!

Step 6: GitHub Configuration

Lastly, Go to your GitHub repository and navigate to Settings -> Pages (left sidebar). Select source as “Deploy from branch” and branch as “gh-pages”.

GitHub Pages Settings

Wait for a few minutes and soon, your site will be live!

hashtag
Git Workflow for Paired Projects

This is likely your first time collaborating on code with another person using Git. The workflow below is intentionally simple. Follow it closely and you'll avoid most of the headaches that come from working in the same codebase.

hashtag
The Golden Rule

Never push directly to main. All work happens on branches. Code gets into main through Pull Requests (PRs) that your partner reviews.

hashtag
Branch Strategy

Use feature branches — short-lived branches where each branch corresponds to one ticket on your scrum board.

Branch naming convention: feature/short-description

Examples:

  • feature/fetch-all-items

  • feature/render-item-list

  • feature/single-item-section

  • feature/form-html

  • feature/responsive-layout

hashtag
The Workflow (Repeat for Every Ticket)

Then start the next ticket from step 1.

hashtag
Dividing the Work into Tickets

The key to working in parallel is to split work by feature, not by file. Each ticket should be a vertical slice — the HTML, CSS, JS, and fetch logic needed for one piece of functionality.

Here is a suggested way to break the project into tickets. The ticket numbers suggest a rough order, but tickets at the same level can be worked on in parallel by different partners.

Setup (do together, Day 1) — this is the one time you push directly to main

  1. Project Setup — Create GitHub Organization, repo, and clone locally. Set up Vite project with initial file structure (index.html, styles.css, app.js)

  2. Assign Tickets — Assign tickets in the backlog to each team member.

Partner A: Fetch & Render All Items:

  1. Collection section HTML & CSS — Create a <section> for displaying the collection of data with a h2 and a ul to be filled using JavaScript

  2. Fetch all items — Write a fetch function that GETs the collection endpoint and logs the data. Include async/await, try/catch, response.ok check.

  3. Render item list — Write a function that takes the fetched array and renders <li> elements inside the <ul> in the collection <section>. Use createElement

  4. Responsive grid layout — Style the item list using CSS Flexbox or Grid. Add a media query so items stack on mobile and sit side-by-side on desktop.

Partner B: Fetch & Render One Item:

  1. Single item section HTML + CSS — Create the <section> for displaying a single fetched item with its <h2> and placeholder content.

  2. Fetch single item — Write a fetch function that GETs the "single item" endpoint and logs the data. Include async/await, try/catch, response.ok check.

  3. Fetch on Click — Add an event listener (using event delegation on the <ul>) that fetches details for one item and renders them in the single-item section.

Either partner (after earlier tickets merge):

  1. Build the form HTML — Create the <form> with labels, inputs, and name attributes for each input.

  2. Form event handling — Add a submit event listener that prevents default, reads input values, clears the form, and triggers a fetch (or filters results).

  3. Connect form to fetch — Wire up the form so submitting it triggers the collection fetch with the form's input value (e.g. a search query or filter).

  4. Polish and accessibility pass — Confirm semantic HTML, single <h1>, single <main>, <title> in head, no divs replacing semantic elements.

  5. README and deployment — Write the professional README, link AI Usage Doc, final deploy.

hashtag
Handling Merge Conflicts

Merge conflicts happen when both partners edit the same lines in the same file. To minimize them:

  • Communicate constantly. Tell your partner what file you're working in.

  • Keep branches short-lived. Merge PRs quickly (within hours, not days). The longer a branch lives, the more likely it conflicts with main.

  • Pull main before starting a new branch. This ensures you're always building on the latest code.

When a conflict does happen:

  1. Pull main into your feature branch: git merge main

  2. Git will mark the conflicting lines in the file. Open the file and look for the <<<<<<<, =======, >>>>>>> markers.

  3. Talk to your partner about which version to keep (or how to combine them).

  4. Edit the file to resolve the conflict, removing the markers.

  5. git add . and git commit to complete the merge.

  6. Push your branch and continue with the PR.

hashtag
Daily Routine

Time
Activity

Start of day

Stand-up: What did you do yesterday? What are you doing today? Any blockers?

During the day

Work on your ticket. Commit often. Push and open a PR when done. Review your partner's PRs promptly.

End of day

Stand-down: What got done? What's next? Make sure all open PRs are merged so tomorrow starts clean.

hashtag
Common Mistakes to Avoid

  • Working on main directly. You'll overwrite each other's work.

  • Giant branches that touch every file. Keep tickets small and focused.

  • Not pulling before branching. You'll end up working on stale code.

  • Ignoring your partner's PR. Review quickly — your partner is blocked until you do.

  • Both editing index.html at the same time. Coordinate who's touching shared files, or accept that you'll need to resolve a merge conflict.

hashtag
Project Grading

We care deeply about the quality of the code that is produced at Marcy. Even if your application works as described, was it created following best practices? Did you effectively use all of the skills from the module? Were you able to learn and grow from this project-building process?

To ensure that your project meets Marcy's standards of excellence, your project will be assessed on the following criteria (38 points total):

hashtag
Fetching Requirements (8 points)

hashtag
User Interface: Structure and Accessibility (12 points)

hashtag
General (9 points)

hashtag
Form Requirements (9 points)

hashtag
Tips for Success

hashtag
Choosing an Easy API to Work With

Choose an API from this list of free APIs as they are all free and, importantly, do not require an API key.

If you are able to find another API that is free and does not require an API key, you are free to use it, but do not waste time on this search nor trying to get a tricky API to work (don't use the Spotify API. Just don't. Please.)

hashtag
Focus on demonstrating your learning, not building something unique.

One of the easiest ways to get off track is by worrying about creating a unique project

Remember:

  • Student projects are meant for learning, demonstrating your learning, and practicing talking about your technical work

  • Student projects are not meant to be unique.

  • You're not creating a new app that addresses a gap in the market.

  • You aren't deploying this app for the purpose of having real users.

hashtag
Make Decisions Quickly

You may have a great idea that you really want to implement, but remember, you are working as a team and you only have a week. Time is not on your side and the more time you waste disagreeing with your partner about what features to implement or what API to use, the less time you'll have to actually build the thing.

hashtag
Plan and Delegate!!

  • Use branches and make PRs

  • Use your scrum board

  • Assign tasks

  • Don't do duplicate work

hashtag
Meet on your own time

Be in alignment with your teammate outside of the scheduled meetings with your Engineering Manager.

hashtag
Test your API!

Actually write a fetch to make sure that the API works before choosing it for your proposal

Previous7. Handling FormsNextCase Study: Recipe Browser

Last updated