Project Overview

Project Purpose and Objectives

This project implements a Meeting Cost Calculator designed to track and compute the real-time cost of meetings based on attendee count, average hourly wage, and meeting duration. The system enables users to start, pause, and reset meetings while continuously updating the monetary cost incurred. It also maintains a history of past meetings for review.

Key objectives include:

• Accurate time and cost tracking for meetings with dynamic attendee and wage inputs.

• Persistent storage of past meeting data using browser localStorage.

• User interaction management through a responsive form-based UI with real-time feedback.

• Clear visualization of current meeting cost and historical meeting summaries.

Core functionalities are implemented as follows:

• A Meeting model manages meeting state, increments of time, attendee and wage changes, and cost calculations.

• A Warehouse model abstracts localStorage operations to save and retrieve meeting data.

• UI views render the current meeting cost/time and a list of past meetings dynamically.

• The main entry (index.js) orchestrates UI event handling, state updates, and data persistence.

Example Workflows and Use Cases

Starting a Meeting and Tracking Cost

1. User inputs number of attendees, average wage, and meeting purpose.

2. User clicks Start:

   • Meeting instance initializes increments and sets start time.

   • A timer begins updating the displayed cost every second.

3. As time progresses, the system calculates elapsed time and multiplies by attendee count and wage to determine the current cost burn rate.

4. User can update attendee count or wage during the meeting; the system pushes current increments and starts new increments with updated values.

5. User clicks Stop:

   • Meeting clock stops, final increment is saved, and the meeting data is stored in the warehouse (localStorage).

6. The UI updates the current cost display and refreshes the past meetings list with the newly saved meeting.

Resetting Meeting Data

• When the user clicks Reset, the current meeting data is cleared, counters reset to defaults, and UI inputs are reset to initial states.

• The cost display and form inputs are updated to reflect the reset state.

Reviewing Past Meetings

• The system loads past meeting records from localStorage on page load or after a meeting ends.

• These records are rendered as a table showing date/time, attendees, total cost, and meeting purpose.

• A Clear Storage button enables removing all stored meeting history.

Stack and Technologies

• JavaScript (ES6 modules): Core programming language for models, views, and UI event management.

• Browser localStorage: Provides persistent client-side storage for meeting data via the Warehouse class.

• Bootstrap 4: Used for responsive layout and styling of the UI components.

• FontAwesome & Google Fonts: Used for iconography and custom typography enhancing UI clarity and style.

• CSS (app.css): Custom styles manage backgrounds, layout constraints, and responsive text alignment.

These technologies were selected for their wide browser support, simplicity in client-side storage, and ease of integration into a modular JavaScript codebase. The modular ES6 approach facilitates separation of concerns and maintainability.

Key libraries and modules essential to the system:

• Meeting.js: Core logic for meeting lifecycle and cost calculations.

• Warehouse.js: Abstracts localStorage operations for reliable data persistence.

• Meeting and PastMeetings views: Render the dynamic cost display and past meetings table.

• index.js: Coordinates UI events, model updates, and view rendering.

High-Level Architecture

The architecture follows a modular front-end design pattern focusing on separation of concerns between models, views, and controller logic.

Major Components

• UI Layer (index.html + index.js):

  • HTML form inputs for meeting details and control buttons.

  • Event listeners in index.js handle user interactions.

  • DOM updates invoke view render functions reflecting current or past meetings.

• Models (lib/models):

  • Meeting: Manages meeting state and incremental time-based calculations.

  • Increment: Represents discrete time intervals with associated cost data.

  • Warehouse: Handles localStorage persistence for meeting data.

• Views (lib/views):

  • MeetingTemplate: Renders current meeting cost and time info.

  • PastMeetingsTemplate: Renders a table of stored past meetings.

Interaction Flow

• User input events trigger index.js handlers which call Meeting methods to update state (start, stop, change attendees/wage).

• Meeting class pushes increments representing elapsed time and cost when parameters change or meeting stops.

• Meeting data is saved to Warehouse (localStorage) when a meeting ends.

• Views update dynamically to show current meeting cost or past meetings list.

graph TB
UI[index.html / index.js] --> MeetingModel(Meeting Model)
MeetingModel --> IncrementModel(Increment Model)
MeetingModel --> WarehouseModel(Warehouse Model)
MeetingModel --> MeetingView(MeetingTemplate)
WarehouseModel --> PastMeetingsView(PastMeetingsTemplate)
UI --> MeetingView
UI --> PastMeetingsView

Developer Navigation

Frontend Developers Start Here

• index.html: UI structure and form controls.

• index.js: Core event handlers for UI interactions, meeting lifecycle control, and view updates.

• lib/views/: Contains rendering logic for current meeting cost (meeting.js) and past meetings summary (pastMeetings.js).

• app.css: Styling details to customize UI appearance.

Focus on how user input triggers meeting state changes and UI refreshes.

Backend/Model Developers Focus Here

• lib/models/meeting.js: Meeting lifecycle, increments management, cost/time calculations.

• lib/models/increment.js: Data structure for time intervals with cost calculation.

• lib/models/Warehouse.js: Interfaces with localStorage for storing/loading meeting data.

• lib/constants.js: Time constants used in calculations.

Focus on extending or optimizing meeting cost logic, persistence mechanisms, or adding new data attributes.

Data Persistence and Storage Exploration

• Explore Warehouse.js for localStorage interaction patterns.

• Investigate how meeting increments are serialized and saved under localStorage keys.

• Verify data limits (max 10 meeting records) and implement potential extensions.

Visual Diagrams

Component Diagram: High-Level Architecture

graph TB
UI[UI Layer]
Meeting[Meeting Model]
Increment[Increment Model]
Warehouse[Warehouse Model]
MeetingView[Meeting View]
PastMeetingsView[Past Meetings View]
UI --> Meeting
Meeting --> Increment
Meeting --> Warehouse
Meeting --> MeetingView
Warehouse --> PastMeetingsView
UI --> MeetingView
UI --> PastMeetingsView

Flowchart: Meeting Cost Calculation Workflow

flowchart TD
Start[Start Meeting]
Init[Initialize Meeting Instance]
Timer["Start Timer (1s interval)"]
UpdateInputs[User Updates Attendees/Wage]
PushIncrement[Push Increment for elapsed time]
CalculateCost[Calculate current cost]
UpdateUI[Update Cost Display]
StopMeeting[Stop Meeting]
SaveData[Save Meeting to Warehouse]
Reset[Reset Meeting Data]
Start --> Init --> Timer
Timer --> CalculateCost --> UpdateUI
UpdateInputs --> PushIncrement --> Init
StopMeeting --> PushIncrement --> SaveData
SaveData --> UpdateUI
Reset --> Init

This overview guides developers through the core technical structure, workflows, and navigation paths necessary to understand, maintain, and extend the meeting cost calculator project efficiently.