Project: Build a community resource directory

Outcome

Build a directory that helps a visitor find and inspect fictional community resources. The directory contains at least twelve structured entries and supports search or category filtering. Your current course level determines whether you implement the directory as a tested application or an editor-managed CMS publication.

What you will practice

Model repeated public information as consistent directory records.
Build an accessible search, filter, result, and detail path.
Plan how directory data stays valid, current, and maintainable in the selected implementation.

Project brief

A fictional municipality or community organization needs one place to list public resources. Choose a directory focus such as repair services, cultural venues, study spaces, sports facilities, volunteer organizations, or public meeting rooms.

The directory must help a visitor answer these questions:

Which resources match a name, category, or visitor need?
What does each resource provide?
Where is it available and when is it open?
What accessibility or arrival information is available?
When was the information reviewed, and how can a visitor reach the organization safely?

Use fictional records or verified public organization information. Do not publish a private person’s contact details, schedule, address, or other personal information.

Starting point

Before you start

The application, data, CMS, SEO, and accessibility lessons used in the selected course level.
A proposed directory topic with at least twelve fictional or verified public entries.
A parent course folder where you can create one dedicated project folder or CMS evidence folder.
A code editor and browser, or access to the CMS used in the selected course level.

Current state: The resource records can begin in a spreadsheet or text outline. No application, CMS model, or search interface is required before you begin.
First action: Open the selected level section. Define the fields that every resource record must contain, then complete one reference record.
First checkpoint: The directory shows twelve resource names, categories, summaries, and locations from one consistent record structure.
Help trigger: Open the assistance section or ask for help when a resource cannot fit the shared record structure or the current search state is unclear.

Requirements

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

Required directory behavior

The directory contains at least twelve resources across at least three categories.
Each resource has a stable identifier, name, category, summary, location, opening information, accessibility or arrival information, public contact route, and review date.
A visitor can search resource names and summaries or filter resources by category.
The result view states the active search or filter and the number of matching resources.
A visitor can inspect one complete resource record and return to the previous directory state.
Empty and unavailable states explain what happened and provide a route back to the full directory.

Accessibility and responsive behavior

The search field has a persistent visible label.
Filter controls expose their names and selected state to assistive technology.
Result updates are announced without moving keyboard focus unexpectedly.
Every link and control works with a keyboard and has a visible focus state.
The directory remains usable without horizontal page scrolling at a 320px viewport and at 200% browser zoom.
Categories, review status, empty states, and errors do not depend on color alone.

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 directory subject, fictional organization, categories, records, visual style, result layout, and detail-page structure.
Choose whether search updates immediately or after submission, provided the current query and result count remain clear.

Out of scope

The required project does not include private records, user accounts, reviews, booking, payment, live maps, or an emergency-service directory.
The project does not require implementation rules from another course level.
Optional extensions do not affect whether the required directory is complete.

Level-specific implementation

Complete the shared requirements and one level section. The other section is not an additional requirement.

Level 3.1 · Web Development

Provisional expected effort: 14–22 hours for the required path. This range includes data preparation, application setup, implementation, support, debugging, automated testing, verification, and re-entry. Optional extensions are not included.

New and reused: Reuse accessible interface, responsive design, routing, and component skills. Add validated directory data, URL-controlled search state, derived results, error boundaries, and automated tests.

First action: Create the application with the framework used in your current course work. Define the resource data type or schema, then validate and render one complete reference record.

Required implementation

Define and validate or type every required resource field.
Store the twelve resource records outside the components that render them.
Keep the active query and category in explicit state and reflect them in the URL so a filtered view can be shared or restored.
Derive matching resources from the complete validated data set without changing the source records.
Use stable identifiers for resource routes, list keys, and lookups.
Separate search controls, result summaries, resource cards, resource details, empty states, and errors into clear responsibilities.
Handle empty data, invalid records, unknown resource identifiers, and data-loading failure with usable states.
Add automated tests for a combined search-and-category result, restoration from URL state, and one invalid-data or unknown-resource path.
Use version control and confirm that the production build completes without errors.

Level 3.1 definition of done

The project is complete for Level 3.1 when the shared requirements pass, validated resource data drives stable routes and derived results, URL state restores a filtered view, every required unavailable state is usable, all three automated test paths pass, and the production build completes without errors.

Level 3.2 · Content Management

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

New and reused: Reuse content strategy, taxonomy, SEO, analytics, and publishing skills. Add directory record validation, content ownership, review dates, controlled categories, and archive behavior.

First action: In the CMS used in your current course work, create a resource content type with fields for identifier, name, category, summary, location, opening information, accessibility or arrival information, public contact route, content owner, and review date.

Required implementation

Build the directory in the CMS used in your current course work.
Store each resource as a separate structured record instead of one item in a manually edited directory page.
Create categories as controlled taxonomy or reusable category records.
Validate required fields, URL fields, identifier uniqueness, and review dates where the CMS supports these rules.
Make list and detail templates render records without resource-specific layout edits.
Add draft, published, needs-review, and archived states or an equivalent documented workflow.
Configure a unique page title, meta description, and stable URL for each resource detail page.
Create an editor checklist for sources, public contact details, alternative text, category choice, link checks, review date, preview, publication, and archive decisions.
Write a short analytics plan with two measurements and the directory 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, editors can create and maintain structured resource records through controlled categories and required fields, templates render the directory without record-specific layout changes, the review and archive workflow works, resource pages contain the required SEO information, and the editor and analytics plans are complete.

Create and verify the resource records

Define one shared record structure.
Complete all required fields for twelve resources.
Assign every resource to one of at least three controlled categories.
Check public contact routes and review dates.
Render or publish the complete unfiltered directory.

Check

All twelve resources appear, use the same required fields, have stable identifiers, and provide complete public information without exposing private data.

Checkpoint: The complete directory data is available

What now works: Twelve consistent resource records appear across at least three categories with complete contact and review information.
What remains: Complete search, filtering, detail, unavailable-state, and selected level requirements.
Next action: Implement or configure one category filter and verify its result count.
If it does not work: If one record fails, compare it with the complete reference record and correct the first missing or invalid field before changing the interface.

Complete the find-and-inspect path

Add the selected level’s search and category behavior. Preserve the active directory state when the visitor opens one resource and returns. Verify empty, invalid, unknown, and archived or unavailable states that apply to the implementation.

Check

Search for a known name, combine the search with one category, open a matching resource, return to the same result state, then trigger one no-results or unavailable path.

Checkpoint: The complete directory path works

What now works: Search, category filtering, result feedback, resource details, return behavior, and required unavailable states pass the shared and selected level requirements.
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 the first failed item.
If it does not work: If the wrong result appears, inspect the active query, category, and resource values before changing the search logic or CMS template.

Assistance

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

Assistance 1 — Identify the active directory state

Name the state you are testing: full directory, search results, category results, combined results, resource detail, no results, invalid data, or archived content. Work only in the owner of that state.

Assistance 2 — Use one resource-data contract

Give every resource the same fields: identifier, name, category, summary, location, opening information, accessibility or arrival information, public contact route, owner, and review date. Validate one record before adding the remaining records.

Assistance 3 — Follow the directory subgoals

Use this order: define the record, complete twelve resources, render all resources, add one filter, add search, preserve state through the detail path, implement unavailable states, then complete the selected level checks.

Self-check

Complete these checks against the required result.

Count the resources and confirm that at least twelve complete records appear across at least three categories.
Search for a known resource and confirm that the result summary states the query and correct result count.
Combine one search with one category and confirm that every result matches both conditions.
Open one resource, return, and confirm that the previous directory state is restored.
Trigger no-results and one invalid, unknown, or archived state and confirm that each state provides a clear recovery route.
Use only the keyboard to operate every link and control and confirm that focus remains visible and predictable.
Check the directory 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 level do not apply.
Confirm that every record uses fictional or verified public organization information and contains no private personal data.

Safe stopping point

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