Saltus – Topeka Police Department CMS

Web Designer – Individual Contributor · 2016 · 5 months · 1 person · 7 min read

Independently built a full CMS frontend for the Topeka Police Department from designer-supplied Photoshop files — delivering a pixel-accurate, semantically structured, and publicly accessible web interface in HTML, SCSS, and JavaScript within a five-month engagement

Overview

Delivered the complete frontend build of a Content Management System for the Topeka Police Department — a public-sector law enforcement agency in Kansas, USA. Working as an individual contributor from designer-supplied Photoshop (PSD) files, translated static design assets into a fully functional, semantic, and accessible CMS interface using HTML, SCSS, and vanilla JavaScript. The platform serves as the public-facing and internal content management tool for the department, handling announcements, incident reporting, resource pages, and community communications.

Problem

The Topeka Police Department needed a CMS that could serve two distinct audiences — the general public seeking law enforcement information and resources, and department staff managing content internally. The existing digital presence lacked the structure, visual credibility, and usability expected of a modern public institution. Design had been completed by a specialist designer and supplied as Photoshop files, but required a disciplined web designer to translate those static assets into a maintainable, semantically correct, and accessibility-conscious web interface — without a framework, a design system, or a pre-existing codebase to build from.

Constraints

  • No frontend framework — built entirely in vanilla HTML, SCSS, and JavaScript
  • Design delivered as static Photoshop files — implementation required accurate interpretation and translation to code
  • Public sector context demands high accessibility standards and cross-browser compatibility
  • Solo delivery across the full frontend build within a five-month timeline
  • CMS must be navigable and operable for non-technical department staff managing content
  • Government and law enforcement context requires a trustworthy, professional visual tone — no deviation from supplied design specifications

Approach

Began by thoroughly analysing the Photoshop files — identifying the component inventory, spacing system, typographic scale, and color palette embedded in the design — and translating these into a structured SCSS token and component architecture before writing any page-level code. This front-loaded design analysis ensured consistent implementation across all CMS modules and reduced the need for retrospective style corrections. Built the interface module by module, validating each against the PSD at multiple viewport sizes. Applied semantic HTML throughout, ensuring the structure was meaningful to screen readers and search engines independent of the visual layer. JavaScript was used sparingly and purposefully — for interactive UI patterns such as navigation menus, modal dialogs, form validation, and dynamic content toggling.

Key Decisions

Extract a SCSS token and component system from the Photoshop files before building pages

Reasoning:

Building page by page directly from PSD files without first establishing shared tokens and components leads to duplicated values, inconsistent spacing, and styles that are expensive to update globally. Spending the first phase of the engagement extracting color, typography, and spacing values into SCSS variables and building a small component library ensured every page was built from a consistent foundation — and meant any design change only needed to be made in one place.

Alternatives considered:
  • Build page by page with inline and per-page styles
  • Use a third-party framework (Bootstrap) and adapt to the design
  • Extract tokens after all pages are built as a refactor pass

Semantic HTML as the structural foundation, with JavaScript added only where necessary

Reasoning:

In a public sector context, the CMS needed to be accessible to the widest possible range of users — including those on assistive technologies — and indexable by search engines for public information discoverability. Semantic HTML provides both by default. Keeping JavaScript minimal and purposeful also meant the interface remained functional for users with JavaScript disabled or on slow connections, which is a realistic scenario for members of the public accessing government resources.

Alternatives considered:
  • Component-heavy JavaScript with the HTML generated dynamically
  • jQuery-driven interface with DOM manipulation for all interactions
  • Single-page application architecture (disproportionate for a CMS of this scale)

Pixel-accurate PSD-to-code translation with responsive adaptation

Reasoning:

The designer had supplied complete Photoshop files representing the intended visual output. Deviating from these specifications without designer input would have produced an inconsistent product and undermined the design investment already made. Pixel-accurate implementation — with responsive adaptations applied at breakpoints where the fixed-width PSD layout needed to reflow — honoured the design intent while ensuring the interface worked across device sizes not represented in the static files.

Alternatives considered:
  • Interpret PSD loosely and make independent design decisions
  • Build desktop layout only with no responsive considerations
  • Request redesigned assets for each breakpoint before building

Tech Stack

  • HTML5
  • SCSS
  • JavaScript (ES6)
  • CSS Custom Properties
  • Responsive Design
  • Photoshop (PSD to code)
  • Cross-browser compatibility

Result & Impact

  • Solo contributor, 5 months
    Delivery Model
  • PSD to production-ready HTML/SCSS/JS
    Source Assets
  • Zero — vanilla stack
    Framework Footprint
  • Public sector law enforcement
    Context

The Topeka Police Department CMS delivered a professional, credible digital presence appropriate for a public law enforcement institution. The pixel-accurate implementation of the designer's vision produced a visually trustworthy interface that aligned with the department's communication standards. Semantic structure and accessibility-conscious markup ensured the platform served the broadest possible public audience, including users on assistive technologies. The SCSS component architecture established during the build provided a maintainable foundation for future content and feature additions without requiring a full frontend overhaul.

Learnings

  • PSD-to-code translation requires extracting the design system before writing CSS
  • Public-sector projects need semantic HTML as a baseline accessibility requirement
  • Vanilla JavaScript keeps interactivity deliberate and the interface leaner than a framework-heavy build
  • A week of upfront planning and component architecture saves weeks of inconsistent rework
  • Government UI must prioritise authority, clarity, and restraint over visual flashiness
  • Responsive PSD adaptation is about reflowing content thoughtfully, not just scaling it

PSD to Production

Translated the complete designer-supplied Photoshop specification into a production-ready frontend:

  • Design asset analysis — extracted color palette, typographic scale, spacing rhythm, and component inventory from the PSD files before writing a single line of code
  • SCSS token architecture — color, typography, and spacing values codified as SCSS variables and custom properties, forming a single source of truth for the entire CMS
  • Component library build — reusable HTML and SCSS components (navigation, cards, tables, forms, alerts, modals) built once from the PSD spec and consumed consistently across all CMS modules
  • Pixel-accurate implementation — each module validated against the Photoshop source at the designed viewport width before responsive adaptation was applied
  • Asset optimisation — images, icons, and graphical elements extracted from PSDs and optimised for web delivery

CMS Interface & Module Build

Built the full range of CMS modules required for department content and public communications management:

  • Public-facing pages — department announcements, incident alerts, community resources, and contact information, structured for clarity and easy scanning by members of the public
  • Content management interface — internal dashboard enabling non-technical department staff to create, edit, and publish content without developer intervention
  • Navigation and wayfinding — multi-level navigation with accessible keyboard support and clear active state indicators across the CMS hierarchy
  • Forms and data entry — incident reporting forms, contact forms, and content submission interfaces with client-side validation and clear error messaging
  • Dynamic UI components — modal dialogs, accordion panels, notification banners, and dropdown menus built in vanilla JavaScript with progressive enhancement

Semantic Structure & Accessibility

Applied semantic and accessible frontend practices appropriate for a public-sector platform:

  • Semantic HTML throughout — correct use of landmarks, headings, lists, tables, and form elements providing a meaningful document structure for screen readers and search engines
  • Keyboard navigability — all interactive components fully operable without a mouse, including navigation menus, modals, and form controls
  • ARIA augmentation — roles, labels, and live regions applied to custom interactive patterns not fully covered by native HTML semantics
  • Color contrast compliance — all text and interactive element color combinations checked against WCAG AA contrast ratio requirements
  • Cross-browser compatibility — validated across major browsers including Chrome, Firefox, Edge, and Safari to ensure consistent rendering for the broadest public audience

Responsive Layout

Extended the fixed-width PSD design to a fully responsive interface:

  • Mobile-first responsive build — core layout and typography established for small screens, enhanced progressively for tablet and desktop viewports
  • Fluid and flexible layout — CSS flexbox used to produce layouts that reflow gracefully across breakpoints without fixed-pixel assumptions
  • Touch-friendly interaction targets — navigation, buttons, and form controls sized and spaced appropriately for touch input on mobile devices
  • Content prioritisation at breakpoints — secondary content and navigational chrome collapsed appropriately on small screens to keep primary department information accessible
All projects