Queue-North-Website/docs/design/OVERHAUL_PLAN.md

1015 lines
26 KiB
Markdown
Raw Normal View History

2026-05-12 01:10:34 -05:00
# Queue North Website — 2026 Overhaul Plan
docs: adopt project template, retire the markdown backlog This repository is the one the template's README describes: 205 issues, zero milestones, and severity labels spelled "P0 Critical" / "P1 High" / "P2 Medium", which privacyllc.dev reports as NOT ADOPTED rather than as 87% complete. Six markdown records described the same work and none pointed at the tracker. Two of them said the project was in "Phase 5" while the code was at 0.9.3. Migrated, then deleted in this commit: FUTURE.md -> docs/history/BATCH_LEDGER.md (Archived). Its open items were all already filed as issues, so nothing needed migrating into the tracker HISTORY.md -> docs/history/DEVELOPMENT_LOG.md, verbatim, 0 lines lost DEVELOPMENT_LOG.md -> the same file, as a second labelled block. Not interleaved: the changelog has three duplicated version headings, so one date order would have implied more than the record supports PROJECT.md -> docs/planning/PROJECT_PLAN.md STRUCTURE.md -> the agent pipeline into README.md; its versioning rules retired BUILD_SUMMARY.md -> BATCH_LEDGER.md. Its embedded SQL schema deliberately NOT carried: it predated the UNIQUE constraint on leads.email, and server/index.js owns the schema SCRIPTS.md -> docs/TOOLS.md, corrected for the SSR + prerender build Moved with history (git detects all four as renames): OVERHAUL_PLAN.md, review.md, project-requirements.md, docs/zoho-setup.md Kept because this project earned them: the five-agent pipeline, the design system in OVERHAUL_PLAN.md (Status: Current, with a front-note saying which half is history), the positioning argument in REDESIGN_REVIEW.md, and REQUIREMENTS.md whole, including its change policy. Deleted from the template because they do not apply, each said out loud in DOC_TRUST_MAP.md: QA pass I (no money moves), the authorisation checklist group and the session-token row (no accounts, no sessions), and one PRECAUTIONARY paragraph in SECURITY.md about holding credentials on behalf of users — there are none, and PROJECT_PLAN.md records accounts as out of scope. Pass H was kept and rewritten: its authorisation half does not apply, its what-a-stranger-can- reach half is the most exposed surface here. Also removed: main.js, the old static site's hash router, referenced by nothing and preserved in .drop/; and test-results/.last-run.json, a May Playwright artifact reading {"status":"failed"} for a suite that does not exist. The repository was made private on Forgejo before this commit. That is what let the internal history be committed rather than exempted — null/fruit-fall is already private and reports normally. Two defects found on the way in and fixed here: zoho-setup.md told admins to edit `server/zoho/`, a directory that has never existed in any commit (the mapping is in server/index.js), and README.md's route list still advertised /8x8, removed at 0.6.6, while omitting /privacy-policy. Branding: icon.webp and logo.webp converted from this project's own marks in assets/. banner.webp is absent and is filed as an issue rather than faked. Verified: verify.sh 3/3, doc-claims 71 claimed paths all present, backup and a first-ever restore of the live leads database (2 tables, 3 rows, under 1s). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-18 01:19:02 -05:00
```
Status: Current
Owner: _null
Last reviewed: 2026-08-18
Governs: tailwind.config.js, src/index.css — the visual system: palette,
typography, spacing, radius and shadow, component choices, and the
layout blueprints for each page type
Review trigger: Any change to a Tailwind theme token, the type scale, the
spacing rhythm, or the layout of a page type; any new page type
```
> **Two halves, and only one is current.** Its *Scarlett Design Implementation
> Brief* onward — Tailwind theme tokens, the numeric-typography rule, the type
> scale, section spacing, radius and shadow rules, the component list, the page
> blueprints and the explicit anti-patterns — is the **live design authority** for
> this project and should be trusted as written.
>
> Its earlier *Migration Phases* and *Agent Plan* sections describe a rebuild that
> completed at `v0.9.x`. They are kept as the record of what was planned and are
> **history, not instructions**. The narrative of how it actually went is in
> `docs/history/BATCH_LEDGER.md`; open work is in the tracker.
2026-05-12 01:10:34 -05:00
## TL;DR
Rebuild the current static HTML/CSS/JS website into a modern full-stack app using:
- **Vite** — build tool, not Next.js
- **React** — SPA with client-side routing via React Router
- **Tailwind CSS** — utility-first styling
- **shadcn/ui** — component primitives
- **Sonner** — toast notifications
- **TanStack Query** — server state management
- **Express** — backend API
- **better-sqlite3** — local SQLite database
The current website has good business content, but the structure and visual design feel dated. The rebuild should make Queue North Technologies feel like a modern, trustworthy, premium communications and infrastructure partner.
---
## Current Site Assessment
The current project is a static site with:
- `index.html` — all pages live in one large file
- `styles.css` — large hand-written stylesheet with many page-specific overrides
docs: adopt project template, retire the markdown backlog This repository is the one the template's README describes: 205 issues, zero milestones, and severity labels spelled "P0 Critical" / "P1 High" / "P2 Medium", which privacyllc.dev reports as NOT ADOPTED rather than as 87% complete. Six markdown records described the same work and none pointed at the tracker. Two of them said the project was in "Phase 5" while the code was at 0.9.3. Migrated, then deleted in this commit: FUTURE.md -> docs/history/BATCH_LEDGER.md (Archived). Its open items were all already filed as issues, so nothing needed migrating into the tracker HISTORY.md -> docs/history/DEVELOPMENT_LOG.md, verbatim, 0 lines lost DEVELOPMENT_LOG.md -> the same file, as a second labelled block. Not interleaved: the changelog has three duplicated version headings, so one date order would have implied more than the record supports PROJECT.md -> docs/planning/PROJECT_PLAN.md STRUCTURE.md -> the agent pipeline into README.md; its versioning rules retired BUILD_SUMMARY.md -> BATCH_LEDGER.md. Its embedded SQL schema deliberately NOT carried: it predated the UNIQUE constraint on leads.email, and server/index.js owns the schema SCRIPTS.md -> docs/TOOLS.md, corrected for the SSR + prerender build Moved with history (git detects all four as renames): OVERHAUL_PLAN.md, review.md, project-requirements.md, docs/zoho-setup.md Kept because this project earned them: the five-agent pipeline, the design system in OVERHAUL_PLAN.md (Status: Current, with a front-note saying which half is history), the positioning argument in REDESIGN_REVIEW.md, and REQUIREMENTS.md whole, including its change policy. Deleted from the template because they do not apply, each said out loud in DOC_TRUST_MAP.md: QA pass I (no money moves), the authorisation checklist group and the session-token row (no accounts, no sessions), and one PRECAUTIONARY paragraph in SECURITY.md about holding credentials on behalf of users — there are none, and PROJECT_PLAN.md records accounts as out of scope. Pass H was kept and rewritten: its authorisation half does not apply, its what-a-stranger-can- reach half is the most exposed surface here. Also removed: main.js, the old static site's hash router, referenced by nothing and preserved in .drop/; and test-results/.last-run.json, a May Playwright artifact reading {"status":"failed"} for a suite that does not exist. The repository was made private on Forgejo before this commit. That is what let the internal history be committed rather than exempted — null/fruit-fall is already private and reports normally. Two defects found on the way in and fixed here: zoho-setup.md told admins to edit `server/zoho/`, a directory that has never existed in any commit (the mapping is in server/index.js), and README.md's route list still advertised /8x8, removed at 0.6.6, while omitting /privacy-policy. Branding: icon.webp and logo.webp converted from this project's own marks in assets/. banner.webp is absent and is filed as an issue rather than faked. Verified: verify.sh 3/3, doc-claims 71 claimed paths all present, backup and a first-ever restore of the live leads database (2 tables, 3 rows, under 1s). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-18 01:19:02 -05:00
- main.js — manual hash-based routing and interactions. Named without backticks
because this section describes the site as it was BEFORE the rebuild; that
file was deleted on 2026-08-18 and a backticked path would claim it still
exists. The original is preserved in `.drop/`
2026-05-12 01:10:34 -05:00
- Inline Zoho webform scripts
- Static assets in `assets/`
### Current Problems
1. **Single giant HTML file**
- All pages live inside `index.html`.
- Routing is manually handled through hash-based JavaScript.
- The structure is hard to maintain and scale.
2. **CSS is doing too much**
- `styles.css` is very large.
- Many page-specific rules and overrides exist.
- Layout feels patched together instead of systemized.
3. **Old visual language**
- Current colors lean heavily on dark teal and beige.
- Header/logo behavior feels awkward and dated.
- Repeated cards and sections lack a strong modern design system.
- The site communicates the right business, but not with enough polish.
4. **Fragile contact form flow**
- Inline Zoho scripts.
- Hidden iframe submission.
- Difficult to validate, style, and control in a modern app.
5. **No real application architecture**
- No component system.
- No API layer.
- No database.
- No modern routing.
- No server-state management.
---
## Target Architecture
## Frontend Stack
Use:
- **Vite**
- **React**
- **React Router**
- **Tailwind CSS**
- **shadcn/ui**
- **Sonner**
- **TanStack Query**
### Suggested Frontend Structure
```txt
client/
src/
app/
App.jsx
router.jsx
components/
layout/
Header.jsx
Footer.jsx
MobileNav.jsx
sections/
Hero.jsx
TrustBar.jsx
ServicesGrid.jsx
IndustriesGrid.jsx
PartnerSection.jsx
ContactCTA.jsx
ui/
shadcn components
pages/
Home.jsx
About.jsx
Services.jsx
ServiceDetail.jsx
Industries.jsx
IndustryDetail.jsx
EightXEight.jsx
Contact.jsx
Support.jsx
lib/
api.js
queryClient.js
data/
services.js
industries.js
```
---
## Backend Stack
Use:
- **Express**
- **better-sqlite3**
### Suggested Backend Structure
```txt
server/
index.js
db/
connection.js
schema.sql
routes/
leads.js
support.js
health.js
services/
leadService.js
supportService.js
```
### Initial API Routes
```txt
GET /api/health
POST /api/leads
POST /api/support
GET /api/services
GET /api/industries
```
---
## Database Plan
Use SQLite through `better-sqlite3`.
### Initial Tables
```txt
leads
- id
- company
- name
- email
- phone
- zip
- message
- service_interest
- created_at
support_requests
- id
- name
- company
- email
- phone
- issue
- priority
- created_at
```
### Zoho Integration
Zoho should not drive the frontend anymore.
Recommended path:
1. Frontend submits to Express.
2. Express validates request.
3. Express stores submission in SQLite.
4. Optional later: backend forwards lead data to Zoho.
This keeps the website clean, testable, and controllable.
---
## New Visual Direction
## Brand Feel
Target vibe:
**Bright enterprise communications partner. Clean, trustworthy, modern, approachable, and premium.**
The site should feel less like a local IT website from the early 2000s and more like a serious communications, contact center, and infrastructure partner for modern businesses.
Because this is a business services website, the visual direction should be **light-first**, not fully dark/cyber. A mostly dark interface can look sleek, but it may also feel too niche, too technical, or too startup/gaming-adjacent for SMB and enterprise buyers. The better direction is a bright, polished base with strong navy sections and crisp blue/cyan accents.
## Recommended Color Scheme
### Primary Light-First Palette
```txt
Background: #F8FAFC
Section Alt: #EEF6FB
Card: #FFFFFF
Border: #D8E3EA
Text: #0F172A
Muted: #475569
Soft Text: #64748B
Primary Navy: #0B2A3C
Deep Navy: #071A2A
Trust Blue: #0EA5E9
Accent Cyan: #22D3EE
```
### Optional Warm Accent
```txt
Signal Gold: #F59E0B
```
Use gold sparingly for badges, stats, certification highlights, or key trust moments.
### Dark Usage Guidance
Use dark navy intentionally, not everywhere:
- Header or top navigation
- Hero section
- Footer
- CTA bands
- Certification/trust moments
Keep most body sections bright and readable:
- White cards
- Light blue-gray section backgrounds
- Dark readable text
- Blue/cyan action accents
This gives the site a modern 2026 look without making it feel like a cybersecurity, crypto, or gaming landing page.
---
## Layout Direction
This section is the primary design brief for Scarlett.
The layout should feel like a modern B2B technology services website: bright, structured, confident, and conversion-focused. Avoid the early-2000s pattern of giant logos, crowded nav, heavy gradients everywhere, oversized generic images, and repeated boxed sections without rhythm.
### Global Layout Principles
- Use a **light-first page body** with strategic dark navy moments.
- Use a consistent max-width container: approximately `1200px` to `1280px`.
- Use generous vertical spacing:
- Mobile sections: `64px` to `80px`
- Desktop sections: `96px` to `128px`
- Use a clear rhythm:
- Dark hero
- Light trust section
- White/soft-blue service sections
- Dark CTA band
- Light detail sections
- Dark footer
- Keep the site visually calm. Do not use too many competing gradients, glows, borders, and shadows at once.
- Cards should feel premium and clean, not like old Bootstrap panels.
- Prefer fewer stronger sections over many cramped sections.
- Every page should have one obvious primary action: usually `Request Consultation` or `Contact Us`.
### Header / Navigation Layout
Desktop header:
- Sticky top header.
- Dark navy or white header is acceptable, but it must be compact and polished.
- Logo should be normal-sized and aligned, not oversized or bleeding into content.
- Navigation should be single-line and calm:
```txt
Home
Services
Industries
8x8
About
Contact
Support
```
- Primary CTA button on the right:
- `Request Consultation`
- Use shadcn/ui `NavigationMenu` if dropdowns are retained.
- Avoid wrapping nav links.
- Avoid huge dropdown panels unless they add real clarity.
Mobile header:
- Use shadcn/ui `Sheet` for navigation.
- Menu should slide in cleanly.
- Primary routes appear first.
- Service and industry subroutes can appear under simple section labels.
- CTA button should be visible in the sheet.
### Home Page Layout
Recommended home page structure:
1. **Hero**
- Use a dark navy hero section with bright text.
- Large modern headline.
- Suggested headline:
`Modern Communications Infrastructure Without the Vendor Noise`
- Subheading focused on UCaaS, Contact Center, networking, deployment, and managed lifecycle support.
- Two CTAs:
- Primary: `Request Consultation`
- Secondary: `Explore Services`
- Right side visual:
- Use a refined communications/network image, abstract interface panel, or polished existing asset.
- Do not use a raw stock-image block that feels pasted in.
- Trust chips below copy:
- `8x8 Certified Partner`
- `Veteran Owned`
- `25+ Years Experience`
- `SMB to Enterprise`
2. **Trust / Certification Bar**
- Light section directly below hero.
- Include 8x8 partner logo or certification language.
- Purpose: quickly establish credibility before services.
- Keep it compact and horizontal on desktop, stacked on mobile.
3. **Services Preview**
- Bright section with white cards.
- 6-7 concise service cards.
- Each card should include:
- Icon or small visual marker
- Service name
- One-sentence value statement
- Subtle `Learn more` affordance
- Avoid large image tiles unless imagery is carefully cropped and consistent.
4. **Why Queue North**
- Three-pillar layout:
- `Architecture`
- `Deployment`
- `Lifecycle Support`
- This section should explain how Queue North works, not just what it sells.
- Recommended style: alternating light background with strong typography and small supporting cards.
5. **Industries**
- Healthcare
- Retail
- Manufacturing
- Education & Finance
- These should feel like solution pathways.
- Do not present them as generic stock categories.
- Each industry card should connect pain point → Queue North solution.
6. **Final CTA**
- Dark navy CTA band near bottom of page.
- Suggested copy:
`Tell us what you're trying to fix. We'll help map the path.`
- CTA button:
`Request Consultation`
### Inner Page Layouts
Every inner page should use a consistent pattern:
1. **Page Hero**
- Short headline.
- One paragraph explaining the page value.
- Optional badge, e.g. `Service`, `Industry`, or `8x8 Partner`.
2. **Main Content Section**
- Use a two-column layout on desktop when useful:
- Left: core explanation
- Right: card with key benefits, use cases, or CTA
- Stack cleanly on mobile.
3. **Supporting Cards**
- Use 3-card or 4-card grids for benefits, capabilities, or outcomes.
- Keep card heights balanced.
4. **CTA Footer Band**
- Each major page should end with a CTA leading to contact.
### Services Page Layout
The `/services` page should act as a service hub.
- Top page hero explains the whole service model.
- Follow with a card grid for all services.
- Each service card links to its detail route.
- Recommended service card structure:
```txt
[small icon]
Service Name
Short outcome-driven description
Learn more →
```
Service detail pages should include:
- Hero with service name and value proposition.
- Section: `What this solves`
- Section: `How Queue North helps`
- Section: `Ideal for`
- CTA: `Talk to us about this service`
### Industries Page Layout
The `/industries` page should explain that Queue North adapts communications and support to operational realities.
Industry detail pages should include:
- Hero with industry-specific value proposition.
- Pain points.
- Queue North solution approach.
- Relevant services.
- CTA.
### Contact / Support Layout
Contact and support pages must feel trustworthy and simple.
- Use shadcn/ui form primitives.
- Keep forms visually clean with clear labels.
- Use Sonner toast for success/error states.
- Avoid giant intimidating forms.
- Use a two-column desktop layout:
- Left: reassurance, contact expectations, phone/email if available
- Right: form card
- On mobile, form comes after the intro copy.
### Design Quality Bar
Scarlett should treat the design as unacceptable if it has any of these issues:
- Nav wraps on desktop.
- Logo is oversized or visually collides with content.
- Cards look like default boxes with no hierarchy.
- Text contrast is weak.
- Sections feel cramped.
- Mobile layout feels like a collapsed desktop site.
- Images are inconsistent in crop, tone, or quality.
- There is no clear CTA above the fold.
- The site feels like cybersecurity/gaming/crypto instead of business communications.
---
## Navigation Plan
Current dropdown navigation should be simplified.
### Desktop Navigation
```txt
Home
Services
Industries
8x8
About
Contact
Support
```
### Mobile Navigation
Use shadcn/ui `Sheet`.
Mobile nav should:
- Open cleanly from a menu button.
- Avoid wrapping links.
- Show primary routes first.
- Include service and industry routes in grouped sections if needed.
---
## Route Plan
Replace hash routing with React Router paths.
```txt
/
/about
/services
/services/unified-communications
/services/contact-center
/services/managed-support
/services/consulting-training
/services/infrastructure-cabling
/services/wireless-access
/services/local-networking
/industries
/industries/healthcare
/industries/retail
/industries/manufacturing
/industries/education-finance
/8x8
/contact
/support
```
---
## Component System
Use shadcn/ui primitives wherever available.
Required primitives:
- `Button`
- `Card`
- `Sheet`
- `Dialog`
- `Input`
- `Textarea`
- `Select`
- `Badge`
- `Accordion`
- `NavigationMenu`
- `Toaster` / Sonner integration
This will modernize interactions and keep the UI consistent.
---
## Content Model
Move repeated content into data files.
Suggested files:
```txt
client/src/data/services.js
client/src/data/industries.js
client/src/data/certifications.js
client/src/data/stats.js
```
Use these files to render:
- Service overview cards
- Service detail pages
- Industry cards
- Industry detail pages
- Footer links
- Navigation links
- Trust badges
This prevents duplication and keeps future edits simple.
---
## Scarlett Design Implementation Brief
### Tailwind Theme Tokens
Using the **light-first business palette** defined in OVERHAUL_PLAN.md:
```js
// tailwind.config.js theme extension
theme: {
extend: {
colors: {
background: '#F8FAFC',
'section-alt': '#EEF6FB',
card: '#FFFFFF',
border: '#D8E3EA',
text: '#0F172A',
muted: '#475569',
'soft-text': '#64748B',
primary: {
navy: '#0B2A3C',
'navy-dark': '#071A2A',
blue: '#0EA5E9',
cyan: '#22D3EE',
},
accent: {
gold: '#F59E0B',
},
},
fontFamily: {
sans: ['Inter', 'sans-serif'],
},
},
}
```
### Numeric Typography Rule
All numbers in the visual design should use **Georgia**. This applies to stats, counters, years, version displays, numeric badges, metrics, and prominent numeric callouts.
Implementation guidance:
- Add a reusable Tailwind font family such as `font-numeric` mapped to `Georgia, serif`.
- Use the numeric font only on numeric content.
- Do not switch body text, headings, nav, or general copy to Georgia.
### Typography Scale
```css
/* Base: 16px */
.text-xs: 12px / 16px
.text-sm: 14px / 20px
.text-base: 16px / 24px
.text-lg: 18px / 28px
.text-xl: 20px / 30px
.text-2xl: 24px / 36px
.text-3xl: 30px / 44px
.text-4xl: 36px / 52px
.text-5xl: 48px / 64px
```
### Section Spacing / Container Sizes
| Breakpoint | Container Max | Section Vertical Spacing |
|------------|---------------|--------------------------|
| Mobile | `100%` | `64px` / `80px` (bottom) |
| Desktop | `1200px` | `96px` / `128px` (bottom) |
Use `container mx-auto px-4 md:px-6 lg:px-8` pattern.
### Radius / Shadow / Border Rules
```css
/* Borders */
border: 1px solid border-color
rounded-lg: 8px
rounded-xl: 12px
rounded-2xl: 16px
/* Shadows */
shadow-sm: 0 1px 2px 0 rgb(0 0 0 / 0.05)
shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1)
shadow-md: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1)
shadow-lg: 0 10px 15px -3px rgb(0 0 0 / 0.1), 0 4px 6px -4px rgb(0 0 0 / 0.1)
/* Cards */
- White background
- subtle border radius (12px)
- light shadow
- no heavy borders
```
### shadcn/ui Components to Use
Required primitives from `@/components/ui/`:
- `Button` — primary/secondary/callouts
- `Card` — service cards, industry cards
- `Sheet` — mobile navigation
- `Input`, `Textarea`, `Select` — forms
- `Badge` — certifications, status indicators
- `Accordion` — FAQ or details sections
- `NavigationMenu` — desktop nav (optional if simple)
- `Toast` / `Toaster` — success/error feedback
- `Dialog` — optional modal content
### Home Page Layout Blueprint
**1. Hero (Dark Navy)**
- Full-width, dark background (`bg-primary-navy`)
- Max-width container (`1200px`)
- Two-column desktop: copy left, visual right
- Mobile: stacked, copy first
- Headline: `Modern Communications Infrastructure Without the Vendor Noise`
- Subhead: UCaaS, Contact Center, Deployment, Lifecycle
- Two CTAs: Primary (`Request Consultation`), Secondary (`Explore Services`)
- Trust chips below: 8x8 Partner, Veteran Owned, 25+ Years, SMB to Enterprise
**2. Trust Bar (Light Section)**
- Background: `bg-section-alt`
- Horizontal center-aligned icons/logos
- Mobile: stacked, centered
**3. Services Grid (White Cards)**
- Background: `bg-background`
- Grid: 2 cols mobile, 3 cols tablet, 4 cols desktop
- Each card: icon, name, 1-sentence value, subtle `Learn more`
- Shadow: `shadow-sm`
**4. Why Queue North (Three Pillars)**
- Alternating light/dark sections optional
- Card grid: `Architecture | Deployment | Lifecycle Support`
- Light background with navy accent text
**5. Industries Preview (Solution Pathways)**
- Background: `bg-section-alt`
- Grid: Healthcare, Retail, Manufacturing, Education & Finance
- Each card: pain point → Queue North solution
- 2 cols mobile, 4 cols desktop
**6. Final CTA (Dark Band)**
- Dark navy background
- Centered copy: `Tell us what you're trying to fix. We'll help map the path.`
- Single CTA: `Request Consultation`
### Service / Industry Detail Layout Blueprint
**Page Hero**
- Section background: `bg-background`
- Left-aligned headline + short intro paragraph
- Optional badge (Service / Industry / 8x8 Partner)
**Main Content (Two-Column Desktop)**
- Desktop: Left = core explanation, Right = benefits/CTA card
- Mobile: stacked
- Left column: `prose` or clean `p + ul` text
- Right column: Card with checklist, use cases, or brief differentiators
**Supporting Cards Grid**
- 3 or 4 cards
- Icons, short titles, 1-sentence descriptions
- Grid: 1 col mobile, 2 col tablet, 3 col desktop
**CTA Footer Band**
- Each major page ends with CTA
- Dark navy section
- Centered copy + primary button
### Contact / Support Form Layout
**Desktop: Two-Column**
- Left: reassurance copy, phone/email if available, trust badges
- Right: Form Card
- Background: `bg-background`
**Mobile: Stacked**
- Copy first
- Form second
- Single-column input stacking
**Form Components**
- `Input` — name, company, email, phone, zip (if needed)
- `Textarea` — message or issue description
- `Select` — service interest or priority (if applicable)
- `Button` — Submit with loading state
- `Toast` — success/error via Sonner
### Responsive / Mobile Behavior
**Mobile First Rule**
- Sections stack vertically
- Grids: 1 col → 2 col → 3+ col
- Nav: `Sheet` menu slides in from right
- Buttons full-width on mobile, constrained width on desktop
- Images: full-width or max `max-w-full`, object-cover
**Typography Scaling**
- Headlines shrink for mobile (e.g., `text-4xl md:text-5xl`)
- Body text: `text-base` minimum
- Ensure contrast ratio ≥ 4.5:1
**Spacing Rhythm**
- Mobile section padding: `py-16` (64px)
- Desktop section padding: `py-24` (96px)
- Card padding: `p-4 md:p-6`
### Asset / Image Treatment
**Guidelines**
- Images: consistent aspect ratio (16:9 or 4:3 for hero)
- Avoid inconsistent stock-photo quality
- Use `object-cover` for hero banners
- For card visuals, use consistent sizing and cropping
- Replace generic stock with custom illustrations or refined photos
**Current Assets Check**
- Review `assets/` folder
- Confirm logo PNG/SVG at 2x size for retina
- Favicon: 32px, 48px, 180px (iPhone), 192px (Android)
- Replace placeholder images with clean B2B visuals
### Explicit Anti-Patterns to Avoid
❌ Nav wraps on desktop (single line only)
❌ Oversized logo bleeding into content
❌ Cards with default Bootstrap-style borders
❌ Weak text contrast (dark gray on white, light gray on white)
❌ Sections feeling cramped or inconsistent spacing
❌ Mobile layout feeling like collapsed desktop (no mobile-first grid)
❌ Images inconsistent in crop, tone, or quality
❌ No clear primary CTA above the fold on home
❌ Dark navy used everywhere (feels crypto/cyber/gaming instead of business)
❌ Gradient overlays on every section
❌ Multiple competing typefaces
❌ Large font sizes without line-height spacing
---
## Phase-Based Versioning
Version numbers must correlate directly to the active overhaul phase.
- **Phase 1** uses `0.1.x`
- First Phase 1 release: `0.1.0`
- Every completed agent pass/checkpoint within Phase 1: `0.1.1`, `0.1.2`, etc.
- **Phase 2** uses `0.2.x`
- First Phase 2 release: `0.2.0`
- Iterations/fixes within Phase 2: `0.2.1`, `0.2.2`, etc.
- **Phase 3** uses `0.3.x`
- **Phase 4** uses `0.4.x`
- **Phase 5** uses `0.5.x`
Rule: the minor version maps to the phase number; the patch version maps to each completed task batch after the full pipeline finishes. Dispatch a task batch, run it through the required agents, then push that completed batch once. Example: Docker task batch goes through Neo → Private Hudson → Bishop → Ripley, then pushes as `0.2.1`. Notes/tags should use the version number only, e.g. `0.2.1`.
2026-05-12 01:10:34 -05:00
---
## Migration Phases
## Phase 1: Scaffold the Stack
Goals:
- Create Vite React app.
- Add Tailwind CSS.
- Add shadcn/ui.
- Add React Router.
- Add Sonner.
- Add TanStack Query.
- Create Express server.
- Add better-sqlite3.
- Set up development scripts.
Result:
- Frontend boots.
- Backend boots.
- API health check works.
- Frontend can call backend.
---
## Phase 2: Rebuild Layout
Goals:
- Build application shell:
- Header
- Footer
- Layout wrapper
- Mobile navigation
- Build route pages.
- Port existing business content into React components.
- Replace hash routing with React Router.
- Move repeated content into data files.
2026-05-12 01:18:57 -05:00
- Remove legacy `styles.css` file.
2026-05-12 01:10:34 -05:00
Result:
- Site content exists in the new React app.
- Routes are clean and shareable.
- Structure is maintainable.
2026-05-12 01:18:57 -05:00
- Old global stylesheet removed.
2026-05-12 01:10:34 -05:00
---
## Phase 3: Visual Overhaul
Scarlett owns this phase.
Goals:
- Define Tailwind theme tokens.
- Apply new color system.
- Improve typography.
- Improve spacing scale.
- Build responsive-first layouts.
- Replace dated cards/sections with modern component patterns.
- Improve logo/header placement.
- Remove layout jank.
- Ensure mobile experience feels intentional.
Result:
- Website feels modern, premium, and trustworthy.
- Visual system is reusable across pages.
---
## Phase 4: Forms + Backend
Goals:
- Replace inline Zoho iframe form with React form.
- Submit contact requests to Express API.
- Submit support requests to Express API.
- Save submissions in SQLite.
- Use Sonner for success/error messages.
- Add validation.
- Optional later: forward leads to Zoho from backend.
Result:
- Forms are owned by the application.
- Leads/support requests are stored locally.
- UX is cleaner and easier to test.
---
## Phase 5: Verification
Bishop owns verification.
Goals:
- Confirm frontend build works.
- Confirm backend starts.
- Confirm all routes load.
- Confirm mobile navigation works.
- Confirm contact form submits.
- Confirm support form submits.
- Confirm SQLite writes succeed.
- Confirm no obvious console errors.
- Confirm basic accessibility expectations.
- Update project documentation.
Result:
- Rebuild is tested and documented.
---
## Agent Plan
Recommended pipeline:
1. **Scarlett**
- Create design direction.
- Define Tailwind theme.
- Define layout system and component expectations.
2. **Neo**
- Scaffold Vite + React + Express + SQLite.
- Build API/database foundation.
- Convert static site into structured app.
3. **Scarlett**
- Polish UI implementation.
- Enforce shadcn/ui and Tailwind standards.
- Review responsive behavior and visual quality.
4. **Bishop**
- Verify build/runtime/routes/forms.
- Update docs.
5. **Ripley**
- Final test.
- Commit and push.
---
## Recommendation
```txt
Design system first → scaffold/build → polish → verify
```
---
## Success Criteria
The overhaul is successful when:
- The site no longer looks or feels early-2000s.
- The app runs on the requested stack.
- Routing uses React Router, not hash switching.
- Styling uses Tailwind, not a giant global stylesheet.
- shadcn/ui primitives are used for common UI elements.
- Contact/support forms submit through Express.
- Form submissions are stored in SQLite.
- The site is responsive and polished on mobile.
- The content still clearly communicates Queue North's services, 8x8 partnership, and operational expertise.