Why we built it this way

Why we built it

Your RFP asks for “dynamic storytelling, data dashboards, and program information”. Most government sites treat those as separate problems, and the storytelling loses. Here they sit in a fixed order: tasks first, stories second. The home page opens with the region, then the six things people come to do (find a meeting, comment on a notice, get rid of banned items, start a CDBG project, check a hazard plan, read a report), and only then Our work in the region. A resident who needs a collection fee never has to scroll past a story to find it.

The stories are built from real posts: the 2027 CDBG cycle, the Chillicothe environmental review, the county hazard plans, the fall collection events, RISE. Each card ends with a plain line (Your next step, How to comment, Who to ask) so a story always hands the reader something to do.

Typographically it’s a serif display face over a clean sans, drawn from system font stacks so nothing is fetched from another server. The palette is warm paper with your greens, because the Green Hills are green.

What’s in it

Eight pages, each showing a pattern the live site would repeat:

• Meetings, agendas and minutes: the March 26, 2026 board day as a timeline, then 22 real records across five bodies, each with its agenda and minutes status. Where minutes aren’t posted, it says so.
• Public comment: the open Chillicothe environmental review, how to comment today, and the comment form as we propose it. The form sends nothing.
• Hazard mitigation plans: the data page. A map, a “by the numbers” row, a sortable table and one document with its summary.
• Solid Waste District (a program page), the 2027 CDBG cycle (a story) and newsletters and annual reports (the archive, with filters).

The map is real

The county shapes are U.S. Census Bureau boundaries (TIGERweb, 2026), simplified slightly and drawn in the page as SVG from GeoJSON. There is no map service and no embedded frame. On the live site, GHRPC’s own ArcGIS Pro exports replace them and are drawn by the same code, so every map stays sharp, printable, reachable by keyboard and readable by a screen reader, with a table beside it that says the same thing in words.

What it is not

• It is not the official GHRPC website. ghrpc.org is. Every page here carries that banner and a noindex, nofollow instruction.
• It is not a content migration. Eight pages are built. The other pages and posts on ghrpc.org (about a hundred in our capture) are not here.
• It contains no invented facts. Every date, fee, figure, name and quotation comes from ghrpc.org as captured on September 22, 2026. Where GHRPC hasn’t published something (a comment deadline, a next meeting, a set of minutes, a PDF’s page count) we left the gap visible rather than filling it.
• The comment form sends nothing, and documents aren’t hosted here: document links go to ghrpc.org.

What’s labeled, and why

• “Our proposal” marks notes that describe what the live site would do: how staff add a meeting, what a commenter receives, how the hazard page stays true. They are Clearview’s proposal, not GHRPC practice today.
• Labeled slots show where live content would go: “Next meeting: appears here when staff post the agenda”, and the closing date on a public notice.
• “Our tally” marks the hazard-plan counts, which we counted from GHRPC’s list. GHRPC doesn’t publish them.
• “Illustrative” marks two things: the published-figures table on Newsletters & annual reports, where the rows are real but the way staff would maintain them is the proposal, and the document details on the CDBG story that a live build would add.

How it was made

Static HTML generated by a small build script, one stylesheet and two small scripts. No frameworks and no external requests: no CDN, no font service, no analytics, no embedded frames. Photographs are GHRPC’s own, from ghrpc.org. It loads quickly on a phone on a rural connection.

This concept is built on Nanopage, an AI-assisted site platform that our CTO, Jasmin Ihtijarevic, is involved in building. It’s one of three platforms in our proposal, at the same price. The same design can be built on WordPress or a purpose-built CMS.

The accessibility is not decoration. One h1 per page and no skipped heading levels; a skip link; visible focus; alt text on every image; AA contrast in every state; tables with captions, th scope and sort buttons that announce their order; a Menu button that works by keyboard and closes with Escape; labels on every form field; lang="en"; and respect for prefers-reduced-motion. Every page is checked with axe-core. Turn JavaScript off and every page still reads: menus, sorting and filtering are enhancements over content that is already there.

How we would handle it

In a real build, this design sits on a CMS your staff can run without us.

• Staff sign in with Microsoft 365 on WordPress or the purpose-built CMS: single sign-on against your existing tenant, so there’s no second password. Nanopage doesn’t offer Microsoft 365 sign-in yet.
• A meeting is one form. Body, date, time, place, remote link and agenda file; minutes are added to the same record later. It appears on the meetings page, the calendar and the body’s page at once.
• Documents attach to pages, not to a file dump. Staff upload a report, write a two-sentence summary and tag it, and it appears in the archive, in the year filter and on its program page.
• Data comes in as data. An Excel sheet or an ArcGIS export becomes a sortable table or an inline map, so funding agencies and residents read the number instead of downloading it.
• Comments arrive as dated records, with a confirmation to the commenter and a closing date on every notice.
• Stories are just posts. The magazine layout is generated from the posts you already write; nobody lays out a grid.
• Training and documentation for your team, and an accessibility check built into publishing so the standard holds after we leave.