Skip to main content

Solicitation No. 131SB-26

Approach and project plan

Irving asked for a website for Arts and Culture. Rather than describe one, we built the thing and put it behind a code so you can use it before you read a word about us. This page is the plan behind what you have just clicked through.

Make a specific ask Back to the homepage
  • Pages standing up Eight, all real and navigable
  • Accessibility WCAG 2.2 Level AA and Section 508
  • Timeline Four months, six overlapping phases
  • Built on A content management system your staff can use

Amplus, responding to Solicitation 131SB-26

This is not a mockup. It is the site, already running.

Every page in this demo is a real page on a real content management system, with real Irving Arts and Culture content, a working events filter and a live accessibility toolbar. What follows is the plan that would take it from this demo to launch.

What is already standing up

  • A homepage that is not an org chart

    The first screen names the five destinations and what is on this week. Nothing on it is organised by who reports to whom.

    See the homepage

  • Task navigation, not department navigation

    Buy tickets, plan a visit, book a tour, rent a space, bring my class, support the arts. Six verbs sit above the menu on every page.

    It is on every page

  • One calendar, filtered by mood

    Twelve live records across five venues, filtered by what somebody wants to do on a Saturday rather than by which venue owns the room.

    Try the filters

  • Five identities inside one shell

    Each destination keeps its own colour and photography, inside a structure that behaves the same way everywhere.

    See the five

  • A destination page that answers the visit

    Hours, parking, accessibility and getting there, on the page a visitor is already reading. On the current site they are four separate pages.

    See the Arts Center

  • Accessibility built in, not bolted on

    Text sizing, contrast, reduced motion and link highlighting from a toolbar in the header, on top of semantic markup that already passes.

    Open the toolbar

Six phases, seventeen weeks, four months from kickoff to launch

Phases overlap on purpose, and that overlap is what makes four months realistic rather than optimistic. Design starts while discovery is still finishing, migration starts before the last template is signed off, and accessibility testing runs against real pages as they are built rather than as a gate at the end. Waiting for a clean handoff between stages is how public sector web projects lose a quarter. The one thing that moves this date is content: we need decisions on the retired pages inside the first three weeks.

  1. 01 Weeks 1 to 3

    Discovery and content audit

    Stakeholder interviews across the five venues, an inventory of every page on the current site, and analytics on what residents actually open. Port St. Lucie removed more than six hundred pages before they designed anything. We would expect to recommend something similar.

    • Full content inventory with a keep, merge or retire decision on every page
    • Stakeholder findings from each venue
    • Analytics and search log review
  2. 02 Weeks 2 to 5

    Information architecture and task modelling

    We build the navigation around what people are trying to finish, then let the structure work out which department owns it. Tested with real residents before a single page is designed.

    • Task inventory ranked by volume and urgency
    • Sitemap mapped against Exhibit A
    • Tree testing with residents and staff
  3. 03 Weeks 4 to 8

    Design system and page design

    One set of tokens for colour, type, spacing and radius, and a component library built on top of it. Changing a brand colour changes every page at once. That is how this demo is built, and you can see it in the consistency between pages.

    • Design tokens and component library
    • Key page designs at three breakpoints
    • Per venue identity within the shared shell
  4. 04 Weeks 6 to 13

    Build and content migration

    Templates built as reusable blocks so staff compose pages rather than file tickets. Content migrated with redirects mapped from every retired URL, so nothing that is currently indexed turns into a 404.

    • Full template build in the CMS
    • Content migration with editorial review
    • Redirect map for every changed URL
  5. 05 Weeks 11 to 15

    Accessibility audit and remediation

    Automated testing catches roughly a third of what matters. The rest is keyboard walkthroughs, screen reader passes and colour contrast checked against real content rather than against a swatch.

    • WCAG 2.2 Level AA and Section 508 audit
    • Keyboard and screen reader test report
    • Remediation and a published accessibility statement
  6. 06 Weeks 14 to 17

    Training, launch and support

    Role based training for the people who will actually edit, recorded so the next hire does not need us. Launch on a rehearsed runbook, then a support window with agreed response times.

    • Role based training and recorded sessions
    • Editor documentation in plain language
    • Launch runbook and post launch support

How this answers the scope of work

Responsive design
Every page here is built mobile first and tested at 390px, 768px and 1440px.
WCAG 2.2 Level AA and Section 508
Semantic landmarks, visible focus, skip links and a resident facing accessibility toolbar.
Content management
Role based editing. Staff compose pages from blocks without touching code or markup.
Content migration
Audit first, migrate second, with a redirect mapped from every retired URL.
Search
Weighted toward tasks and events rather than returning every page that contains a word.
Events and ticketing
One record per event with categories, venue, recurring dates and the external box office link.
Forms and rentals
Quote requests, volunteer applications, grant forms and class bookings, routed to a named owner.
SEO and analytics
Structured data per venue and per event, plus redirects and measurement configured at launch.
Hosting and security
Managed hosting, daily backups, a staging environment and a documented restore path.
Training and support
Recorded role based training, written documentation and an agreed support window.

Your specific ask

Tell us what you want to see next and we will build it.

This demo covers a homepage, a full destination page and every section of the Exhibit A sitemap. If there is a page, a workflow or a piece of the scope you want proven before you decide, name it here and we will stand it up rather than describe it.

Or call us directly. [email protected]

Pick anything that applies