Q-NOT Prototype — Project README

This is a static, front-end-only prototype of Q-NOT, an Operational Intelligence Platform for managing appointments, queues, events, and guests. It's built with plain HTML, CSS, and JavaScript — no framework, no build step, no backend. Every page is a real .html file you can open directly in a browser.

This README explains what's inside every single file, what it's responsible for, and what you can safely change if you want to customize colors, text, layout, or add new pages.

---

1. How to open this project

If you want live-reload while editing (recommended if you're making a lot of changes), you can use the VS Code "Live Server" extension,

Important: Don't move or rename the css/ and js/ folders, or the HTML files won't find their styles/scripts. The link paths are relative (e.g. ../css/main.css from inside a subfolder), so the folder structure has to stay intact.

---

2. Folder structure — the big picture

qnot-prototype/
├── index.html                       ← Marketing homepage
├── product.html                     ← Marketing: product/modules page
├── pricing.html                     ← Marketing: pricing + contact form
├── login.html                       ← Login screen (routes to all 3 portals)
├── README.md                        ← This file
│
├── css/
│   ├── main.css                     ← Design tokens + global styles (used on EVERY page)
│   ├── marketing.css                ← Styles only for marketing + customer portal pages
│   └── dashboard.css                ← Styles only for the sidebar app pages (org/staff)
│
├── js/
│   ├── data.js                      ← All fake/mock data (names, numbers, appointments)
│   └── main.js                      ← Shared behavior (active nav highlight, charts, toasts)
│
├── org-dashboard/                   ← Portal 1: for the organization admin
│   ├── dashboard.html               ← Overview page with KPIs and charts
│   ├── appointments.html            ← Table of all appointments
│   ├── queue.html                   ← "Mission control" queue board
│   └── analytics.html               ← Deeper analytics + AI insight cards
│
├── staff-portal/                    ← Portal 2: for doctors/consultants/staff
│   ├── my-appointments.html         ← Staff's own schedule for today
│   └── current-customer.html        ← Detail view of the customer being served
│
└── customer-portal/                 ← Portal 3: for the end customer/patient
    ├── home.html                    ← Search for an organization
    ├── organization-profile.html    ← Org's "mini website" (services, hours, etc.)
    ├── booking.html                 ← Appointment booking form
    ├── confirmation.html            ← Booking confirmation + fake QR code
    └── queue-tracking.html          ← Live queue position tracker

The mental model: this is one "marketing site" (the 4 root .html files) that links out to three separate "logged in" experiences (the three folders). In a real product, each of those three folders would sit behind actual authentication. Here, login.html just has three buttons that jump straight to each one — there's no real auth.

---

3. CSS files — what each one does

css/main.css — the foundation (loaded on every single page)

This is the most important file. It defines:

• Design tokens (CSS variables) at the very top, inside :root { ... }. This is where all colors, spacing, and fonts live. If you want to change the whole app's color scheme, you only need to edit this one place:

  --ink: #132420;        /* main text color */
  --teal: #0F6E56;       /* primary action color (buttons, links) */
  --bg: #F6F5F1;         /* page background */
  --panel: #FFFFFF;      /* card/panel background */
  --amber, --coral, --purple  /* status colors: waiting / delayed / serving */

  Every other CSS file and every inline style in the HTML references these variables (e.g. color: var(--teal)), so changing a value here updates it everywhere automatically.

• Typography — two fonts are loaded from Google Fonts: Fraunces (the serif used for headlines, h1/h2/h3) and Inter (the sans-serif used for body text and UI). If your teammate wants a different headline font, she just needs to change the @import URL at the top and the --font-display variable.

• Layout primitives — reusable utility classes like .container (centers content, max-width 1200px), .section (vertical page padding), .flex, .grid, .gap-16, etc. These are used throughout every page instead of writing custom CSS for each one.

• Buttons — .btn-primary (solid teal), .btn-secondary (white with border), .btn-ghost (no background, just text). Also .btn-sm / .btn-lg for size, and .btn-block for full width.

• Cards — .card is the white bordered box used everywhere (KPI cards, feature cards, tables). .card-hover adds a lift effect on hover.

• Status badges — .badge-completed (green/mint), .badge-waiting (amber), .badge-serving (purple), .badge-delayed (coral). These are used any time you see a colored pill like "Waiting" or "Completed" next to a customer.

• Navbar & footer styles — used on the marketing pages.

• The "rail" component — this is the signature visual element of the whole prototype: a dotted horizontal line with dots that represents progress through a journey (Booked → Checked In → Waiting → Serving → Done). You'll see it on the homepage hero, the product page, and the live queue tracking page. If your teammate wants to reuse this rail somewhere else, she just needs to copy the .rail / .rail-fill / .rail-step HTML structure (examples are in queue-tracking.html and index.html).

• Responsive breakpoints at the bottom (@media queries) that stack things vertically on smaller screens.

css/marketing.css — marketing site + customer portal look

Loaded alongside main.css on: index.html, product.html, pricing.html, login.html, and all 5 files inside customer-portal/.

Contains:

• .hero and .hero-inner — the big two-column intro section on the homepage.
• .feature-grid / .feature-card — the 3-column module cards ("Appointment Scheduling", "Queue Management", etc.)
• .industry-grid / .industry-card — the "Solutions" section cards.
• .pricing-grid / .price-card — the 3 pricing plan cards, including .price-card.featured which adds the teal border and "Most popular" ribbon on the middle plan.
• .testimonial-card — the quote block.
• .cta-band — the dark call-to-action section near the bottom of pages.
• .form-card / .form-group — the styling for the login form and contact form.

If your teammate is only editing marketing copy (text), she won't need to touch this file at all — just the HTML.

css/dashboard.css — the app shell for logged-in pages

Loaded alongside main.css on all pages inside org-dashboard/ and staff-portal/.

Contains:

• .app-shell — the 2-column grid (sidebar + main content) used on every dashboard page.
• .sidebar / .sidebar-link / .sidebar-link.active — the left navigation. The .active class is what highlights the current page (this is actually added automatically by JavaScript, explained below).
• .kpi-grid / .kpi-card — the small stat cards at the top of dashboards ("Appointments Today: 128").
• .chart-placeholder / .chart-bar — a very simple CSS-only bar chart (no charting library used, just divs with heights).
• Table styles (table, thead, tbody) — used on the Appointments page.
• .toolbar / .search-input / .filter-chips — the search bar and filter pills above tables.
• .queue-board / .queue-col / .ticket-card — the 4-column "mission control" board on the Queue Management page (Waiting / Called / Serving / Completed columns).

---

4. JavaScript files — what each one does

js/data.js — all the fake data in one place

This file is just one big JavaScript object called QNOT_DATA. It holds every mock number, name, and status shown across the prototype: appointments, queue tickets, staff list, KPI numbers, AI insight text, etc.

Important honesty note: right now, the HTML pages do not actually read from this file — the numbers are typed directly into each HTML page as plain text. data.js is loaded on every page (via <script src="../js/data.js">) so it's available in the browser console for testing/reference, and so that if your teammate wants to make the pages actually dynamic later (e.g. using JavaScript to fill in the table instead of hardcoding it), the data is already structured and ready to be pulled from. Think of it as the "future database" placeholder.

If she wants to change a number that shows on multiple pages (like the average wait time), she currently has to search-and-replace it across each .html file where it appears, since they're not wired to this file yet.

js/main.js — shared page behavior

Three small things happen here on every page load:

1. Active sidebar link highlighting — it checks the current page's filename and adds the .active CSS class to the matching sidebar link, so the current page is highlighted in the left nav automatically. Your teammate doesn't need to manually mark any link as "active" in the HTML.

2. renderChartBars() — looks for any element with a data-chart="40,55,48,70..." attribute and turns those numbers into little CSS bar chart divs. This is what powers the "Appointments per day" charts. To change the chart data, just edit the numbers inside the data-chart="..." attribute directly in the HTML.

3. simulateAction(message) — a helper function that shows a small black "toast" popup at the bottom of the screen for 2.2 seconds. This is used on buttons like "Call Next" or "Mark Complete" to simulate something happening, since there's no real backend. You'll see it called like onclick="simulateAction('Called A-014')" directly in the HTML.

---

5. The HTML pages — what's on each one, and what to edit

Marketing site (root folder)

index.html — Homepage.

• Hero section with headline, subtext, and two CTA buttons ("Book a Demo", "Start Free Trial"). This is the first thing anyone sees — if your teammate wants to change the core pitch, this is the section to edit.
• A live mock "hero visual" card showing a fake live queue with the rail progress component.
• A logo strip (Healthcare / Education / Government / Corporate / Events).
• A 6-card feature grid describing each Q-NOT module.
• A "Solutions" section with 6 industry cards.
• A testimonial quote block (currently a placeholder quote — replace with a real one later).
• A dark CTA band near the bottom.
• Footer with site links.

product.html — Deeper product explainer.

• Two large feature rows (Appointment Management, Queue Management) with mock UI snippets next to the text.
• A 6-card grid covering the remaining modules (Check-in, Events, Guests, Communication, Operational Intelligence, AI Insights).
• CTA band at the bottom.

pricing.html — Pricing + contact form.

• 3-column pricing table: Starter / Professional (marked "Most popular") / Enterprise.
• A contact form below with Name / Email / Organization / Message fields and a "Book a Demo" button that triggers the toast popup (it doesn't actually send anything anywhere — there's no backend).

login.html — Fake login screen.

• A form with a pre-filled fake email/password (since there's no real authentication).
• Three buttons that go straight to each portal: Organization Dashboard, Staff Portal, Customer Portal.
• A note reminding the viewer this is a prototype and any credentials "work."

---

Organization Dashboard (org-dashboard/)

dashboard.html — The main landing page after "logging in" as an org admin.

• 4 KPI cards: Appointments Today, People Waiting, Average Wait Time, Customers Served.
• A weekly appointments bar chart (uses the data-chart trick from main.js).
• A "Staff Online" list showing who's serving/online/offline.
• A "Recent Activity" table showing the latest 4 appointments with status badges.

appointments.html — Full appointments table.

• A search bar (visual only — doesn't actually filter yet) and filter chips (All / Waiting / Serving / Completed / Delayed).
• A full table: ID, Customer, Service, Time, Assigned Staff, Status, and a "View" button per row.
• To add a new appointment row, just copy one <tr>...</tr> block and edit the text inside.

queue.html — The "mission control" queue board.

• 4 columns: Waiting, Called, Serving, Completed — each showing "ticket cards."
• Buttons like "Call", "Skip", "Complete", "Transfer" all trigger the simulateAction() toast popup rather than actually moving tickets between columns (since there's no backend logic wired up yet — this would be the next thing to build if this becomes a real app).

analytics.html — Deeper analytics + AI insights.

• 4 more KPI cards (Customer Satisfaction, No-show Rate, Busiest Hour, Top Service).
• A chart + staff performance list.
• 4 "AI Insight" cards at the bottom (Pattern / Recommendation / Alert / Trend) — these are static text describing example AI-generated suggestions, meant to sell the future vision of the product rather than being a real, working AI feature.

---

Staff Portal (staff-portal/)

my-appointments.html — A staff member's (Dr. Femi Ajayi's) daily schedule.

• 3 small KPI cards (Appointments Today, Avg Service Time, Feedback Score).
• An "Upcoming" table with an "Open" button per row (the top row links to current-customer.html).
• A "Completed today" table below it.

current-customer.html — Detail view of the customer currently being served.

• Customer name, avatar initials, reason for visit, referring staff.
• An editable notes textarea (pre-filled with example notes).
• 3 action buttons: Mark Complete, Transfer, Call Next — all trigger toast popups.
• An "Up next" preview card at the bottom.

---

Customer Portal (customer-portal/)

This is the end-customer-facing journey, meant to be walked through in order:

home.html — Search/landing page.

• A search bar (pre-filled with "ABC Diagnostic").
• 3 clickable result cards for different organizations (ABC Diagnostic Centre, University of Lagos, Embassy of Canada) — only the first one is fully wired into the rest of the flow; the other two are visual variety and link to the same profile page.

organization-profile.html — The organization's "mini website" inside the app.

• Org name, rating, hours, and 3 action buttons (Book Appointment / Join Queue / Contact).
• A services grid (Blood Test, MRI Scan, etc. with duration + price).
• An "About" blurb.
• A sidebar with current wait time, hours, and address.

booking.html — The appointment booking form.

• Dropdowns for Service and Preferred Staff.
• Date picker and Time dropdown.
• Optional notes field.
• "Confirm Booking" button → goes to confirmation.html.

confirmation.html — Booking confirmation screen.

• A green checkmark icon and confirmation message.
• A fake QR code — this is just a CSS pattern (repeating-conic-gradient), not a real scannable QR code. If your teammate wants a real-looking QR code image, she should replace that div with an actual QR code image or a QR-generating JS library later.
• A summary box (Appointment ID, Service, Date, Time, Branch).
• Buttons: Add to Calendar (toast only), Track Live Queue (goes to queue-tracking.html), Back to Home.

queue-tracking.html — Live queue position tracker.

• Ticket number in large text.
• The rail progress component again, showing "Waiting" as the current step.
• 3 stat cards: position in line, estimated wait, who's currently being served.
• A note about WhatsApp notifications (text only, not a real integration).

---

6. What's real vs. what's just for show

Since this is a prototype for demo purposes, it's worth being upfront with your teammate about what's actually functional vs. what's just there to tell the story:

Feature	Status
Page navigation (links between pages)	✅ Fully working
Colors, fonts, layout, responsiveness	✅ Fully working
Search bars, filter chips	❌ Visual only, don't filter anything
"Call Next" / "Mark Complete" / "Add to Calendar" buttons	❌ Show a toast popup only, don't change any data
QR code on confirmation page	❌ Fake pattern, not a real scannable code
Charts	❌ Simple CSS bars driven by hardcoded numbers, not a real charting library
Contact/login forms	❌ Don't submit anywhere, no validation
Data in data.js	⚠️ Present but not yet connected to the HTML — see note in section 4

---

7. Common things your teammate might want to change

Change the accent/brand color everywhere: Edit the --teal and --teal-deep values in css/main.css (top of file). Everything referencing that variable updates automatically.

Change the headline/body font: Edit the Google Fonts @import line and the --font-display / --font-body variables at the top of css/main.css.

Add a new page to a portal (e.g. a new dashboard page):

1. Copy an existing file in that folder (e.g. copy org-dashboard/analytics.html to org-dashboard/settings.html).
2. Update the <title> and the main content.
3. Add a new <a href="settings.html" class="sidebar-link"> line to the sidebar <nav> block in every page in that folder (since the sidebar is currently repeated in each file rather than shared).

Change mock names/numbers: Right now, most of the shown data is typed directly into each HTML file, so changes have to be made per-page. js/data.js has the same information available in one place for reference or for later wiring into the actual page content with JavaScript.

Add a real chart library: Replace the .chart-placeholder divs and renderChartBars() logic with something like Chart.js if more realistic charts are needed later.

---

8. Quick file checklist for a first-time walkthrough

If your teammate only has 10 minutes, tell her to open these 5 files in this order to get the full story:

1. index.html — the pitch
2. login.html — the entry point
3. org-dashboard/queue.html — the "mission control" screen (most impressive one)
4. customer-portal/booking.html → confirmation.html → queue-tracking.html — the customer's side of the same story
5. org-dashboard/analytics.html — the "AI Insights" cards at the bottom, which sell the future vision

That's the entire loop the real spec describes: a customer books → checks in → waits in a live queue → gets served → and the organization sees it all reflected in real-time analytics.