Group Project 1: Team Website Guide

Introduction

This project asks your team of 3-4 to build a multi-page, responsive website using HTML, CSS, and JavaScript. It is the largest early-semester project in CS300, worth 175 points and due Sunday, March 22, 2026 at 11:59 PM.

Real web development is almost never a solo activity. Developers work on teams, divide responsibilities, review each other’s code, and coordinate through version control. This project simulates that workflow from start to finish.

What you will learn:

• How to build and maintain HTML, CSS, and JavaScript across multiple pages at scale
• How to collaborate using Git branches, pull requests, and code review
• How to communicate effectively as a development team
• How to divide work, manage milestones, and deliver a polished product on deadline

This project spans approximately 6 weeks. You will need to plan, build, test, and present as a team. The skills you develop here – both technical and collaborative – carry directly into professional web development.

Before You Start: Team Setup

Understanding the Requirements

Here is what each rubric category is worth and what I am looking for:

Team Collaboration Guide

This is the most important section of this guide. Technical skills get the website built, but collaboration skills determine whether the team succeeds or falls apart.

Communication Best Practices

• Set up a dedicated channel – a Discord server or Slack workspace specifically for this project. Keep project discussion separate from personal chats
• Agree on response time expectations – for example, everyone responds within 24 hours. Set this expectation in your first meeting
• Use async communication for updates, sync (meetings) for decisions – post progress updates in chat anytime; save complex decisions for live meetings
• Post regular standups – every day or every other day, each person posts a brief update: “What I finished, what I am working on next, any blockers”

GitHub Workflow for Teams

This is the workflow your team should follow for every piece of work. It prevents conflicts, enables code review, and creates a clear history of who built what.

git clone https://github.com/your-team/group-project-1.git
cd group-project-1

git checkout -b feature/homepage
# or
git checkout -b feature/contact-form
# or
git checkout -b fix/mobile-nav

git add index.html css/styles.css
git commit -m "Add hero section HTML structure and basic styling"

# Continue working...
git add css/styles.css
git commit -m "Add responsive navigation with Flexbox"

# Continue working...
git add js/main.js
git commit -m "Add mobile hamburger menu toggle"

git push origin feature/homepage

git checkout main
git pull origin main
git checkout -b feature/next-task

Avoiding Merge Conflicts

Merge conflicts happen when two people edit the same lines in the same file. They are not catastrophic, but they are annoying. Here is how to minimize them:

• Pull from main often – at least daily when you are actively working:

git checkout main
git pull origin main
git checkout your-branch
git merge main

• Communicate about which files you are editing – post in your group chat: “I am working on styles.css today, specifically the hero section”
• Do not work on the same file at the same time – coordinate who edits what
• If a conflict happens, resolve it together on a call – screen share so both people understand what gets kept
• Consider splitting CSS into separate files – for example, nav.css, hero.css, footer.css that are all linked from each HTML page. This reduces the chance of two people editing the same CSS file

Code Review Etiquette

When reviewing a teammate’s pull request:

• Be constructive, not critical: “Have you considered using Flexbox here? It might simplify this layout” – not “This code is wrong”
• Focus on the code, not the person: “This section could use more spacing” – not “You did not add enough spacing”
• Suggest improvements, do not just point out problems: If something could be better, explain how
• Approve promptly – do not let pull requests sit for days. Aim to review within 24 hours
• Leave comments on specific lines – GitHub lets you comment on individual lines of code in a PR, which is much clearer than general feedback

Meeting Structure

Keep meetings short and focused. Use this simple standup format (5-10 minutes):

1. Each person: What did you finish since last time?
2. Each person: What are you working on next?
3. Any blockers or issues?
4. Quick decisions needed?

Handling Team Issues

Weekly Milestones

These milestones keep your team on track across the six-week project timeline. Falling behind by more than one week puts the entire project at risk.

Technical Guidance by Area

HTML Approach

• Start with a sitemap: draw which pages exist and how they connect. A simple sketch on paper or a shared whiteboard is enough
• Create the shared navigation first – it must be identical on every page. Get this right early so every team member can copy the same <nav> element
• Use semantic elements consistently across all pages: <header>, <nav>, <main>, <section>, <article>, <footer>
• Maintain proper heading hierarchy: one <h1> per page, followed by <h2>, <h3>, etc. in order
• Validate with the W3C Validator after each page is complete. Fix errors immediately – they compound if ignored

CSS Approach

JavaScript Feature Ideas

You need at least 3 interactive features across the site. Here are ideas to consider, described conceptually. The implementation is up to you and your team.

1. Mobile hamburger menu – a button that shows and hides the navigation links on small screens. Essential for responsive sites
2. Form validation – check that required fields are filled in, email addresses are formatted correctly, and show helpful error messages before the form submits
3. Image carousel or slider – cycle through a series of images with previous and next buttons. Common on homepages and gallery pages
4. Accordion or FAQ section – collapsible content sections where clicking a question reveals the answer. Keeps long content organized
5. Content filter or search – filter a list of items (products, team members, resources) by category using buttons or a search field
6. Modal or popup – an overlay with content that appears when the user clicks a button or link. Closes when clicking outside or pressing a close button
7. Smooth scroll – clicking a navigation link scrolls smoothly to the corresponding section on the page instead of jumping instantly
8. Scroll animations – elements fade in, slide in, or otherwise animate as the user scrolls down the page
9. Theme switcher – a toggle that switches between light and dark mode, changing background and text colors across the entire site
10. Back to top button – a button that appears when the user scrolls down and smoothly scrolls back to the top of the page when clicked

Project Structure

Presentation Guide

Your team will present the project live to me – either during a scheduled meeting or during a Thursday class session before March 22. Every team member must participate.

Peer Evaluation

After submission, each team member completes a confidential peer evaluation:

• Due within 3 days of the project deadline
• Confidential – I see them, your teammates do not
• Rate each team member on contribution level, communication quality, and work quality (1-5 scale)
• Describe each member’s contributions in your own words
• Self-assessment of your own contribution
• Adjusts individual grades by up to plus or minus 20%

Deployment Guide

Your project must be deployed to a live URL. Choose one of these options:

Submission Checklist

Before submitting, verify every item:

• 5+ HTML pages with semantic elements (<header>, <nav>, <main>, <section>, <footer>)
• Consistent, working navigation across all pages
• External CSS stylesheet(s), fully responsive (mobile-first with min-width media queries)
• Flexbox and/or CSS Grid used for layouts
• Consistent design system (colors, fonts, spacing applied across all pages)
• 3+ JavaScript interactive features working correctly
• No CSS frameworks (no Bootstrap, Tailwind, etc.)
• All team members have visible Git contributions (commits and pull requests)
• Feature branches and pull requests used (not direct pushes to main)
• Deployed to GitHub Pages, Netlify, or Vercel with a working live URL
• README includes: project name, team members and roles, live URL, screenshots, tech stack, setup instructions, feature list
• HTML passes the W3C Validator with no errors
• Each member has PR links ready for their individual D2L submission
• Presentation completed (all members participated, cameras on)
• Peer evaluations submitted within 3 days of the deadline

Troubleshooting & Common Mistakes

git checkout main
git pull origin main
git checkout your-branch
git merge main

cd group-project-1
git status

git branch feature/my-work
git reset --soft HEAD~1
git checkout feature/my-work
git add .
git commit -m "Your commit message"

Key Takeaways

Additional Resources

Git & GitHub

Web Development

Team Collaboration