DEV Community: Coaste

Using Chart.js the Right Way: UI & UX Strategies for Better Data Visualization

Coaste — Tue, 29 Sep 2026 13:50:06 +0000

Charts are everywhere in modern web applications.

Dashboards, admin panels, analytics platforms, financial systems, inventory applications, SaaS products — almost every data-driven interface eventually needs some form of visualization.

But adding a chart is easy.

Designing a chart that actually helps the user understand the data is much harder.

In this article, I'll show how to use Chart.js effectively while applying practical UI and UX principles to make dashboards more readable, useful, and engaging.

The goal isn't to create the most colorful dashboard possible.

The goal is to make the data easier to understand.

What Makes a Good Chart?

A chart should answer a question.

Before writing any JavaScript, ask:

What should the user understand after looking at this chart?

For example:

❌ "Here are our sales."

✅ "Which products generated the most revenue?"

❌ "Here is our inventory."

✅ "Which warehouses currently hold the most inventory?"

❌ "Here are our monthly numbers."

✅ "Is our revenue increasing or decreasing?"

This small change in thinking has a huge impact on the final interface.

A chart should have a purpose.

📊 Choosing the Right Chart

One of the most common mistakes in dashboards is choosing a chart because it looks good instead of choosing it because it communicates the data well.

A simple rule is:

Goal Recommended Chart
Compare categories Bar
Compare rankings Horizontal bar
Show a trend Line
Show composition Doughnut / Pie
Show relationship Scatter
Show progress Doughnut / Progress
Compare multiple metrics Bar / Line

For example, if you want to compare sales between products:

const config = { type: "bar", data: { labels: ["Product A", "Product B", "Product C"], datasets: [{ label: "Sales", data: [120, 180, 95] }] } };

A bar chart immediately communicates the relative size of each category.

🧠 UI/UX Rule #1: Don't Visualize Everything

A dashboard doesn't need 15 charts.

More charts don't necessarily mean more information.

They can actually make the interface harder to understand.

Consider this:

┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Sales │ │ Customers │ │ Orders │
│ │ │ │ │ │
│ CHART │ │ CHART │ │ CHART │
└──────────────┘ └──────────────┘ └──────────────┘

┌─────────────────────────────────────────────────┐
│ ANOTHER CHART │
└─────────────────────────────────────────────────┘

Everything is competing for attention.

Instead, establish a hierarchy:

┌─────────────────────────────────────────────────┐
│ KEY METRIC │
└─────────────────────────────────────────────────┘

┌────────────────────────┐ ┌──────────────────────┐
│ Main Chart │ │ Supporting Metric │
│ │ │ │
└────────────────────────┘ └──────────────────────┘

The interface should communicate:

Primary information → Secondary information → Details

🎯 UI/UX Rule #2: Give Every Chart a Clear Title

Avoid titles such as:

Sales
Data
Statistics
Information

These titles don't provide much context.

Instead:

Monthly Revenue
Revenue by Product
Inventory by Warehouse
Assets by Cost Center
Orders by Category

A good title tells the user what they're looking at without requiring additional explanation.

Chart.js makes this easy:

const config = { type: "bar", data, options: { plugins: { title: { display: true, text: "Revenue by Product" } } } };

The title should communicate the question being answered.

🧩 UI/UX Rule #3: Use Cards to Create Context

A chart by itself can lack context.

For example:

    Revenue

  ████████
  ████████
  ███████████
  ███████████

The user may still ask:

Is that good?

A summary card can provide immediate context:

┌──────────────────────────┐
│ Total Revenue │
│ │
│ $248,420 │
│ │
│ ↑ 12.4% vs last month │
└──────────────────────────┘

Then the chart can explain where that number came from.

This creates a useful hierarchy:

KPI
↓
Trend
↓
Breakdown
↓
Details

Charts should support the metrics, not compete with them.

📈 UI/UX Rule #4: Use Line Charts for Trends

When the user needs to understand change over time, a line chart is usually more appropriate.

For example:

const config = { type: "line", data: { labels: [ "January", "February", "March", "April" ], datasets: [{ label: "Revenue", data: [ 12000, 14500, 13800, 17100 ] }] } };

The important UX principle here is that the order of the points matters.

A line naturally communicates progression.

This makes it useful for:

Revenue
Users
Orders
Inventory
Performance
Traffic
Growth
📊 UI/UX Rule #5: Use Bar Charts for Comparisons

Bar charts are extremely effective when comparing categories.

For example:

const config = { type: "bar", data: { labels: [ "Warehouse A", "Warehouse B", "Warehouse C", "Warehouse D" ], datasets: [{ label: "Inventory", data: [820, 540, 390, 210] }] } };

This immediately answers:

Which warehouse has the most inventory?

For ranking-heavy dashboards, a horizontal bar chart can be even better.

Warehouse A ████████████████████ 820

Warehouse B █████████████ 540

Warehouse C █████████ 390

Warehouse D █████ 210

Long category names become easier to read.

🥧 UI/UX Rule #6: Don't Abuse Pie Charts

Pie and doughnut charts are visually attractive.

That's exactly why they're often overused.

They work best when showing part of a meaningful whole.

For example:

Inventory Distribution

Materials 55%
PPE 25%
Uniforms 20%

But imagine 15 categories:

Category A
Category B
Category C
Category D
Category E
Category F
...

The chart quickly becomes difficult to read.

In those cases, a bar chart usually provides a clearer comparison.

A useful rule:

Use a pie/doughnut chart when composition matters. Use a bar chart when comparison matters.

🎨 UI/UX Rule #7: Don't Let Colors Become Noise

One of the easiest ways to make a dashboard look chaotic is to assign a different color to everything.

For example:

🔴 Sales
🔵 Revenue
🟢 Orders
🟡 Users
🟣 Inventory
🟠 Customers

The interface starts looking like a rainbow.

Instead, establish a visual language.

For example:

Primary color
↓
Main information

Neutral colors
↓
Supporting information

Accent color
↓
Important state

Warning / Error
↓
Only when necessary

Color should communicate meaning.

It shouldn't simply decorate the chart.

👀 UI/UX Rule #8: Highlight What Matters

Suppose you have this dataset:

Product A → 10
Product B → 20
Product C → 150
Product D → 15

The important information is obvious:

Product C is significantly higher.

Your visualization should help the user notice that.

You can use visual hierarchy through:

Position
Size
Labels
Typography
Controlled color
Sorting

The user shouldn't have to inspect every element manually.

🔢 UI/UX Rule #9: Format Numbers for Humans

Raw numbers are often difficult to scan.

Instead of:

1250000

prefer:

1.25M

Instead of:

1250000.00

prefer:

$1.25M

Instead of:

0.1537

prefer:

15.37%

Chart.js provides callbacks that can be used to format values.

For example:

options: { scales: { y: { ticks: { callback: function(value) { return "$" + value.toLocaleString(); } } } } }

Readable numbers reduce cognitive load.

🖱️ UI/UX Rule #10: Use Tooltips for Details

A chart shouldn't try to display every piece of information at once.

That's where tooltips become useful.

The default chart can remain clean:

   Revenue

███
█████
███████
█████████

When the user interacts:

┌────────────────────┐
│ March │
│ Revenue: $42,500 │
└────────────────────┘

This is a good UX pattern:

Show essential information by default. Reveal additional information on interaction.

🔄 UI/UX Rule #11: Combine Charts With Filters

Charts become much more useful when users can interact with the dataset.

For example:

[ All ] [ Materials ] [ PPE ] [ Assets ]

Selecting a category can update the chart.

`$("#categoryFilter").on("change", function () {
const category = $(this).val();

updateChart(category);

});`

This creates a much more dynamic experience.

Instead of creating four different charts:

Chart 1
Chart 2
Chart 3
Chart 4

you can have:

          FILTER
            ↓
         DATASET
            ↓
          CHART

The same visualization becomes useful for multiple contexts.

🧱 UI/UX Rule #12: Use Progressive Disclosure

Don't expose every detail immediately.

A dashboard can follow this structure:

Level 1
Summary
↓
Level 2
Charts
↓
Level 3
Detailed table
↓
Level 4
Movement / History

For example:

Inventory
↓
Warehouse
↓
Material
↓
Movement History

This prevents the interface from becoming overwhelming.

The user gets more information only when they ask for it.

📱 Responsive Charts Matter

A chart that looks great on desktop can become unusable on mobile.

Always consider:

Desktop
┌────────────────────────────────────────────┐
│ CHART │
└────────────────────────────────────────────┘

Mobile
┌──────────────────────┐
│ CHART │
│ │
│ ███ │
│ █████ │
│ ███████ │
└──────────────────────┘

Chart containers should have controlled dimensions and responsive behavior.

A simple CSS approach:

.chart-container {
position: relative;
width: 100%;
height: 320px;
}

And in Chart.js:

options: {
responsive: true,
maintainAspectRatio: false
}

This allows the chart to adapt to the container instead of forcing a fixed aspect ratio.

⚡ Performance: Don't Render What the User Doesn't Need

Large datasets can make dashboards slow.

One important principle is:

Don't render everything just because you have everything.

If the user is looking at the top 10 products, there may be no reason to render 500 categories simultaneously.

Instead:

500 records
↓
Filter
↓
Sort
↓
Top 10
↓
Chart

This improves both readability and performance.

🧠 A Practical Dashboard Pattern

A pattern I like for data-heavy interfaces is:

┌─────────────────────────────────────────────┐
│ Dashboard │
│ │
│ [Filter] [Search] [Date Range] │
└─────────────────────────────────────────────┘

┌──────────────┐ ┌──────────────┐ ┌───────────┐
│ Total │ │ Average │ │ Growth │
│ 1,240 │ │ $420 │ │ +12.4% │
└──────────────┘ └──────────────┘ └───────────┘

┌────────────────────────────┐ ┌──────────────┐
│ │ │ Distribution │
│ Main Trend │ │ │
│ │ │ CHART │
│ CHART │ │ │
│ │ │ │
└────────────────────────────┘ └──────────────┘

┌─────────────────────────────────────────────┐
│ Detailed Data │
│ │
│ Table / Records / History │
└─────────────────────────────────────────────┘

This structure works because each component has a clear responsibility.

🧩 Reusable Chart Functions

If your application contains multiple charts, avoid duplicating the same configuration everywhere.

Instead of:

`new Chart(...);
new Chart(...);
new Chart(...);
new Chart(...);

create a reusable function:

function createChart(canvas, type, labels, values, label) {
return new Chart(canvas, {
type,
data: {
labels,
datasets: [{
label,
data: values
}]
},
options: {
responsive: true,
maintainAspectRatio: false
}
});
}

Then:

createChart(
document.getElementById("salesChart"),
"bar",
["A", "B", "C"],
[120, 180, 90],
"Sales"
);
`
This keeps the implementation consistent.

🚫 Common Chart.js Mistakes

Here are some mistakes I try to avoid when building dashboards.

Too many charts

More charts ≠ better analytics.

Too many colors

Color should communicate meaning.

Missing units

A value like 1250 doesn't tell the user whether it's dollars, units, users, or something else.

Poor labels

Users shouldn't need to guess what an axis represents.

No hierarchy

Every element shouldn't have the same visual importance.

Overloaded tooltips

Tooltips should provide useful context, not become hidden tables.

Fixed dimensions

Charts should adapt to their containers.

Wrong chart type

A beautiful chart can still be the wrong visualization.

🧪 A Complete Example

Here's a small example combining some of these principles:

const labels = [
"Main Warehouse",
"Secondary Warehouse",
"PPE Warehouse",
"Regional Warehouse"
];

const values = [
820,
540,
390,
210
];

new Chart(
document.getElementById("inventoryChart"),
{
type: "bar",

    data: {
        labels,

        datasets: [{
            label: "Inventory",
            data: values
        }]
    },

    options: {
        responsive: true,
        maintainAspectRatio: false,

        plugins: {
            legend: {
                display: false
            },

            tooltip: {
                callbacks: {
                    label: function(context) {
                        return ` ${context.raw.toLocaleString()} units`;
                    }
                }
            }
        },

        scales: {
            y: {
                beginAtZero: true,

                ticks: {
                    callback: function(value) {
                        return value.toLocaleString();
                    }
                }
            }
        }
    }
}

);

`
Notice that the example intentionally keeps the interface simple.

The chart has:

One clear metric
A meaningful label
Formatted numbers
Responsive behavior
Useful tooltips
No unnecessary legend
A clear comparison
🎯 The Main Principle

Chart.js is a tool.

UI/UX determines whether that tool is actually useful.

You can have technically perfect JavaScript and still create a poor dashboard.

The most important questions are not:

"Which Chart.js option should I use?"

They are:

"What does the user need to understand?"

"What information should receive visual priority?"

"What can be hidden until the user needs it?"

"Which visualization communicates this data most naturally?"

Once those decisions are made, implementing the chart becomes much easier.

🚀 Final Checklist

Before publishing a dashboard, I like to ask:

[ ] Does the chart answer a clear question?
[ ] Is the chart type appropriate?
[ ] Is the title meaningful?
[ ] Are the numbers easy to read?
[ ] Are units clearly defined?
[ ] Is there unnecessary visual noise?
[ ] Are colors being used intentionally?
[ ] Can the chart work on mobile?
[ ] Are tooltips useful?
[ ] Can the user filter the information?
[ ] Is the most important information visually dominant?
[ ] Is the chart actually more useful than a table?

If the answer to most of these questions is yes, you're probably on the right track.

Conclusion

Creating charts with Chart.js is relatively easy.

Creating useful data visualizations requires a little more thought.

The best dashboards don't try to impress users with dozens of charts, animations, or colors.

They guide the user's attention.

They create hierarchy.

They provide context.

And most importantly, they make complex information easier to understand.

Good data visualization isn't about showing more data. It's about making the right data easier to see.

That's where Chart.js + good UI/UX becomes much more powerful.

If you're building a dashboard right now, start with the question you're trying to answer — and choose the visualization afterward.

Building an Asset & Inventory Dashboard with JavaScript, jQuery, Tailwind CSS and Chart.js

Coaste — Tue, 29 Sep 2026 13:39:27 +0000

In many business applications, important information is spread across different screens, tables, and systems. Although the data is available, understanding it quickly can still be a challenge.

This project explores how to build a simple and interactive Asset & Inventory Dashboard that brings materials, assets, PPE, uniforms, values, quantities, and movement history into a single interface.

The dashboard was originally developed for an internal environment and connected to business APIs. For the public version, the original integrations and company-specific information were removed and replaced with mock data.

The goal is to provide a generic example of how a lightweight dashboard can be built using HTML, JavaScript, jQuery, Tailwind CSS, and Chart.js, without requiring a frontend framework.

Overview of the Project

The dashboard was designed to organize different types of operational information into a single interface.

The main sections are:

Materials — Inventory organized by warehouse.
Assets — Assets organized by cost center.
PPE and Uniforms — Dedicated inventory information.
Movement History — Historical movements of materials.
Charts — Visual representation of quantities and values.
Search and Filters — Quick access to specific records.

The basic concept is:

Data
↓
Application Logic
↓
Dashboard
↓
Charts / Tables / Cards

Instead of presenting all information in a large table, the dashboard groups related information and provides different ways to analyze it.

Project Structure

The project uses a simple structure:

dashboard-ativos-materiais/
│
├── index.html
│
├── assets/
│ ├── css/
│ │ └── style.css
│ │
│ ├── img/
│ │ └── favicon.svg
│ │
│ └── js/
│ ├── app.js
│ └── mock-data.js
│
├── README.md
└── .gitignore

The JavaScript code is separated into two main files.

mock-data.js contains the data used by the public demonstration.

app.js contains the application logic, including rendering, filtering, searching, charts, and interactions.

This separation makes it easier to replace the mock data with a real API later.

Technologies Used

The project uses a relatively small frontend stack.

HTML

HTML provides the structure of the dashboard and its components.

Tailwind CSS

Tailwind CSS is used for the visual interface, including:

Cards
Buttons
Filters
Tables
Modals
Responsive layouts
Typography
jQuery

jQuery is responsible for the application's interactions and dynamic content.

It is used for:

DOM manipulation
Event handling
Filtering
Searching
Rendering
AJAX requests
Modal interactions
Chart.js

Chart.js is used to create visual representations of the dashboard data.

Dashboard Categories

The dashboard provides a simple category filter:

ALL
MATERIAL
PPE
ASSET

When the user changes the selected category, the interface updates the information displayed on the screen.

A simplified version of the interaction looks like this:

$("#filterType").on("change", function () {
const type = $(this).val();

filterDashboard(type);

});

This allows the dashboard to change its content without requiring a page reload.

Materials

The materials section organizes inventory by warehouse.

Each warehouse contains information such as:

Warehouse
├── Total Quantity
├── Total Value
└── Items
├── Item Code
├── Item Name
├── Quantity
├── Unit Value
└── Total Value

For example, a simplified data structure could look like this:

const material = {
warehouseCode: "WH01",
warehouseName: "Main Warehouse",
itemCode: "MAT001",
itemName: "Example Material",
quantity: 120,
unitValue: 25.50,
totalValue: 3060
};

The interface uses this information to create the corresponding cards and item details dynamically.

Assets

Assets follow a different grouping strategy.

Instead of warehouses, they are organized by cost center.

For example:

Cost Center 1001
│
├── Asset 001
├── Asset 002
└── Asset 003

This makes it possible to display the number of assets and their values according to the organizational structure represented by the data.

The same rendering concept used for materials can be reused here, while the grouping logic is adapted to the type of information being displayed.

PPE and Uniforms

PPE and uniforms have their own section in the dashboard.

The purpose is to keep these records separated from regular materials while maintaining the same visual language.

This allows the user to switch between different types of inventory without learning a completely different interface.

The dashboard also provides a search field.

A basic implementation can listen for changes in the input:

$("#search").on("input", function () {
const searchTerm = $(this).val().toLowerCase();

filterItems(searchTerm);

});

The search can then be applied to the relevant fields, such as:

Item code
Item name
Warehouse
Cost center

For larger datasets, a debounce can be used to avoid executing the filtering function unnecessarily on every keystroke.

The basic flow becomes:

User types
↓
Wait for input
↓
Search / Filter
↓
Update results
Using Mock Data

Because the original application was connected to internal APIs, the public version needed a different data source.

Instead of exposing the original endpoints, the project uses mock data.

For example:

const materials = [
{
warehouseCode: "WH01",
warehouseName: "Main Warehouse",
itemCode: "MAT001",
itemName: "Example Material",
quantity: 120,
unitValue: 25.50,
totalValue: 3060
},
{
warehouseCode: "WH02",
warehouseName: "Secondary Warehouse",
itemCode: "MAT002",
itemName: "Another Material",
quantity: 75,
unitValue: 18.00,
totalValue: 1350
}
];

The important part is that the UI doesn't need to know whether the information came from a mock file or an API.

The application only needs to receive data in the expected format.

Connecting the Dashboard to an API

This separation makes it possible to replace the mock data with a real API.

The public project follows this concept:

                ┌─────────────┐
                │  Dashboard  │
                └──────┬──────┘
                       │
                       ▼
                ┌─────────────┐
                │ JavaScript  │
                │  + jQuery   │
                └──────┬──────┘
                       │
                       ▼
                ┌─────────────┐
                │ Mock Data   │
                └─────────────┘

With a backend, the last layer can simply be replaced:

                ┌─────────────┐
                │  Dashboard  │
                └──────┬──────┘
                       │
                       ▼
                ┌─────────────┐
                │ JavaScript  │
                │  + jQuery   │
                └──────┬──────┘
                       │
                       ▼
                ┌─────────────┐
                │ REST API    │
                └──────┬──────┘
                       │
                       ▼
                ┌─────────────┐
                │ Database    │
                └─────────────┘

This is one of the main reasons for keeping the data layer separated from the interface.

Data Visualization with Chart.js

The dashboard provides a graphical view in addition to the traditional data view.

Chart.js can be used to transform the dataset into charts such as:

Doughnut charts
Bar charts
Ranking charts

A basic Chart.js configuration looks like this:

new Chart(canvas, {
type: "doughnut",
data: {
labels: labels,
datasets: [{
data: values
}]
}
});

The chart receives the same information used by the dashboard.

This means that the data doesn't need to be duplicated just to create a visualization.

Movement History

Another feature of the dashboard is the movement history for materials.

Instead of displaying only the current inventory:

Material: MAT001
Quantity: 120

the user can inspect previous movements.

For example:

Date Type Quantity

09/01/2026 Entry +50
09/05/2026 Exit -10
09/12/2026 Entry +80
09/20/2026 Exit -20

This provides additional context about the current quantity.

The public version uses simulated movement data, but the same structure can be connected to a backend API.

Why jQuery?

One question that naturally comes up is:

Why use jQuery instead of React, Vue, or another frontend framework?

The answer is mostly about project requirements.

This dashboard needs:

DOM manipulation
Event handling
Search
Filtering
Dynamic rendering
API communication
Modal interactions
Chart integration

These requirements can be handled comfortably with jQuery.

Using a framework would certainly be possible, but it would also introduce additional project structure and dependencies that aren't necessary for this particular implementation.

The goal was to keep the application:

Simple → Lightweight → Easy to understand → Easy to deploy

UI and Design

The dashboard uses a clean interface focused on the information itself.

The design uses:

White backgrounds
Green accent colors
Rounded cards
Subtle borders
Clear typography
Responsive layouts
Minimal visual noise

The intention was to avoid the traditional heavy-looking enterprise dashboard and create something closer to a modern productivity application.

The visual hierarchy follows a simple structure:

Header
↓
Filters
↓
Summary
↓
Data
↓
Charts / Details

This helps keep the most important information visible without overwhelming the user.

How the Application Works

The complete flow can be summarized as:

Load application ↓
Load data ↓
Normalize data ↓
Render dashboard ↓
User selects a filter ↓
Filter dataset ↓
Update interface ↓
Update charts

For a search operation:

User enters search
↓
Search term is normalized
↓
Dataset is filtered
↓
Matching records are rendered
↓
Dashboard is updated

This keeps the interaction entirely on the client side in the public version.

Benefits and Use Cases
Reusable

The dashboard isn't tied to a specific company or database in its public version.

The data layer can be replaced with another source.

Lightweight

There is no complex frontend build system required.

The project can run as a simple web application.

Scalable

The same structure can be extended with additional categories, filters, charts, or API endpoints.

Easy to Customize

Because the interface is built with HTML, Tailwind CSS and JavaScript, the visual design can be modified without changing the entire application architecture.

API Ready

The mock data layer can be replaced with a REST API when real data becomes available.

What I Learned

This project reinforced an important idea:

A dashboard isn't just about displaying data. It's about making data easier to understand.

Creating a chart is relatively easy.

The more interesting challenge is deciding:

What information should be highlighted?
What should be grouped?
What should be a card?
What should be a table?
What should become a chart?
What does the user actually need to find?

These decisions have a direct impact on the usefulness of the application.

Future Improvements

There are several things that could be added to future versions:

REST API integration

Authentication

Role-based access

Advanced filters

Excel export

PDF reports

Pagination

More detailed analytics

Mobile improvements

Dark mode

The current version intentionally focuses on the frontend and uses mock data.

Running the Project

Clone the repository:

git clone YOUR_REPOSITORY_URL

Enter the project directory:

cd dashboard-ativos-materiais

Then open the project using a local development server.

For example, you can use VS Code with Live Server.

Since the public version uses mock data, no backend configuration is required.

Conclusion

This project started as a practical internal dashboard and evolved into a generic version that can be shared publicly.

The main goal was not to build the most complex dashboard possible.

It was to create a solution that is:

Simple
Visual
Responsive
Easy to understand
Easy to customize
Ready for API integration

The public version is available on GitHub, using mock data instead of the original internal integrations.

If you're interested in dashboards, data visualization, jQuery, Tailwind CSS, or lightweight frontend applications, feel free to explore the project.

GitHub Repository

👉 https://github.com/C0aste/Dashboard-Estoque

If you have suggestions or ideas for improvements, feel free to share them in the comments.

Thanks for reading! 🚀

Tracking Video Watch Progress with JavaScript

Coaste — Wed, 11 Dec 2024 11:45:21 +0000

In modern web applications, it is essential to provide users with a seamless experience where their progress is saved across sessions. One of the most common use cases for this is tracking how much of a video a user has watched, so they can pick up where they left off. This tutorial will walk you through how to implement such a system using JavaScript, localStorage, and event listeners, while also integrating server-side communication to store watched time.

Overview of the Code

**
The provided solution allows for tracking the watched time of multiple videos on a webpage. It stores the watch progress in the browser’s localStorage and, if a user exceeds the last watched time, updates the progress in a server-side database using a POST request. The goal is to offer a generic, scalable method that works for all videos with minimal effort.

<video class="videoCourse" controls data-idvideo="123">
  <source src="path/to/video.mp4" type="video/mp4">
  Your browser does not support the video tag.
</video>

<video class="videoCourse" controls data-idvideo="123">

: This element embeds a video player on the page.

The class="videoCourse" is used to select all videos on the page via JavaScript.
The data-idvideo="123" is a custom attribute that holds a unique identifier for each video. This ID allows us to track and store the watch progress for individual videos.
: Specifies the path to the video file and the video format (in this case, MP4)

// Function to update the watched time
function updateWatchedTime(video, videoId) {
    var timeInSeconds = video.currentTime; // Time watched in seconds
    var minutes = Math.floor(timeInSeconds / 60); // Whole part (minutes)
    var seconds = timeInSeconds % 60; // Remaining seconds
    var decimalTime = minutes + (seconds / 60); // Converts seconds into a fractional minute

    // Get the last recorded time for the video (saved in localStorage or a global variable)
    var lastRecordedTime = localStorage.getItem("lastRecordedTime_" + videoId);
    if (lastRecordedTime === null) {
        lastRecordedTime = 0; // Default value if no previous time is found
    } else {
        lastRecordedTime = parseFloat(lastRecordedTime);
    }

    // Check if the current time is greater than the last recorded time
    if (decimalTime > lastRecordedTime) {
        // If the current time is greater, save the new time
        var requestData = "VIDEO_ID=" + videoId + "&WATCHED_TIME=" + decimalTime.toFixed(4);
        console.log("Sending: " + requestData); // Shows the watched time in decimal (4 decimal places)

        // Send the data to the server (replace with actual URL)
        $.post("path/to/api", requestData, function(response) {
            // Handle server response if needed
            console.log("Server response: " + response);
            // After saving, update the localStorage with the new watched time
            localStorage.setItem("lastRecordedTime_" + videoId, decimalTime.toFixed(4));
        });
    } else {
        console.log("Watched time is less than the last recorded time. No update sent.");
    }
}

// Add an event listener for the 'timeupdate' event to all video elements
document.querySelectorAll('.videoCourse').forEach(function(video) {
    // Get the video ID (should be uniquely assigned to each video element)
    var videoId = video.getAttribute('data-idvideo');
    // Add the 'timeupdate' event listener
    video.addEventListener('timeupdate', function(event) {
        updateWatchedTime(video, videoId); // Pass the video and its ID directly
    });
});

Explanation of the Code

Update Watched Time Function** The core of this solution is the updateWatchedTime() function. This function is responsible for:

Calculating the Watch Progress: The function first retrieves the currentTime of the video (in seconds) and converts this into minutes and seconds. The time is then converted to a decimal format (e.g., 3 minutes 30 seconds becomes 3.50).

Checking the Last Recorded Time: Using the localStorage.getItem() method, we retrieve the last recorded time for the video. If no time has been recorded yet (i.e., the first time the user watches the video), it defaults to 0. This ensures that progress tracking starts from zero.

Storing the Time: If the current time is greater than the last recorded time, it means the user has watched more of the video since the last update. The function sends the updated time to the server using a POST request. After the data is successfully sent, the localStorage is updated with the new time.

2. Handling Multiple Videos
The script adds an event listener to all videos on the page with the class="videoCourse". It uses the data-idvideo attribute to get the unique video ID and tracks the progress for each individual video.

Event Listener: Every time the video’s time is updated (i.e., as the user watches the video), the timeupdate event is triggered. This event fires continuously as the video plays, providing an opportunity to track the progress.

querySelectorAll(): This method selects all video elements on the page, making the script adaptable for any number of videos. It loops through each video, attaching the timeupdate listener, ensuring that the watch progress is tracked for each video independently.

How This Works: A Step-by-Step Flow

**
User Watches Video: As the user watches the video, the timeupdate event continuously triggers.
Watch Progress Calculated: The script calculates how much of the video has been watched in minutes and seconds, then converts it to a decimal format.
Last Recorded Time: The script compares the current watch time to the last recorded time saved in localStorage.
Update if Necessary: If the current watch time is greater than the previously saved time, the new time is sent to the server. Afterward, the new time is saved in localStorage.
Next Visit: The next time the user visits the page, the script checks localStorage for the last saved time. If available, it starts tracking from where the user left off.

Benefits and Use Cases

**
Scalability: This approach works for any number of videos on a page. It uses the data-idvideo attribute to uniquely identify each video, making the system scalable without modification.
Persistence: Using localStorage, the user’s progress is saved across sessions. Even if the page is reloaded or if the user leaves and returns, their progress is retained.
Seamless Integration: The solution integrates smoothly with existing video players, making it easy to implement on websites that already use the HTML5 tag.
Server Integration: The system allows you to send the watch progress to the server, providing a way to track user engagement and provide insights into how users interact with video content.

Tailwind - Fixed bottom

Coaste — Thu, 14 Mar 2024 13:47:27 +0000

In Tailwind's docs, they don't mention how to create a button to take you back to the top, but I've come across one solution for this issue:

when you create and set up your application, copy and paste this code in the top of your page.

 <img src="yourimage.png" alt="Up Your Page">
 <span>Subir Página</span>

This button (when you click) does your page return to the first div.

Tailwind - Forms

Coaste — Thu, 15 Feb 2024 17:30:53 +0000

Installation,
Latest version (Using NPM)

npm install flowbite

Creating a "tailwind.config.js" file, put this code:

module.exports = {

    plugins: [
      require('flowbite/plugin')

 ]
    content: [
        "./node_modules/flowbite/**/*.js"
    ]
}

Require the JavaScript code that powers the interactive elements before the end of your *body * tag:

<script src="../path/to/flowbite/dist/flowbite.min.js"></script>

or include via CDN (not recommended)
If you want to quickly test out Flowbite you can easily include the following CSS and JavaScript files.

<link href="https://cdnjs.cloudflare.com/ajax/libs/flowbite/2.3.0/flowbite.min.css"  rel="stylesheet" />
<script src="https://cdnjs.cloudflare.com/ajax/libs/flowbite/2.3.0/flowbite.min.js"></script>