Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Making the JADA Maintenance Dashboard Clickable: UI/UX Enhancement with CloudFront Cache Invalidation

What Was Done

The JADA Maintenance Hub dashboard had a "Total Tasks" information card displaying aggregate task counts, but it was purely informational—non-interactive. We made this card clickable to navigate users directly to the Tasks tab, improving workflow efficiency and reducing navigation friction. This required HTML/CSS modifications to the S3-hosted dashboard, cache invalidation to ensure users received the updated version, and validation that the interaction pattern integrated correctly with the existing tab-switching architecture.

Technical Details: The Problem and Solution

Initial State

The maintenance hub dashboard lives as a static HTML file in an S3 bucket, served through CloudFront with client-side JavaScript managing tab navigation. The dashboard displays multiple information cards in a grid layout on the home tab, including a "Total Tasks" card showing aggregate task counts. Users who wanted to see task details had to manually click the "Systems" tab navigation element—an extra click in the critical path.

Code Changes: Making the Card Interactive

The file modified was /maintenance_index.html (the index.html file downloaded from the S3 maintenance bucket). The solution involved three CSS and HTML patterns:

  • Semantic HTML Wrapping: The Total Tasks card was already a <div> with class info-card. We converted its click behavior by adding an onclick event handler that calls the existing switchTab('systems') JavaScript function.
  • CSS Styling for Interactivity: Added a new CSS class info-card-link to provide visual affordance that the card is clickable: 
    .info-card-link {
  cursor: pointer;
  transition: transform 0.2s ease, box-shadow 0.2s ease;
}

.info-card-link:hover {
  transform: translateY(-2px);
  box-shadow: 0 4px 16px rgba(0, 0, 0, 0.12);
}
  • JavaScript Integration: The dashboard's existing tab-switching logic already had a switchTab() function that updates the UI state and manages which tab content is visible. No new JavaScript was required—we simply wired the card's click event to call the existing function with the parameter 'systems'.

Infrastructure and Deployment

S3 Bucket and File Location

The maintenance dashboard is hosted in an S3 bucket serving the subdomain maintenance.jada.queenofsandiego.com. The bucket structure is:

s3://[maintenance-bucket]/
  ├── index.html          (main dashboard)
  ├── assets/
  │   ├── css/
  │   └── js/
  └── ...other resources

CloudFront Distribution and Cache Invalidation

The S3 bucket is fronted by a CloudFront distribution to enable edge caching, reduce latency for users, and provide HTTPS termination via Route53. When we updated index.html` in S3, the CloudFront cache still served stale content to users because CloudFront's default TTL is typically 24 hours for HTML files.

To ensure users received the updated version immediately, we invalidated the CloudFront cache for the maintenance distribution using the command pattern:

aws cloudfront create-invalidation \
  --distribution-id [CLOUDFRONT_DIST_ID] \
  --paths "/index.html" "/assets/*"

This invalidation request cleared the cached objects, forcing CloudFront to fetch fresh content from S3 on the next user request. The invalidation typically completes within 30–60 seconds.

Why This Architecture?

CloudFront + S3 is the standard pattern for static content delivery because:

  • Geographic Distribution: CloudFront edge locations worldwide reduce latency for users accessing the dashboard from different locations.
  • Cost Efficiency: S3 storage is cheap; CloudFront caching reduces the number of origin requests.
  • DDoS Mitigation: CloudFront provides built-in protection against volumetric attacks.
  • HTTPS/SSL: CloudFront handles SSL termination, offloading the computational burden from the origin.

Why This Approach Matters

User Experience

The Total Tasks card is the first thing users see on the maintenance dashboard. Making it actionable removes friction—users can now jump directly to the task list in one click instead of two, which is particularly valuable in a marine environment where quick decision-making under stress is common.

No Backend Changes Required

The solution is purely client-side JavaScript and CSS. The dashboard already had the switchTab() function managing tab state and rendering. We leveraged that existing infrastructure rather than introducing new API endpoints, Lambda functions, or backend logic. This reduces complexity, deployment risk, and ongoing maintenance burden.

Visual Affordance

The hover effect (slight upward transform + enhanced shadow) communicates to users that the card is interactive. This follows established UI/UX patterns—buttons and clickable elements should signal their affordance through visual cues.

Validation and Testing

Before deploying, we verified:

  • The HTML structure of the Total Tasks card and its relationship to the tab navigation markup.
  • The switchTab('systems') function correctly switches the active tab and renders the tasks table.
  • CSS transitions and hover states render without JavaScript errors in the browser console.
  • The CloudFront cache invalidation completed successfully and new requests return the updated HTML.

Deployment Workflow

  1. Download current file from S3: aws s3 cp s3://[maintenance-bucket]/index.html /tmp/maintenance_index.html
  2. Edit locally: Add the onclick handler and info-card-link CSS class to the Total Tasks card.
  3. Upload back to S3: aws s3 cp /tmp/maintenance_index.html s3://[maintenance-bucket]/index.html
  4. Invalidate CloudFront: Create invalidation request for the distribution ID.
  5. Verify in browser: Visit maintenance.jada.queenofsandiego.com, clear local cache, and test the card click.

What's Next

This pattern can be extended to other dashboard cards—making the "Open Work Orders" card jump to the Work Orders tab, or the "Upcoming Maintenance" card jump to a Scheduled Maintenance view. The infrastructure is now in place and tested.

Additionally, we should document the cache invalidation workflow for future updates to ensure team members don't accidentally serve stale content to users after S3 modifications.

```