My progress
Menu

Level 2 · Web Development Basics · Course 2.3 Introduction to JavaScript

Module 20: Your First Interactive Website

Goal: find and fix problems with the browser's tools, test your site properly, and publish it on the internet, completing the website you've built through Level 2.

You'll need: your site from Module 19, pushed to GitHub (Module 10).

Lessons

  1. 1Reading errors15–25 minutes✓
  2. 2Debugging with the browser's tools15–25 minutes✓
  3. 3Testing your site15–25 minutes✓
  4. 4Publishing your site15–25 minutes✓
  5. 5Frontend and backend, and what comes next15–25 minutes✓

🛠️Module practice: finish and check

  1. Fix every console error and Lighthouse warning you can.
  2. Complete your TESTING.md checklist on desktop and phone.
  3. Publish the site and test the live version.
  4. Ask one person to use it while you watch, and fix one thing they struggled with.

🛠️Level 2 final project: Build and Publish Your First Website

You now have everything you need for the Level 2 project (6 to 10 hours). Build a website for a portfolio, a small business, an education project or a community group, with:

  1. At least three linked pages with semantic HTML.
  2. Alt text on every meaningful image.
  3. Navigation and a footer on every page.
  4. One external stylesheet, using Flexbox or Grid.
  5. A responsive layout that works from phone to desktop.
  6. A form with browser validation (it doesn't need to send data yet; that's Level 4).
  7. At least two JavaScript interactions.
  8. Accessibility and error testing, written down in TESTING.md.
  9. A Git history of small, clear commits.
  10. Published online.

✅Module check

Explain in a few sentences, in your own words:

How do you find and fix a bug, and what's the difference between the frontend you've built and a backend?

Show a good answer

A good answer mentions: reproduce the problem, read the first console error and its line, check real values with console.log or breakpoints, test one guess at a time, and make the smallest fix; then retest with a checklist. The frontend runs in the visitor's browser and controls what they see and do; the backend runs on a server and handles what must be trusted or kept: storing data, logins, secrets, emails and final validation.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. The console shows a SyntaxError and none of your interactions work. Why do they all fail?

Why each option is right or wrong

  • “Each feature happens to have its own separate bug” (Incorrect): Many bugs at once is unlikely; one syntax error explains them all.
  • “The CSS file overrode the JavaScript” (Incorrect): CSS can't stop JavaScript from running.
  • “The browser needs updating to run the code” (Incorrect): A SyntaxError means the code itself is broken, not the browser.
  • “A syntax error stops the whole file from running” is correct.

    Before running a script, the browser reads the whole file. If it finds code it can't understand, like a missing bracket, it refuses to run any of that file, so every feature in it stops at once.

    • The clue: everything breaks together, and the console names a line.
    • Fix that one line and everything usually returns.

📖 Revise: Lesson 1: Reading errors

Question ID module-20-q1 · Report a mistake in this question
2. What should you give an AI when asking for help with an error?

Why each option is right or wrong

  • “Just a short note that the page is broken, plus its web address” (Incorrect): Without the error and code, the AI can only guess.
  • “Your password, so it can log in and look” (Incorrect): Don't share passwords. Paste the relevant error and code instead.
  • “A screenshot of the whole home page only” (Incorrect): A screenshot shows the symptom, not the error or the code.
  • “The full error, the code around the named line, and what you expected” is correct.

    The exact error message and line number point to the problem. The nearby code shows the context. Saying what you expected lets the AI tell the difference between a crash and a logic mistake.

    • Don't share passwords, keys or private customer data in the chat.

📖 Revise: Lesson 1: Reading errors

Question ID module-20-q2 · Report a mistake in this question
3. Your menu button does nothing, and there's no error. What would you check?

Why each option is right or wrong

  • “The domain's renewal date” (Incorrect): The page loaded, so the domain is fine.
  • “Whether the server is running the latest version of Node.js for the site” (Incorrect): The menu runs in the browser, not on the server.
  • “The file size of the logo image” (Incorrect): Images don't stop click handlers.
  • “Whether the click handler runs at all, and whether the class is toggled” is correct.

    No error means the code ran without crashing, but something didn't connect. Add a console.log in the handler to see if it fires, then watch the Elements tab to see if the class changes. That splits the problem between JavaScript and CSS.

    • Handler doesn't fire: check the selector and where the listener is added.
    • Class toggles but nothing shows: check the CSS rule.

📖 Revise: Lesson 2: Debugging with the browser's tools

Question ID module-20-q3 · Report a mistake in this question
4. Why fix the smallest thing and test, rather than change many things at once?

Why each option is right or wrong

  • “Browsers can only apply one code change at a time, so the rest are lost” (Incorrect): Browsers handle any number of changes. The limit is your understanding.
  • “Git rejects commits with many changes” (Incorrect): Git accepts large commits; they're just harder to understand.
  • “Big changes are slower to save” (Incorrect): Saving speed isn't the issue.
  • “You know which change fixed it, and avoid creating new problems” is correct.

    Change one thing, test, and you learn what works. Change ten things at once and if it works you don't know why, and if it breaks you don't know which change did it.

    • Commit after each working step so you can go back.

📖 Revise: Lesson 2: Debugging with the browser's tools

Question ID module-20-q4 · Report a mistake in this question
5. Everything works on your laptop in Chrome. What haven't you tested yet?

Why each option is right or wrong

  • “Nothing more, since Chrome is the browser most of your visitors use anyway” (Incorrect): Most used isn't all. Safari is common on iPhones.
  • “Only the page title and favicon” (Incorrect): Those are minor next to phones and accessibility.
  • “Only the fonts on other laptops” (Incorrect): Fonts are one small part of cross-device testing.
  • “Phones, other browsers, the keyboard alone, slow connections and odd input” is correct.

    Your laptop is one setup out of many. Real visitors use small phone screens, Safari and Firefox, keyboards and screen readers, slow mobile data, and type unexpected things into forms.

    • Quick wins: a real phone, Firefox, Tab through the page, the slow 3G setting in DevTools.
    • Odd input: empty fields, very long names, emoji.

📖 Revise: Lesson 3: Testing your site

Question ID module-20-q5 · Report a mistake in this question
6. Your site works locally, but a page shows 404 online. What's a likely cause?

Why each option is right or wrong

  • “The page is too short for the server to send” (Incorrect): Servers send pages of any length.
  • “The server doesn't support HTML files” (Incorrect): Web servers exist to serve HTML.
  • “Your browser's cache is still holding the old site” (Incorrect): A cache can show old content, but not a 404 from the server.
  • “A link's upper or lower case doesn't match the file name” is correct.

    Windows and Mac usually ignore case in file names; most web servers don't. A link to Contact.html works locally but fails online if the file is contact.html.

    • Habit: lowercase file names and links everywhere.
    • Other cause: the file wasn't uploaded.

📖 Revise: Lesson 4: Publishing your site

Question ID module-20-q6 · Report a mistake in this question
7. Can a static site on GitHub Pages store contact form messages by itself?

Why each option is right or wrong

  • “Yes, by writing them into the HTML file” (Incorrect): Browsers can't write to files on the server.
  • “Yes, in localStorage stored on GitHub's servers” (Incorrect): localStorage lives in each visitor's browser, not on any server.
  • “Yes, by saving them in the CSS file” (Incorrect): CSS styles pages; it can't store data.
  • “No, storing data needs a backend or a form service” is correct.

    A static site is just files sent to the browser. There's no code on the server to receive a form and save it. You need a backend with a database, or a third-party form service.

    • Quick option: form services that email you the messages.
    • Later: your own backend, covered from Level 4.

📖 Revise: Lesson 4: Publishing your site

Question ID module-20-q7 · Report a mistake in this question
8. Why can't a payment secret key be kept in your frontend JavaScript?

Why each option is right or wrong

  • “JavaScript can't store long text like keys” (Incorrect): It can store any text.
  • “It would make every payment slower” (Incorrect): Speed isn't the problem; exposure is.
  • “Minifying the code first would hide the key well enough from visitors” (Incorrect): Minified code is still readable; the key would be easy to find.
  • “Every visitor downloads the frontend code, so anyone could read it” is correct.

    All frontend code is sent to the visitor's browser, where they can read it with View Source or DevTools. A secret key there is public. Secret keys belong on a server.

    • Publishable keys are designed to be public; secret keys aren't.
    • If one leaks: revoke it at the provider straight away.

📖 Revise: Lesson 5: Frontend and backend, and what comes next

Question ID module-20-q8 · Report a mistake in this question
9. Why watch someone else use your site?

Why each option is right or wrong

  • “To check that the colours look right to them” (Incorrect): Colours are a small part. Confusion and mistakes matter more.
  • “To measure the server's speed” (Incorrect): Speed is measured with tools, not by watching.
  • “It's a legal requirement before publishing” (Incorrect): It isn't required; it's just very useful.
  • “They find confusing parts you can't see” is correct.

    You know how your site works, so you can't see it fresh. A new person shows you where they hesitate, misread, or click the wrong thing, which is exactly what you need to fix.

    • Don't help them: stay quiet and take notes.
    • Five people usually reveal the biggest problems.

📖 Revise: Lesson 3: Testing your site

Question ID module-20-q9 · Report a mistake in this question
10. Why check the repository for private information before publishing with GitHub Pages on a free account?

Why each option is right or wrong

  • “GitHub automatically removes private files when it publishes the site” (Incorrect): Nothing is deleted; it's all visible.
  • “Private information slows the site down” (Incorrect): Speed isn't the concern; exposure is.
  • “Pages can't display any private files” (Incorrect): The concern isn't display, it's that the repository is readable.
  • “On a free account, the repository must be public, so anyone can read it” is correct.

    On GitHub's free plan, Pages publishes from public repositories, so every file and every past commit can be read by anyone. Notes, keys or personal details in the history are exposed.

    • Check history too: a deleted file still exists in older commits.

📖 Revise: Lesson 4: Publishing your site

Question ID module-20-q10 · Report a mistake in this question

ProLearners Assist