Queen’s School of Computing: A CISC 121 Homework

Student Webpage Tutorial + Peer Review

Launch your own site in 20 minutes

This tutorial guides you — no coding experience required — to create and deploy a personal Queen’s Computing student webpage and complete a simple peer code review.

What to Submit (deliverables on OnQ)

Submit to OnQ once you finish all steps

Reminder: These are required deliverables. This homework counts towards the participation mark and feedback will be provided. Your website must be launched successfully so we can give you meaningful feedback.

Step 0: Sign in (or create a GitHub account)

~1–2 minutes

Tips & fixes
  • No verification email? Check spam or click Resend verification.
  • Forgot password? Use Forgot password on the sign‑in page.
  • Student Pack rejected? Re‑apply with your Queen’s email and a photo of your student card.

Step 1: Create your repository

~2 minutes

Explainer: A repository (“repo”) is like a special online folder where all the code, images, and history for your project are stored. GitHub keeps track of changes over time, like a timeline.

  1. Click the + in the top bar → New repository.
  2. Name it queens‑student‑page and check Add a README.
  3. Choose Public, add MIT LicenseCreate repository.
Tips & fixes
  • Repo name taken? Try queens‑student‑page‑2025.
  • Private repo? GitHub Pages works only on Public (unless paid plan).

Step 2: Add your homepage

~4 minutes

Explainer: HTML is the language of web pages. It uses “tags” like <h1> for headings, <p> for paragraphs, and <img> for images. The browser reads this file top to bottom and displays it as a page.

Add a file named index.html at the root (main level) of the repo and paste this starter. The red comments show where to personalize.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1"/>
    <title>My Queen’s Student Page</title>
    <link rel="stylesheet" href="style.css"/> <!-- do not change this line -->
  </head>
  <body>
    <header>
      <h1>Welcome to My Page</h1> <!-- change this heading to your name -->
    </header>

    <main>
      <!-- ====== ABOUT SECTION (edit the text) ====== -->
      <h2>About Me</h2>
      <p>I am a student at Queen’s School of Computing. I’m interested in <!-- replace with interests -->.</p>

      <!-- ====== PHOTO (upload me.jpg to repo root, then update the src below) ====== -->
      <img src="me.jpg" alt="Your Name portrait" width="240" height="240" />

      <!-- ====== PROJECTS/COURSES (add or rename items to courses instead of projects) ====== -->
      <h2>Projects</h2>
      <ul>
        <li>Project One — one sentence description.</li>
        <li>Project Two — coming soon.</li>
      </ul>

      <!-- ====== CONTACT (update your links) ====== -->
      <h2>Contact</h2>
      <p>Email: <a href="mailto:student@queensu.ca">student@queensu.ca</a></p>
      <p>LinkedIn: <a href="#">add your link here</a></p>
    </main>
  </body>
</html>
Tips & fixes
  • Where to place? The file is at the top level of your repo, not inside a folder.
  • Wrong name? Must be exactly index.html.

Step 3: Add Queen’s branding (style.css)

~3 minutes

Explainer: CSS is the language that styles your HTML. It controls colors, fonts, spacing, and layout. By separating style (CSS) from structure (HTML), it’s easier to update the look without touching the content.

Create a file named style.css (at the same level as index.html) and paste:

:root {
  --red:#b90e31; --gold:#fabd0f; --blue:#002452;
}
body { font-family: system-ui, sans-serif; margin:0; background:var(--red); color:#fff; }
header { background:var(--blue); color:#fff; padding:1rem; }
main { background:#fff; color:#1a1a1a; max-width:900px; margin:2rem auto; border-radius:12px; padding:1.5rem; }
a { color: var(--blue); }
/* === personalize below by changing colors or spacing === */
/* example: make headings blue and a bit larger */
h2 { color: var(--blue); font-size: 1.6rem; }
/* example: make your photo round */
img { border-radius: 12px; }
Tips & fixes
  • Not working? Ensure <link rel="stylesheet" href="style.css"> is inside <head> of index.html.
  • Colors look off? Double‑check the hex codes.
  • Long code lines overflow? Scroll the code block; boxes now scroll horizontally if needed.

Step 4: Enable GitHub Pages

~3 minutes

Explainer: GitHub Pages is a free hosting service. When you enable it, GitHub takes your index.html and style.css files and serves them on the public web. That’s how your code “lives online” at a real URL.

  1. Go to Settings → Pages.
  2. Set SourceDeploy from a branch.
  3. Choose Branch main, Folder /rootSave.
  4. Wait for the green check, then open the link.
Tips & fixes
  • 404? Wait a minute and refresh.
  • No URL? Confirm repo is Public and branch/folder are set.

Step 5: Personalize & publish updates

~6–7 minutes

Explainer: HTML + CSS together make your website. HTML is the “skeleton” (sections, text, images). CSS is the “skin and clothes” (colors, fonts, layout). Every change you make and commit to GitHub will trigger GitHub Pages to redeploy your live site.

You have two options:

  1. Manual edits: Open index.html. Use the existing structure and follow these instructions:
    • Change the page title: In the <title> tag inside <head>, replace My Queen’s Student Page with your own name.
    • Header with your name: Find <h1>Welcome to My Page</h1> and replace the text with your name.
    • About Me: In <main>, replace the sample paragraph with a few sentences about yourself.
    • Add a photo: Upload an image (e.g., me.jpg) to repo root. Then add:
      <img src="me.jpg" alt="Photo of Your Name" width="240" height="240" />
    • Projects: After About section:
      <h2>Projects</h2>
      <ul>
        <li>Project One — one sentence description.</li>
        <li>Project Two — coming soon.</li>
      </ul>
    • Contact: At bottom of <main>:
      <h2>Contact</h2>
      <p>Email: <a href="mailto:student@queensu.ca">student@queensu.ca</a></p>
      <p>LinkedIn: <a href="https://linkedin.com/in/yourprofile">linkedin.com/in/yourprofile</a></p>
  2. With Copilot Chat: After the Student Pack is active, in VS Code ask Copilot to personalize your page, e.g., “Insert my name into the page title and header.”
Tips & fixes
  • Image not showing? Ensure file is uploaded at repo root and filename matches exactly.
  • Broken layout? Keep new sections inside <main>...</main>.
  • Made a mistake? Revert to an earlier version: Go to your repo → Code tab → click the commit count (e.g., "15 commits") → find the working version → click the commit hash → click Browse files → copy the URL. Then go back to Code tab → Add fileUpload files → drag your backup files or use the web editor to manually restore the working content. Alternative: Click the commit hash → click Revert button (if available) → Create revert commit.
Congrats! You now have a live, customizable student page.

Step 6: Pair up & peer review (homework) — full instructions

~20–25 minutes total (10–12 per partner)

A) Invite your partner (so they can be assigned as reviewer)

  1. Open your repo → SettingsCollaborators and teams (sometimes shown as Manage access).
  2. Click Add people → type your partner's GitHub username → Add.
  3. Your partner must accept the email/in-app invite. (Without accepting, they can still comment, but you can't formally assign them as a reviewer.)
Tips
  • Public repos allow comments from anyone; adding as collaborator enables formal Review assignments and suggestion commits.
  • If Collaborators and teams isn't visible, ensure you're the repo owner.

B) Create a "review Pull Request (PR)" in your repo

  1. On the Code tab, open the branch dropdown (it says main) → type peer-review-prepCreate branch.
  2. Edit a tiny thing in index.html (e.g., add a comment <!-- TODO: improve About text -->) → Commit.
  3. Click the yellow banner "Compare & pull request" → title: Peer Review: <Your Name>.
  4. In the PR description, paste your live URL + any questions you have for the reviewer.
  5. On the right side, under Reviewers, assign your partner (after they accepted the invite).

C) Partner: conduct the peer review using the Code Review Checklist

Goal: Apply the CISC 121 Code Review Checklist to evaluate your partner's webpage for readability, correctness, maintainability, and best practices.

  1. Go to your partner's repo → Pull requests tab → open the PR titled Peer Review: ...
  2. Open the live URL in a new tab to test functionality.
  3. Click Files changed to review the code line-by-line.
  4. Use the Code Review Checklist below to guide your review. Leave at least one comment per checklist category (8 total minimum).
  5. For each comment, follow SMART feedback principles (see guidelines below).
  6. When finished, click Review changes (top-right) → write a summary → choose Comment, Approve, or Request changesSubmit review.
The Code Review Checklist (from CISC 121)
Checklist Item What to Check For
1. Functionality Does the code work correctly? Test the live site: click all links, verify images load, check for console errors.
2. Clarity Is the code easy to read and understand? Check for meaningful element names, clear headings, no jargon.
3. Structure Is the code organized in small parts (semantic HTML)? Verify proper use of <header>, <main>, heading hierarchy, etc.
4. Maintainability Is it easy to update later? Ensure styles are in CSS (not inline), repeated patterns use classes, colors use CSS variables.
5. Performance Does the code run efficiently? Check image file sizes, avoid redundant CSS, ensure page loads quickly.
6. Security Does it handle bad inputs safely? Verify no personal phone/address exposed, external links are trustworthy, no inline scripts from unknown sources.
7. Documentation Are the comments useful? Check README explains setup, HTML comments clarify sections, commit messages describe why changes were made.
8. Testing Are edge cases handled? Test on mobile/desktop, try broken image paths, click mailto/external links, verify accessibility (alt text, contrast).
How to Give SMART Feedback

Every comment you leave should follow the SMART framework from CISC 121:

  • Specific: Point to the exact file, line, or behavior. Say what to change.
    Example: "In index.html line 23, the <img> tag is missing an alt attribute. Add alt='Photo of [Name]' for accessibility."
  • Measurable: Define what "better" means with a concrete check (e.g., test passes, page loads faster, no console errors).
    Example: "Reduce me.jpg from 2MB to under 500KB so the page loads in under 2 seconds on slow connections."
  • Achievable: Suggest a realistic fix given the scope and skill level of CISC 121.
    Example: "Replace inline styles with a CSS class. For instance, change <p style='color:blue'> to <p class='highlight'> and define .highlight { color: var(--blue); } in style.css."
  • Relevant: Keep feedback aligned with the homework goals (functionality, clarity, structure, etc.). Avoid nitpicks that don't improve the page.
    Example (good): "This heading should be <h2> instead of <h3> to maintain proper hierarchy."
    Example (avoid): "I prefer green over blue" (personal preference, not relevant).
  • Time-bound: Indicate priority or timeline.
    Example: "Fix the broken LinkedIn link before merging this PR" or "Consider adding a footer in a future update."
❌ Bad feedback: "Your design is bad."
✅ Good feedback: "In style.css line 12, the background color #fff and text color #f0f0f0 have low contrast (WCAG fail). Change text to #1a1a1a for readability. Fix before merge."
How to leave comments in GitHub
  • Line-specific comment: In Files changed, hover over a line → click the blue + → type your SMART feedback → Add review comment.
  • Suggest a code change: Click Insert a suggestion button → edit the code block → Add review comment. The author can apply it with one click.
  • General comment: Use the Conversation tab for issues that span multiple files (e.g., "All images are missing alt text").
  • Attach screenshots: Drag-drop images into the comment box to show visual issues (e.g., layout bug on mobile).

D) Author: respond to feedback & apply changes

  1. Open your PR → read all comments in Conversation and Files changed tabs.
  2. For suggestion blocks, click Apply suggestion (or Add suggestion to batch) → Commit.
  3. For other feedback, edit the files directly (via web or local) → commit with a descriptive message referencing the feedback (e.g., "Fix alt text per @partner's review").
  4. Reply to each comment to acknowledge it or ask clarifying questions.
  5. When all critical issues are resolved, click Merge pull requestConfirmDelete branch. GitHub Pages will redeploy automatically.

E) Quick reference: Review comment examples by checklist item

Expand for example comments
  • Functionality: "The LinkedIn link in line 34 points to # (nowhere). Update to your actual LinkedIn profile or remove it. Fix before merge."
  • Clarity: "In line 18, the heading 'Stuff' is vague. Change to 'My Projects' or 'Coursework' so visitors understand the section. Fix before merge."
  • Structure: "Lines 20–25 nest an <h3> directly under <h1> with no <h2>. This breaks heading hierarchy. Change <h3> to <h2>."
  • Maintainability: "Line 30 uses inline style style='color:#b90e31'. Move this to style.css as .red-text { color: var(--red); } so future color changes are centralized."
  • Performance: "me.jpg is 3.2MB. Compress to under 500KB using TinyPNG or similar. Goal: page load under 2 seconds on 3G. Fix before merge."
  • Security: "Line 40 includes your phone number. Remove it unless you intend to make it public. If intentional, acknowledge this comment."
  • Documentation: "README is empty. Add a sentence: 'Personal student page for CISC 121. Edit index.html to update content.' Can follow up after merge."
  • Testing: "The <img> in line 28 has no alt attribute. Add alt='Portrait of [Your Name]' for screen-reader users. Fix before merge."