Interaction Analysis. - Domenicko/medical-booking-system GitHub Wiki

Interaction Analysis

1. Selected Module

Module: Doctor Search and Appointment Booking

Purpose: The module allows patients to search for doctors, explore doctor profiles, select an available appointment slot, and receive confirmation after booking.

The interaction design focuses on usability, responsiveness, performance, and accessibility.

2. Micro-Interactions

2.1 Doctor Card Hover and Focus Interaction

Purpose: Help users identify interactive doctor cards and navigate to additional information.

  • Trigger: The user hovers over a doctor card with a mouse or focuses an interactive element inside the card using the keyboard.
  • Rules: The card applies a subtle upward translation. A shadow effect may appear through an opacity transition. The interaction must not change the card's layout or cause surrounding elements to move.
  • Feedback: The card appears slightly elevated, providing a clear visual indication that it is interactive.
  • Loops / Modes: This is a reversible interaction. The card returns to its default state when the pointer leaves or keyboard focus moves away. The focused state remains visible while the element has keyboard focus.

2.2 Doctor Search with Debouncing

Purpose: Allow patients to find doctors by name without performing unnecessary filtering operations after every keystroke.

  • Trigger: The user enters or edits text in the doctor search input.
  • Rules: A debounce function delays filtering until the user stops typing for approximately 300 milliseconds. If the user enters another character before the delay expires, the previous pending operation is cancelled. Search results are matched against doctor names.
  • Feedback: The results update after the debounce delay. Matching doctor cards are displayed, while non-matching cards are hidden. If no doctors match, a clear empty-state message is displayed.
  • Loops / Modes: This is a repeatable interaction. The results change as the search query changes. Clearing the input restores the full doctor list.

2.3 Appointment Booking and Confirmation

Purpose: Provide clear feedback when a patient selects an available appointment slot and confirms a booking.

  • Trigger: The patient selects an available appointment slot and activates the booking confirmation button.
  • Rules: The system validates the selected doctor, date, and time before processing the booking. A successful booking updates the appointment status. The selected slot must not be treated as confirmed if validation or booking fails.
  • Feedback: The selected slot receives a distinct visual state. After successful confirmation, the interface displays a confirmation message and a pulse indicator. If the operation fails, the user receives an understandable error message.
  • Loops / Modes: This interaction uses multiple states: available, selected, processing, confirmed, and error. The pulse animation runs temporarily or for a defined number of iterations rather than indefinitely.

3. CSS Animations and GPU-Friendly Properties

Interactive elements will use CSS transitions based primarily on transform and opacity.

  • Doctor cards will use a subtle translateY transition.
  • Buttons will provide visual hover and active feedback.
  • Appointment confirmation will use a pulse animation based on opacity and scaling.
  • Shadow appearance, where required, will be implemented using an opacity-controlled pseudo-element to avoid animating layout-affecting properties.

The animations will respect the user's reduced-motion preferences through prefers-reduced-motion.

4. JavaScript Performance Optimization

4.1 Debouncing the Search Input

A reusable debounce utility or custom hook will delay doctor-list filtering until the user stops typing for 300 milliseconds.

This reduces unnecessary filtering operations and improves responsiveness when the doctor list grows.

4.2 Event Delegation on the Doctor List

A single click listener will be attached to the doctor-list container rather than attaching separate native event listeners to every doctor card.

The handler will inspect event.target and use closest() to identify the intended interactive element. It will then determine which doctor or action was selected.

In the React implementation, the listener will be managed through a suitable effect with proper cleanup. Native event delegation will not be combined with duplicate React click handlers for the same action.

5. Accessibility

5.1 Keyboard Navigation

  • Interactive elements must be reachable using the Tab key.
  • Native buttons and links will support Enter and Space according to their standard browser behavior.
  • Doctor cards that navigate to profiles will use semantic links or buttons.
  • Appointment slots will expose their selected state and remain keyboard-accessible.

5.2 Focus Management

Interactive elements will have a visible :focus-visible style with sufficient contrast against the background.

Keyboard focus must not be indicated by color alone. Focus indicators must remain visible and must not be removed without an accessible replacement.

5.3 Motion Accessibility

Animations will be reduced or disabled when the user has enabled prefers-reduced-motion. Essential information, including booking confirmation and error messages, will remain available without animation.

6. Acceptance Criteria

  • Doctor cards provide clear hover and keyboard-focus feedback.
  • Card animations use transform and opacity for the animated effects.
  • Doctor search filters results after a 300 ms debounce delay.
  • Clearing the search input restores the full list.
  • The doctor list uses a single delegated native click listener where required.
  • Appointment booking provides clear success and error states.
  • Interactive elements are accessible by keyboard.
  • Focus indicators are visible and distinguishable.
  • Reduced-motion preferences are respected.
  • All changes are tested without breaking existing Home page functionality.