Project: Build a browsable product catalog

Outcome

Build a catalog that helps a visitor browse at least eight fictional products, narrow the list, and inspect complete product information. The catalog does not sell products. Your current course level determines whether you focus on browser interaction, application architecture, or content management.

What you will practice

Turn repeated product information into a consistent content structure.
Build an accessible browse-and-inspect path for a product catalog.
Verify the data, interface, and publishing requirements for the selected course level.

Project brief

A fictional organization has a small product range but no usable catalog. Choose one coherent range, such as workshop tools, office equipment, assistive products, outdoor equipment, or digital service packages.

The catalog must help a visitor answer these questions:

Which products are available?
Which category does each product belong to?
What is the product for?
What are its important features or specifications?
How can the visitor narrow the list and inspect one product in detail?

Use fictional product and organization data. Use placeholder prices when prices support the chosen catalog. Do not add real payment, checkout, customer accounts, or stock systems.

Starting point

Before you start

The lessons and tools used in your current course level.
A content outline for at least eight fictional products in two or more categories.
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 product range can begin as a text outline. No catalog interface, application, or CMS model is required before you begin.
First action: Open the selected level section. Define the product fields that every catalog item must contain, then write one complete sample product.
First checkpoint: The catalog shows all eight product names, categories, and summaries in a consistent repeated structure.
Help trigger: Open the assistance section or ask for help when one product cannot fit the shared field structure or the next browse behavior is unclear.

Requirements

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

Required catalog behavior

The catalog contains at least eight products across at least two categories.
Each product has a name, category, short summary, image or visual placeholder, and at least three features or specifications.
A visitor can narrow the visible catalog by category.
A visitor can inspect complete information for one product without losing a clear route back to the catalog.
An empty category or no-results state explains why no products are visible and how to return to the full catalog.

Accessibility and responsive behavior

Product names use headings that preserve a logical document order.
Product images have useful alternative text, or an empty alt attribute when they repeat adjacent text without adding information.
Filter controls expose their names and selected state to assistive technology.
Every link and control works with a keyboard and has a visible focus state.
The catalog remains usable without horizontal page scrolling at a 320px viewport and at 200% browser zoom.

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 product range, organization, categories, specifications, images, visual style, and card layout.
Choose whether full product information appears on a page, route, or accessible disclosure when your level permits that choice.

Out of scope

The required project does not include real payment, checkout, authentication, customer data, stock synchronization, or an administrative dashboard.
The project does not require implementation rules from another course level.
Optional extensions do not affect whether the required catalog is complete.

Level-specific implementation

Complete the shared requirements and one level section. The other sections are not additional requirements.

Level 2 · Web Construction

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

New and reused: Reuse responsive HTML and CSS. Add JavaScript state, category filtering, clear result feedback, and a small analytics plan.

First action: Add all eight products as visible HTML. Assign each product a category value that the filter can read.

Required implementation

Add category controls that filter the product list with JavaScript.
Keep all products and their essential information available when JavaScript is unavailable.
Store the selected category in one clear application-state value instead of inferring state from CSS classes alone.
Show the selected category and matching product count through visible text.
Provide a clear no-results state and a control that restores all products.
Respect prefers-reduced-motion if product cards or detail views use motion.
Write a short analytics plan with two measurements and the catalog question each measurement answers. Real tracking is not required.

Level 2 definition of done

The project is complete for Level 2 when the shared requirements pass, category filtering and reset behavior work with pointer and keyboard input, all product content remains available without JavaScript, result and no-results states are clear, and the analytics plan contains two relevant measurements.

Level 3.1 · Web Development

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

New and reused: Reuse accessible interface and responsive-design skills. Add typed product data, derived filter state, routes, component boundaries, and automated verification.

First action: Create the application with the framework used in your current course work. Define the product data type or schema, then render one valid product through a product-card component.

Required implementation

Store the eight products as structured data outside the components that render them.
Validate or type the required product fields so missing names, categories, summaries, and specifications are detectable during development.
Derive the visible product list from the complete data set and selected filter state.
Use clear component boundaries for filters, catalog results, product summaries, product details, and empty states.
Give each product a stable detail route or URL based on an identifier rather than its displayed position.
Add automated tests for one filtering behavior and one product-data or routing edge case.
Use version control and confirm that the production build completes without errors.
A backend and database are not required; local structured data is valid for the required path.

Level 3.1 definition of done

The project is complete for Level 3.1 when the shared requirements pass, valid structured product data drives the catalog and stable detail routes, filtering derives from explicit state, both required automated tests pass, and the production build completes without errors.

Level 3.2 · Content Management

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

New and reused: Reuse content planning, usability, SEO, taxonomy, and publishing skills. Add reusable product fields, controlled categories, and an editor-focused workflow.

First action: In the CMS used in your current course work, create a product content type with fields for name, identifier, category, summary, image, alternative text, and specifications.

Required implementation

Build the catalog in the CMS used in your current course work.
Create reusable product fields instead of placing every product inside one unrestricted page field.
Create categories as controlled taxonomy or reusable category records rather than free-text variations on each product.
Make the catalog and product-detail templates render CMS content without product-specific layout edits.
Configure a unique page title, meta description, and stable URL for each product detail page.
Create an editor checklist for product entry, image alternative text, category selection, preview, link checks, and publication.
Write a short analytics plan with two measurements and the catalog question each measurement answers. Real tracking is not required.

Level 3.2 definition of done

The project is complete for Level 3.2 when the shared requirements pass, an editor can add or update products through reusable fields and controlled categories, templates render the catalog without product-specific layout changes, product pages contain the required SEO information, and the editor and analytics plans are complete.

Create the complete catalog content

Define the shared product fields.
Complete all fields for eight products.
Assign every product to a valid category.
Render or publish the complete unfiltered catalog.
Open one product and verify every required detail.

Check

All eight products appear in the unfiltered catalog, use the same required field structure, and provide a working route to complete product information.

Checkpoint: The complete catalog content is available

What now works: Eight consistent products appear across at least two categories, and one complete product-detail path works.
What remains: Complete and verify the selected level's browse, architecture, or CMS requirements.
Next action: Return to the selected level section and implement its first category behavior or content-model check.
If it does not work: If a product is missing or inconsistent, compare its fields with the complete sample product and correct one field before testing the catalog again.

Complete and verify category browsing

Implement the selected level’s category behavior. Confirm that the full catalog, one filtered result, and the no-results state each give the visitor a clear next action.

Check

Select each category in turn. Confirm that every visible product belongs to the selected category, the result state is announced, and the full catalog can be restored.

Checkpoint: Category browsing works

What now works: The complete, filtered, product-detail, and no-results paths pass the shared requirements and selected level contract.
What remains: Run the final self-check and prepare the project for submission.
Next action: Run the self-check from top to bottom and record the first failed item.
If it does not work: If filtering shows the wrong product, inspect that product's category value before changing the filter logic or template.

Assistance

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

Assistance 1 — Identify the active catalog state

Name the state you are testing: all products, one selected category, one product detail, or no results. Work only in the data, control, component, or CMS template that owns that state.

Assistance 2 — Use one consistent product record

Create one complete reference record with these fields: name, identifier, category, summary, image, alternative text, and specifications. Compare every other product with that record.

Assistance 3 — Follow the catalog subgoals

Use this order: define the fields, complete eight products, render all products, add category browsing, add the product-detail path, verify empty states, then complete the selected level checks.

Self-check

Complete these checks against the required result.

Count the products and confirm that at least eight complete records appear across at least two categories.
Select every category and confirm that each result contains only matching products.
Open one product and confirm that its full information is available with a clear route back to the catalog.
Trigger the no-results state and confirm that it explains the result and provides a route back to all products.
Use only the keyboard to operate every link and control and confirm that selected and focus states remain visible.
Check the catalog at a 320px viewport and at 200% browser zoom without horizontal page scrolling.
Run the checks in the selected level definition of done. Requirements from the other levels do not apply.

Safe stopping point

Stop after a checkpoint passes. Record the catalog state that works, what remains, the exact next action, and any required server, browser, data, repository, or CMS state. Use that note when you resume.