Project: Build a community event website

Outcome

Build a website for a fictional one-day community event. The website will help a visitor find the event date, location, schedule, practical information, and contact route. The product goal stays the same at every level. Your current course level determines the required implementation.

What you will practice

Turn a product brief into a complete website with clear visitor tasks.
Apply the technical methods from your current course level to one shared product goal.
Verify content, responsive behavior, keyboard operation, and level-specific requirements.

Project brief

The fictional organization is preparing a one-day community event. Choose an event type such as a technology meetup, repair workshop, local conference, creative market, or public information day.

The organization needs a website that answers these visitor questions:

What is the event?
When and where does it take place?
What happens during the day?
What should a visitor know before arriving?
How can a visitor contact the organizer or reach a registration service?

Use fictional contact details and a non-functional registration link such as https://example.com/register. Do not collect or publish private information.

Starting point

Before you start

The lessons and tools used in your current course level.
A code editor and browser, or access to the CMS used in your current course level.
A parent course folder where you can create one dedicated project folder or CMS evidence folder.

Current state: The event idea can be new or based on a supplied classroom brief. No finished event website is required before you begin.
First action: Use the level links below to open your level section. Read the shared requirements and the requirements for that level before you create files or CMS content.
First checkpoint: The website opens and shows the event name, date, and location on its main page.
Help trigger: Open the assistance section or ask for help when you cannot identify the next file, CMS item, or test needed for the current checkpoint.

Requirements

The required assignment is complete when every applicable criterion below is met.

Required visitor information

The main page identifies the event name, purpose, date, and location.
The website contains a schedule with at least three named activities and their times.
The website contains practical visitor information, including accessibility or arrival information.
The website provides a safe contact route or a non-functional link to an external registration service.
Navigation links let a visitor reach the main information areas.

Accessibility and responsive behavior

Headings describe the content and follow a logical order.
Links and controls have names that describe their destination or action.
A visitor can use every link and control with a keyboard and can see the current focus position.
Text and controls remain readable without horizontal page scrolling at a 320px viewport and at 200% browser zoom.
Meaning does not depend on color alone, and each meaningful image has suitable alternative text.

Project workspace and version control

Create one dedicated project folder before implementation. Keep unrelated exercises and repositories outside it.
For a source-code implementation, make the project folder a Git repository on main and connect it to its own private GitHub repository as origin.
Commit coherent working checkpoints, inspect staged changes, push the final verified state, and finish with a clean working tree.
For a CMS implementation, use one dedicated CMS workspace and a local evidence folder for plans and restorable exports. Use Git for source or evidence files when the selected level requires it, and never commit credentials or private data.

Design freedom

Choose the event type, organization name, written content, images, visual style, and page structure.
Use one page or several pages unless your level requirements specify a technical structure.

Out of scope

The project does not require real registration, payment, authentication, or storage of visitor information.
The project does not require the implementation rules from another course level.
Optional extensions do not affect whether the required project is complete.

Level-specific implementation

Complete the shared requirements and one level section. The other level sections show how the same brief can support later or parallel course work. They are not additional requirements.

Level 1 · Web Introduction

Provisional expected effort: 6–10 hours for the required path. This range includes orientation, content preparation, implementation, support, debugging, verification, and re-entry. Optional extensions are not included.

New and reused: Reuse semantic HTML, CSS, responsive layout, image preparation, and validation. The project combines these skills in one complete product.

First action: Create the project folder and add index.html and styles.css. Connect the stylesheet and open index.html in a browser.

Required implementation

Build the website with semantic HTML and CSS.
Use header, nav, main, and footer for content that matches those purposes.
Use a responsive layout that changes without hiding required information.
Validate the HTML and correct errors that affect the document structure.
Do not use JavaScript or a framework for the required path. This level assesses the HTML and CSS implementation.

Level 1 definition of done

The project is complete for Level 1 when all shared requirements pass, the HTML and CSS files contain the complete website, the layout works at the required viewport and zoom checks, and you can explain two semantic or responsive-design choices.

Level 2 · Web Construction

Provisional expected effort: 8–14 hours for the required path. This range includes orientation, content preparation, implementation, support, debugging, verification, and re-entry. Optional extensions are not included.

New and reused: Reuse responsive HTML and CSS. Add client-side interaction, motion rules, and a basic analytics plan.

First action: Create or open the event website, add the complete schedule as static content, and confirm that every schedule item is visible before JavaScript runs.

Required implementation

Add schedule categories and controls that filter the visible schedule items with JavaScript.
Keep every schedule item available when JavaScript is unavailable.
Show the selected filter through text and visual state. Do not rely on color alone.
If the interface uses motion, remove non-essential motion when prefers-reduced-motion is active.
Write a short analytics plan that names two useful events or measurements and explains what question each one answers. Real tracking is not required.

Level 2 definition of done

The project is complete for Level 2 when all shared requirements pass, the schedule filters work with pointer and keyboard input, the unfiltered schedule remains available without JavaScript, reduced-motion behavior passes, and the analytics plan names two relevant measurements.

Level 3.1 · Web Development

Provisional expected effort: 10–18 hours for the required path. This range includes orientation, content preparation, implementation, support, debugging, verification, and re-entry. Optional extensions are not included.

New and reused: Reuse accessible interface and responsive-design skills. Add component boundaries, structured data, version control, and automated verification.

First action: Create the project with the framework used in your current course work. Render the event name, date, and location from one structured event-data object.

Required implementation

Build the interface with the framework and routing approach used in your current course work.
Store event and schedule content separately from the components that render it.
Split the interface into components with clear responsibilities, such as event summary, navigation, schedule, and practical information.
Add at least one automated test for a component, data transformation, or user interaction that matters to the required result.
Use version control and keep commit messages focused on meaningful project changes.
A backend, database, and authentication system are not required.

Level 3.1 definition of done

The project is complete for Level 3.1 when all shared requirements pass, the framework renders structured event data through clear components, the required automated test passes, the repository records the implementation history, and the production build completes without errors.

Level 3.2 · Content Management

Provisional expected effort: 8–14 hours for the required path. This range includes orientation, content modeling, CMS configuration, support, debugging, verification, and re-entry. Optional extensions are not included.

New and reused: Reuse content planning, usability, SEO, and analytics skills. Add a content model and an editor-focused publishing workflow.

First action: In the CMS used in your current course work, create an event content type with fields for the event name, date, location, summary, and practical information.

Required implementation

Build the website in the CMS used in your current course work.
Create structured fields for the event details and schedule instead of placing all content in one unrestricted text field.
Make it possible for an editor to change the event date, location, and schedule without changing the page layout.
Add a unique page title, meta description, and clear URL for the main event page.
Create a short publishing checklist that covers content review, link checks, responsive checks, and publication.
Write a short analytics plan that identifies two useful measurements. Real tracking is not required.

Level 3.2 definition of done

The project is complete for Level 3.2 when all shared requirements pass, an editor can update the event and schedule through structured CMS fields, the main page contains the required SEO information, and the publishing and analytics plans are complete.

Build the shared visitor path

Add the event name, purpose, date, and location to the main page.
Add the schedule, practical information, and contact or registration route.
Connect the navigation to each main information area.
Open the website in a browser and follow the visitor path from the first heading to the contact or registration route.

Check

A visitor can identify the event, find one schedule activity, review the practical information, and reach the contact or registration route without guessing where to go next.

Checkpoint: The core event information is available

What now works: The main page shows the event identity, date, location, schedule, practical information, and contact or registration route.
What remains: Complete and verify the implementation requirements for your selected course level.
Next action: Return to your level section and test its first required technical behavior.
If it does not work: If information is missing, compare the visible page with the five visitor questions in the project brief and add one missing answer at a time.

Complete and verify your level implementation

Complete only the implementation section for your current level. Keep the shared visitor path working while you add the technical structure, interaction, framework behavior, or CMS workflow.

Check

Run every check in your level definition of done. Correct one failed check at a time, then repeat the complete visitor path.

Checkpoint: The selected level implementation works

What now works: The shared website and the implementation requirements for one course level pass their stated checks.
What remains: Run the final self-check and prepare the project for submission.
Next action: Complete the self-check from top to bottom and record any failed item before you change the project.
If it does not work: If several checks fail, begin with the first shared requirement that fails. Restore that behavior before you test the level-specific requirements again.

Assistance

The complete brief and requirements remain visible above. Open one assistance level when you want more structure.

Assistance 1 — Identify the current target and working area

Work with one course level. Keep the shared requirements and that level section open. Your current target is the first visitor result that does not work yet. Make the next change in the file, component, or CMS item that owns that result.

Assistance 2 — Use a bounded content outline

Start with these five content areas: event summary, schedule, practical information, location, and contact or registration. Add one area at a time. Use the same content outline whether you render it with HTML, JavaScript, a framework, or a CMS.

Assistance 3 — Follow the project subgoals

Use this order:

Make the event identity visible.
Add every required content area.
Connect the navigation.
Complete the implementation requirements for your level.
Test keyboard use, narrow layout, and 200% zoom.
Run the final level-specific check and prepare the submission.

Self-check

Complete these checks against the required result.

Open the main page and confirm that the event name, purpose, date, and location are visible without using a menu.
Follow the schedule, practical-information, and contact or registration paths and confirm that every required destination is available.
Use only the keyboard to operate every link and control. Confirm that focus remains visible.
Check the website at a 320px viewport and at 200% browser zoom. Confirm that required content and controls remain usable without horizontal page scrolling.
Run the checks in your selected level definition of done. Requirements from the other levels do not apply.
Confirm that no page, repository, screenshot, or CMS entry contains private contact information or login credentials.

Safe stopping point

Stop after a checkpoint passes. Record what works, which shared or level-specific requirement remains, the exact next action, and any required server, browser, repository, or CMS state. Use that note as the first action when you resume.