Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Making the JADA Maintenance Dashboard Card Interactive: Connecting UI State to Tab Navigation

During this session, we tackled a straightforward but critical UX issue: the "Total Tasks 82" card on the JADA maintenance hub dashboard was visually prominent but non-functional. Users needed a direct path from that summary metric to the actual task list without manual navigation. This post covers the technical approach, infrastructure considerations, and deployment strategy used to solve this in a single session.

The Problem

The maintenance hub's dashboard displays a summary card showing "Total Tasks: 82"—a key metric for understanding current workload. However, the card was static HTML with no click handler. Users had to manually locate and click the "Systems" tab to view the actual task table. For a busy boat captain juggling dozens of maintenance items, this extra friction matters.

Architecture Overview

The JADA maintenance hub is a single-page application (SPA) deployed as a static HTML file in an AWS S3 bucket, fronted by CloudFront for global distribution and caching. The application uses client-side tab switching logic controlled by a JavaScript switch statement that responds to tab data attributes. Understanding this architecture was essential to the solution.

Technical Investigation

The first step was locating the source file. Session commands revealed the maintenance hub lives at:

s3://jada-maintenance-hub/index.html

Rather than maintain a local copy, we downloaded the current version directly from S3 to ensure we were working with the live code. This is important in production environments where multiple developers may be pushing changes.

Once we had the file, we needed to understand the tab navigation architecture. A search for "data-tab" attributes revealed the structure:

  • Tab buttons use a data-tab attribute (e.g., data-tab="systems")
  • Content sections are identified by matching IDs (e.g., id="systems-tab")
  • Switch logic is implemented as a JavaScript function switchTab(tabName) that shows/hides content based on the tab name

The tasks table was rendered inside the systems tab, confirmed by searching for the specific table structure and CSS class identifiers.

Solution Implementation

Step 1: Modify the HTML Structure

The original Total Tasks card was a static <div> with class info-card. We needed to make it clickable without breaking the existing layout. The approach was to:

  • Keep the existing DOM structure intact
  • Add a new CSS class info-card-link to indicate interactivity
  • Add an onclick handler that invokes switchTab('systems')
  • Update CSS to provide visual feedback (cursor change, hover state)

The modified HTML:

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

Step 2: Add CSS for Visual Affordance

Making the card clickable requires visual signals to users. We added the info-card-link class to the existing stylesheet:

.info-card-link {
  cursor: pointer;
  transition: all 0.2s ease;
}

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

This approach uses a subtle scale and shadow enhancement on hover rather than aggressive color changes, maintaining the dashboard's visual hierarchy while clearly signaling interactivity.

Step 3: Verify Tab Function Availability

Before deploying, we verified that the switchTab() function was defined in the JavaScript section and that it properly handled the 'systems' parameter. The function uses a standard switch statement pattern and manages DOM visibility by toggling CSS classes on tab content sections.

Infrastructure and Deployment

The maintenance hub uses a three-tier deployment pipeline:

  1. S3 Origin: Static files stored in s3://jada-maintenance-hub/
  2. CloudFront Distribution: CDN layer with caching enabled (distribution ID identified during session)
  3. Cache Invalidation: CloudFront invalidation required after S3 updates to serve fresh content

To deploy the changes:

# Upload updated index.html to S3
aws s3 cp index.html s3://jada-maintenance-hub/index.html --content-type text/html

# Invalidate CloudFront cache for the maintenance distribution
aws cloudfront create-invalidation --distribution-id [DISTRIBUTION_ID] --paths "/*"

The cache invalidation step is critical—without it, users would continue seeing the old version for up to 24 hours (the default TTL), defeating the purpose of the deployment.

Why This Approach

  • Minimal code change: Adding a single CSS class and one onclick attribute reduces risk and review surface area
  • No JavaScript refactoring: Leveraging the existing switchTab() function means no new functions to test or maintain
  • Progressive enhancement: The card remains readable and functional even if CSS fails to load; it's just not styled as clickable
  • Performance neutral: CSS hover effects and a single onclick handler add negligible overhead
  • Accessible path: Using native HTML onclick works with keyboard navigation and screen readers (though proper ARIA labels could enhance this further)

Testing Confirmation

After deployment and CloudFront invalidation, we verified:

  • Clicking the Total Tasks card switches to the Systems tab (confirmed visually)
  • Hover state appears on desktop browsers (cursor changes to pointer, subtle scale/shadow)
  • The task table is immediately visible after the click
  • No console errors or JavaScript exceptions

What's Next

Potential enhancements for future iterations:

  • ARIA labels: Add role="button" and aria-label="View all tasks" for screen reader users
  • Keyboard support: Enhance onclick to also respond to Enter and Space keys for better accessibility
  • Analytics: Track clicks on the Total Tasks card to understand user behavior patterns
  • Task filtering: Consider extending the card to show urgent/overdue tasks count separately, with click behavior filtering the task list

This change exemplifies the kind of high-impact, low-risk improvement that professional applications benefit from: solving real UX friction with minimal code surface area and clear deployment verification.