eCampus Redesign

The brief

NSCC's eCampus website is the front door to the college's online learning resources — program information, course catalogs, login paths into the learning management system. For a publicly-funded community college, that site has to do three things well: load fast on the networks students actually have, meet accessibility standards as a matter of law and ethics, and be findable through search.

In Winter 2026, I joined a five-person Work-Integrated Learning team tasked with redesigning it. My role was Senior Dev / Architect — owning the technical proposal, the scaffold, the deployment pipeline, and the engineering decisions that would carry the project from audit through to a living site. Sponsor: Michael Purcell. Faculty supervisor: Nadia Gouda. My teammates: Shayne McNeil (PM), Krishna Priyanka Garikapati (Design Lead), Dawson Brown (Dev/Research Lead).

The audit

Before proposing anything, I needed to know exactly what was wrong with the existing site. It was built on Articulate Rise — a platform designed for SCORM-packaged training content, not for serving as a public-facing institutional website. Three numbers from the audit set the agenda for everything that followed.

6.6 MB initial payload. A healthy modern landing page weighs in around 1–2 MB. Six-plus megabytes means students on slower rural connections — common across much of Nova Scotia — wait a long time for content to appear, or give up before it does.

21 WCAG 1.1.1 violations. WCAG 1.1.1 is the most fundamental success criterion in the standard: every non-text element needs a text alternative. Twenty-one violations on a single site is the kind of finding that turns into a formal complaint and a remediation order.

Blocked from search indexing. The site's robots configuration was preventing Google from crawling it. A community college's program page cannot be invisible.

Heavy, inaccessible, and invisible. The audit became the proposal.

The proposal

With the audit in hand, I drafted the architecture proposal. Three constraints drove it: static-first for performance, semantic HTML and ARIA for accessibility, and clean URLs with proper metadata for indexability.

I chose Astro as the framework. Its island-architecture model ships zero JavaScript by default, which directly attacks the payload problem. Its component model gives a single source of truth for things like the navigation and footer — the existing site had multiple drifting copies of the same chrome. And its first-class TypeScript support meant we could enforce typed content models for catalog data instead of relying on copy-paste.

For deployment, Vercel — for the preview-per-PR workflow and the edge network. For content, I argued for centralizing data in typed files (with a future CMS path) so program updates would flow from one place out rather than being maintained across dozens of pages.

Phase 2: scaffold and ship

Once the proposal was approved, my Phase 2 deliverable was the working foundation: the Astro scaffold, the base layouts and design-token system, the CI/CD wiring through Vercel, and the documentation a future maintainer would need to extend it. The initial PR landed on main ahead of the May handoff.

The deploy preview from Vercel ran on every PR after that, which meant the design lead and research lead could see exactly what changed, and the sponsor could check progress without me needing to push something to staging.

The results

A second Lighthouse audit was captured against the redesigned site on May 26, 2026 — the day of project handoff, using the same methodology as the May 7 baseline. Every category moved in the right direction:

• Performance: 27 → 95 (+68)
• SEO: 54 → 92 (+38; indexable, meta description present)
• Best Practices: 96 → 100
• Accessibility (Lighthouse): 100 → 100

The Core Web Vitals tell the same story more concretely. Largest Contentful Paint — the most user-visible loading metric — dropped from 7.5 seconds to 1.3 seconds, an 83% reduction. Total Blocking Time fell from 1,410 ms to zero, indicating the redesign no longer ships a JavaScript bundle large enough to monopolize the main thread. The 6.6 MB payload is no longer flagged as enormous; JavaScript execution time, main-thread work, and long tasks all dropped below Lighthouse's reporting threshold. The site moved from the lowest Performance band (0–49) to the highest (90–100) in three weeks.

An honest note on accessibility. Lighthouse's accessibility score is necessary but not sufficient for full WCAG 2.1 conformance — its automated rules catch only a subset of issues. The 21 WCAG 1.1.1 violations identified in the baseline originated from Articulate Rise's lesson-navigation template, which doesn't exist in the new architecture, so structurally they no longer apply. A full Deque axe scan of the redesign is the open item that closes out the accessibility comparison.

What it taught me

The audit is the proposal. I came into this expecting to spend most of my time writing code. The most leveraged work was actually the audit phase — quantifying the existing site's problems concretely enough that every architectural decision afterward had a measurable target. "Make it faster" is a feeling. "Cut payload from 6.6 MB to under 1.5 MB" is a brief.

Architecture is partly a communication artifact. A good proposal isn't just a tech-stack list — it's a document that lets a designer, a PM, a sponsor, and another developer agree on what the system is going to be, before there's any system to disagree about. The scaffold I shipped was the proposal made literal.

Shipping a foundation is its own deliverable. On a fixed-term WIL placement, my output wasn't a finished marketing site — it was an architecture and scaffold that the next iteration of the team could build into. Being clear about that scope, in the docs and the handoff, mattered more than trying to claim credit for everything that would eventually live on the URL.