Evergreen Community
Services District

Evergreen Community Services District is a complete public-sector digital platform covering everything an independent parks and recreation district does: finding a park, registering for a program, reserving a hall, reading a board agenda, responding to a bid and requesting an interpreter.

It was built to demonstrate that a district website can be genuinely useful to residents without giving up any of the rigour a public agency needs in its records, its notices and its procurement.

Parks and recreation districts carry two audiences that pull in opposite directions. A parent looking for a Tuesday swim lesson wants a catalog. A vendor looking for an addendum wants a filing cabinet. Most district sites pick one and fail the other.

The answer here was not to compromise between them but to give each its own idiom inside one design system: photography and browsable categories at the front, dense ruled records at the back, with shared components, shared vocabulary and a single search index across both.

Navigation is organised the way residents describe their errands, not the way the district is departmentally organised: Parks, Programs, Events, Rentals, Community, District. A department-shaped menu would have put Recreation Services and Parks and Facilities side by side, which means nothing to someone looking for a picnic shelter.

Every one of the six sections resolves to a real landing page, and every link in the mega menu resolves to a real filtered view with its own shareable URL.

The facility finder filters twelve facilities across six independent dimensions: type, amenity, accessibility feature, reservability, indoor or outdoor, and neighborhood. Each option shows how many results it would leave, and options that would return nothing are disabled rather than hidden so the column does not reflow as you work.

Filter state lives in the URL, so a filtered view can be bookmarked, shared or linked to from a mega menu. A schematic district diagram sits above the results; it is explicitly labelled as not to scale and not survey data, because implying geospatial precision a district has not published would be worse than showing nothing.

Programs are presented as a catalog rather than a records table. Each row carries what a family actually compares on: age range, the days and times it meets, the dates it runs, the resident fee and how many places are left.

Seven filters cover age, activity, registration status, day of week, time of day, season and location. Registration status is stored rather than derived, so a waitlisted program says waitlist instead of quietly accepting a registration that cannot be honoured.

The events calendar offers a chronological list and a grouped-by-month view. A month grid was built and discarded: a district running sixteen events a year would spend most of that grid on empty cells.

Rentals cover thirteen spaces with capacity, resident and nonprofit rates, deposits, insurance requirements and the cancellation schedule. The reservation request form validates against the capacity of the selected space, so a request for 200 people in a room that holds 40 is caught before it reaches staff.

Eighteen board meetings are published with agenda, packet and approved minutes, filterable by year, meeting type and agenda topic. The document library holds eighty-nine records across twelve categories with full metadata.

Meeting documents are derived from the meeting records rather than duplicated, which means a meeting and its documents cannot disagree about a date, a title or a file size. Documents that have not completed accessibility remediation are marked as such, with the alternate-format offer stated rather than implied.

Designed and tested against WCAG 2.1 Level AA. Semantic landmarks and a logical heading order on every page, a skip link, visible focus on a single consistent treatment, and colour never used as the only carrier of meaning: every status chip states its status in words.

Forms use the error-summary pattern public services have converged on, with a focused, linked list of problems at the top of the form and each error described in text beside its field. Hints and errors are wired through aria-describedby; nothing depends on a placeholder.

The accessibility of the district itself is treated as content, not a disclaimer: each facility lists its accessibility features, the finder filters on them, and a page aggregates coverage across all twelve facilities so gaps are visible rather than buried.

Laid out from 320 pixels upward rather than shrunk from the desktop. Filters collapse into a full-height drawer with a count on the trigger and an explicit apply action; catalog rows restack so price and schedule stay adjacent to the name; the horizontal parks rail becomes a swipeable gallery with scroll snapping.

Every interactive target keeps a 44 pixel minimum, and content reflows without horizontal scrolling at 320 pixels and at 400 percent zoom.

A warm paper ground rather than white, a deep desaturated forest as the institutional voice, and clay as the warm counterweight that carries alerts and emphasis. Fraunces sets display type at editorial sizes; Figtree handles body and interface text.

Every colour, type step, radius and container width is a token consumed by components, so the system can be re-themed without touching a page. Status colours were chosen to clear 4.5:1 against their own tints, not against white, because that is where they are actually used.

Cards are used sparingly by design. Listings are ruled rows, photography carries its own captions, and sidebars are margin notes with a heavy top rule rather than boxes floating above the page.

Every record is typed, and facilities are the spine: programs, events, rentals, projects, notices and meetings all reference a facility id. That is what makes the cross-linking trustworthy rather than decorative. A project references a facility that exists; a notice links the project it concerns; a solicitation links back to the project it procures.

Labels for every coded value live in one taxonomy module, so a facility type is worded identically in a filter chip, a search result and a detail page. The unified search index is built from the same records at module load, which is why search results carry real metadata instead of a generic snippet.

Next.js App Router with React Server Components and TypeScript in strict mode. Detail routes are statically generated through generateStaticParams; filtered index pages read the query string on the server so their filters work as ordinary crawlable links without JavaScript.

Interactive finders are client components behind Suspense boundaries, which keeps their shells in the static payload. Images are served through next/image with explicit sizes; fonts are self-hosted through next/font with no layout shift. Structured data is emitted for facilities, events, job postings and the FAQ page.

TypeScript strict passes with no errors, ESLint passes with no warnings, and the production build completes with every route accounted for. All routes were exercised, including every dynamic detail page, and checked for console errors, broken links and layout overflow.

Layouts were audited at 320, 375, 390, 430, 768, 1024 and 1440 pixels. Keyboard paths were walked end to end: navigation and mega menus, filter drawers, the meeting archive, form validation and the search flow.