Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Making the JADA Maintenance Dashboard Card Interactive: Tab Navigation & S3 Deployment

The JADA Maintenance Hub dashboard displays a "Total Tasks" card showing the current task count (82 in this session). Previously, this was a static display element. The requirement was to make this card clickable—tapping it should navigate the user directly to the Systems tab where the full task table lives. This post covers the technical approach, infrastructure decisions, and deployment process.

What Was Done

We transformed the Total Tasks info-card from a passive display element into an interactive navigation control by:

  • Adding click-handler JavaScript that triggers the existing switchTab('systems') function
  • Styling the card with hover states and cursor changes to signal interactivity
  • Pushing the updated HTML to S3 and invalidating the CloudFront distribution to serve fresh content

Technical Details: Code Changes

File Modified: /tmp/maintenance_index.html (downloaded from S3 bucket prior to edit)

The maintenance hub's card structure follows a standard info-card pattern. The Total Tasks card HTML originally looked like:

<div class="info-card">
  <div class="card-label">Total Tasks</div>
  <div class="card-value">82</div>
</div>

We wrapped this in a clickable container and added an onclick handler:

<div class="info-card info-card-link" onclick="switchTab('systems')">
  <div class="card-label">Total Tasks</div>
  <div class="card-value">82</div>
</div>

Why this approach? The existing tab-switching logic already had a switchTab() function that handles DOM updates, active-state styling, and data rendering. Rather than duplicate that logic or create a separate navigation handler, we leveraged the existing function. This follows the DRY principle and reduces maintenance burden.

CSS Addition: The info-card-link class provides visual feedback:

.info-card-link {
  cursor: pointer;
  transition: background-color 0.2s ease, box-shadow 0.2s ease;
}

.info-card-link:hover {
  background-color: rgba(255, 255, 255, 0.1);
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.2);
}

The hover effect subtly lifts the card (via box-shadow) and lightens the background, making it clear to users that the element is interactive. The cursor: pointer CSS property ensures the browser displays the hand cursor on hover.

Why the Systems Tab?

The dashboard uses a tabbed interface with multiple views (Dashboard, Systems, History, etc.). The task table—showing detailed task status, assignments, priority, and dates—is rendered in the Systems tab. When a user clicks the Total Tasks card, switching to this tab immediately shows them the full task list, providing seamless navigation from summary to detail.

Infrastructure & Deployment

Storage: The maintenance hub's index.html is stored in an S3 bucket (not version-controlled locally in the repo). This allows dynamic updates without redeploying application code.

Download from S3:

aws s3 cp s3://[maintenance-bucket-name]/index.html /tmp/maintenance_index.html

Upload to S3 (after edits):

aws s3 cp /tmp/maintenance_index.html s3://[maintenance-bucket-name]/index.html --content-type "text/html"

CloudFront Invalidation: The maintenance subdomain is served through a CloudFront distribution. After uploading to S3, we invalidated the cache to ensure users receive the updated file immediately (rather than waiting for the 24-hour default TTL):

aws cloudfront create-invalidation --distribution-id [DISTRIBUTION-ID] --paths "/*"

Why CloudFront? CloudFront provides edge-caching at AWS's global content delivery network, reducing latency for users accessing the maintenance hub from multiple locations. The invalidation step ensures that cached versions don't serve stale HTML, which would break the new click functionality.

Architecture Decisions

1. No Backend Changes Required

This was a pure frontend enhancement. The task data is already fetched and rendered by existing backend services. By using the existing switchTab() function, we avoided any API changes or server-side modifications.

2. Progressive Enhancement

The card remains visually present and functional even in older browsers or if JavaScript is disabled (though it won't be clickable). The card still displays the task count, maintaining information availability.

3. Accessibility Consideration

While the current implementation uses onclick, a more accessible approach for future work would be to wrap this in a <button> element or add appropriate ARIA attributes. The cursor: pointer CSS helps signal interactivity, but keyboard navigation (Tab key) would require additional ARIA roles.

Testing & Validation

After deployment:

  • Verified the updated index.html was readable from the maintenance subdomain
  • Clicked the Total Tasks card and confirmed navigation to the Systems tab
  • Checked that the task table rendered correctly with the appropriate data
  • Tested hover states in Chrome, Safari, and Firefox to ensure CSS transitions worked as expected

Key Learnings

S3 + CloudFront Pattern: For frequently-updated frontend assets that don't require versioning or rollback, S3 + CloudFront is a lightweight, cost-effective approach. It bypasses application deployment pipelines, allowing marketing or product teams to push UI changes without code review.

Leveraging Existing Functions: The JADA codebase already had robust tab-switching logic. Reusing it meant zero risk of introducing new bugs and maintained consistency with how other tabs are navigated.

What's Next

  • Enhance Other Cards: Consider making other summary cards (e.g., "Overdue Tasks," "In Progress") clickable to filter or navigate to relevant tabs.
  • Accessibility Audit: Refactor card navigation to use semantic HTML (<button> elements) and ARIA labels for improved keyboard and screen-reader support.
  • Analytics: Add click-tracking to the card to measure user engagement and validate whether this UX improvement increases task visibility.
  • Mobile Responsiveness: Verify that touch targets are large enough for mobile users and test on various device sizes.

Deployment Time: ~15 minutes from edit to live, including S3 upload and CloudFront invalidation. This rapid iteration cycle is one of the key advantages of the S3-hosted dashboard pattern.