Pearl Timer – Project Management & Ticket Tracking Application

Web Designer – Individual Contributor · 2016 · 8 months · 2 people · 6 min read

Delivered the frontend for a feature-rich ticket tracking application, including bugs, feature requests, versioned documents, and threaded comments, from discovery through pixel-accurate HTML5/CSS3 implementation and backend handoff over an eight-month solo engagement.

Overview

Built the frontend for Pearl Timer, a unified ticket-based project management tool that combined issue tracking, document versioning, and threaded collaboration in a single interface. As the sole frontend contributor, I owned discovery, scoping, estimation, mockup-driven implementation, and backend integration support. The product's scope—versioned content, comments, and multiple ticket types—made this the most complex solo frontend project of the period.

Problem

Smaller teams either used heavyweight enterprise tools that were expensive and difficult to configure, or lightweight task managers that lacked document history and comment accountability. Pearl Timer aimed to close that gap by offering a ticket tracking platform with versioned documents, threaded discussions, and workflow visibility. The frontend had to make multi-type tickets, versioned attachments, threaded comments, and progress tracking feel approachable and fast for both technical and non-technical users.

Constraints

  • Ticket version history required multiple UI states—current version, prior revisions, diff markers, and restore flows—implemented in static HTML/CSS
  • Threaded comments with edit and reply modes added interaction complexity beyond standard form workflows
  • Four ticket categories (bugs, issues, feature requests, ideas) needed a shared component model while supporting type-specific metadata
  • No frontend framework—built entirely in HTML5, CSS3, jQuery, and vanilla JavaScript
  • Eight-month solo frontend engagement required sustained delivery discipline across a long project lifecycle
  • Designs were provided as client mockups and required faithful implementation without independent changes

Approach

Started with the most detailed discovery phase to date. Pearl Timer's complexity meant the mockups left many interaction states undefined, so I mapped empty states, version workflows, comment behaviours, and ticket transitions with the client before finalising estimates. I then built the interface in sequence: layout and navigation, dashboard and list views, the ticket detail screen, and finally versioning plus comments. jQuery powered inline editing, version history expansion, filtering, sorting, modal confirmations, and dynamic status updates. The markup was kept integration-friendly so backend templates could consume it without restructuring.

Key Decisions

Anchor the build around the ticket detail page

Reasoning:

The ticket detail view contained the most complex interaction set—status controls, version history, comments, metadata, and activity logs. Building it first defined the reusable patterns used across the app and prevented later architectural drift that often happens when the hardest view is saved for last.

Alternatives considered:
  • Build views in navigation order, starting with the dashboard
  • Develop multiple views in parallel with separate workstreams
  • Build a component library separately before page work

Use a single ticket component with type-specific metadata extensions

Reasoning:

Pearl Timer supported bugs, issues, feature requests, and ideas, each with unique fields but the same core structure. A unified ticket component with extension zones for type-specific metadata kept the UI consistent, reduced markup and CSS surface area, and simplified backend templating.

Alternatives considered:
  • Create separate templates for each ticket type
  • Use one template with all metadata fields shown or hidden
  • Share only header components and build distinct detail views

Follow familiar version history conventions for document versioning

Reasoning:

Document versioning is a pattern users already recognise from tools like Google Docs and Confluence. Using a conventional chronological version list with timestamps, author names, and restore actions reduced confusion and made the frontend contract clearer for backend integration.

Alternatives considered:
  • Design a custom visual diff-based version interface
  • Use a modal version history separate from the ticket page
  • Keep version history on a separate, standalone page

Tech Stack

  • HTML5
  • CSS3
  • jQuery
  • JavaScript
  • Responsive Design
  • CSS Animations
  • Modular SCSS Architecture

Result & Impact

  • 8 months
    Engagement Length
  • Tickets, versioning, comments, progress tracking
    Feature Complexity
  • Bugs, issues, feature requests, ideas
    Ticket Types
  • Solo frontend, full lifecycle ownership
    Delivery Model

Pearl Timer's frontend delivered a usable project management experience with document history and threaded collaboration. The unified ticket component model ensured consistent behaviour across ticket types, and the backend-ready markup smoothed integration. This eight-month engagement required sustained focus, careful sequencing, and maintaining the full application architecture throughout the project.

Learnings

  • Build the hardest view first on large apps so reusable patterns form early and consistency is preserved
  • Discovery for feature-rich products must expose undefined states like version workflows, comment edge cases, and empty lists
  • Unified component patterns with type-specific extensions reduce complexity and simplify backend integration
  • Version history interfaces should follow familiar conventions to ease onboarding
  • Long solo engagements teach sustained planning, context recovery, and delivery discipline beyond short sprints
  • Comment systems are complex—threading, editing, deletion, timestamps, and authorship all need explicit handling

Requirements & Planning

This engagement began with a deep discovery phase to make the product definition explicit before coding:

  • Discovery and scoping — analysed every mockup, view, and interaction needed for ticketing, version history, and comments
  • State mapping — defined empty states, version restores, edit/reply behaviours, status transitions, and upload progress with the client
  • Component architecture — identified reusable UI patterns ahead of build, making the unified ticket component the application’s structural foundation
  • Delivery planning — created an eight-month plan that sequenced work from layout and navigation to the most complex detail screens
  • Integration scoping — aligned markup and data-binding expectations with backend developers before writing HTML

Ticket Management Interface

Built the ticket system across all supported types using consistent, reusable components:

  • Dashboard overview — summary of open, in-progress, and resolved tickets with assignee load and recent activity
  • Ticket lists — filterable, sortable ticket views with type badges, status labels, priority markers, avatars, and last-updated timestamps
  • Primary ticket detail view — the most complex screen, combining metadata, status controls, version history, comments, and activity logs
  • Type-specific metadata panels — bug severity, feature estimates, or idea tags rendered within a shared ticket structure
  • Workflow controls — status progression and confirmation flows for open, in-progress, review, and resolved stages

Document Versioning

Delivered the document history experience at the core of Pearl Timer’s audit value:

  • Version history panel — chronological list of versions with author, timestamp, label, and summary
  • Restore workflow — confirmation flow for restoring prior versions with clear impact messaging
  • Attachment workflow — file upload, validation, progress, and feedback for document attachments
  • Comparison cues — indicators showing newer versions exist when viewing older revisions
  • Inline preview — document previews available within the ticket without leaving the page

Comment & Collaboration System

Built a threaded comment experience for team discussion and accountability:

  • Threaded comments — nested replies with avatars, timestamps, and visual hierarchy
  • Inline editing — edit comments directly in place with save/cancel controls and warnings for unsaved changes
  • Reply workflows — visual threading for replies with parent comment context
  • Delete confirmation — modal confirmation and soft-delete state before permanent removal
  • AJAX-ready structure — markup designed for jQuery-driven updates that append comments without full page reloads

Development Team Integration

Supported backend integration across the full project arc:

  • Template-friendly markup — semantic HTML with consistent classes and clear data binding points
  • Pattern documentation — annotated examples for ticket components, version history, and comment threads
  • Sustained collaboration — ongoing support through multiple integration phases for markup, styling, and event-binding issues
  • Browser validation — tested and fixed layout issues across Chrome, Firefox, Internet Explorer, and Safari, especially in comment and versioning screens
All projects