A focused implementation using Next.js and PostgreSQL

Purpose of the update

This update focuses on two parts of the attendance experience: confirming an employee’s location for office attendance and recording work from home attendance correctly. I kept the flow simple because employees should not need technical knowledge to mark their attendance. The screen guides them through the required steps, while the server checks the information before it saves a record.

The location feature adds useful context to an office check in. A time stamp shows when an employee submitted attendance, but it does not show whether the employee was near the approved workplace. By collecting the current latitude and longitude, the system can compare the employee’s position with the office location. This gives the attendance record more meaning without adding a long form or extra manual work.

How location based attendance works

When the employee opens the attendance page, the browser asks for permission to access the device location. The request must be clear and should only appear when location is needed. If the employee allows access, the browser returns the current coordinates. The page holds these values temporarily and prepares them for the attendance request.

Before sending the request, the page checks that both coordinate values are available and valid. It also checks that the user has selected the correct attendance action. During this step, the button shows a loading state so the employee knows the system is working. This prevents repeated clicks and reduces the chance of duplicate submissions.

If location permission is denied, the page does not send an incomplete record. It explains that location access is required for office attendance and asks the employee to enable permission in the browser settings. The same approach is used when the device cannot find a location or when the request takes too long. A useful error message tells the employee what happened and what action to take next.

After the coordinates are available, the system can calculate the distance between the employee and the approved office position. If the employee is inside the allowed radius, the office attendance request can continue. If the employee is outside the radius, the page shows a direct message and does not create an office check in. This keeps the result predictable for both employees and administrators.

Next.js and PostgreSQL Implementation

Next.js user flow

I used Next.js to manage the employee’s interaction with the attendance page. The page controls when to request location, when to enable the attendance button, and what message to show after each action. Keeping these states separate makes the screen easier to understand and prevents the interface from changing in unexpected ways.

The location request starts in the browser because the device must provide the coordinates. When the request succeeds, the page stores the values in its current state and displays that the location is ready. When it fails, the page stores the error instead. The attendance button remains unavailable until the page has enough valid information to continue.

The page then sends a structured request to the server. The request includes the employee reference, attendance action, selected work type, current coordinates, and the client time when needed. The server should never trust these values automatically. It checks the authenticated user, confirms the expected fields, and applies the attendance rules before writing anything to the database.

PostgreSQL record design

PostgreSQL stores the approved attendance record. For this focused flow, the important fields include the employee reference, check in or check out time, work type, latitude, longitude, and attendance status. The database can also keep the approved office reference or the calculated distance when the business needs that information for review.

The server uses one clear database operation for each attendance action. Before creating a new record, it checks whether the employee already has an active record for the same day or period. This protects the data from duplicate entries. It also returns a specific response so the page can show a useful message instead of a general error.

Location values should have suitable numeric precision, and optional values should remain empty only when the selected work type allows it. Office attendance normally requires coordinates. A work from home entry may save the available location for reference, but it should follow a separate rule instead of using the office radius check. This distinction keeps the database record clear.

Reliable feedback and safe failure

Every result returns to the Next.js page in a simple format. A successful request confirms that attendance has been recorded. A validation problem explains which information is missing. A server or network problem asks the employee to try again without pretending that the record was saved. This feedback is important because the employee needs to know whether the attendance action actually reached the database.

Work From Home Attendance Flow

A separate work from home path

Work from home attendance follows a different rule from office attendance. A remote employee should not fail the check in because the device is outside the office radius. For this reason, the employee selects Work From Home before submitting attendance. The selected work type tells the server which validation path to use.

The page still collects the basic attendance details and may request the current location when the organization needs it for reference. However, the server does not compare the employee with the office radius. It validates the user, checks for an existing attendance record, confirms that Work From Home is an allowed option, and then saves the entry with a clear remote work status.

This separation avoids confusing records. An office check in shows that the employee met the office location rule. A work from home check in shows that the employee used the approved remote flow. Administrators can review both types in the same attendance list while still understanding where and how each employee worked.

User interface checks

I reviewed the attendance screens for common interface problems. The main checks included button states, field alignment, spacing, message visibility, and text wrapping on desktop and mobile sizes. I also checked what the screen shows while location is loading, after permission is denied, and when the server returns an error. These states matter because most attendance problems happen when the normal flow is interrupted.

The interface should not show a success message until the server confirms that PostgreSQL saved the record. It should also prevent another click while the first request is running. Clear labels help the employee understand whether the current action is Office or Work From Home. This reduces accidental submissions under the wrong work type.

Project verification

I also checked how the new attendance work connects with the existing project. The review covered the page route, server request, database fields, authentication check, and the response shown to the user. The next testing step should use real office coordinates, different browser permission settings, mobile devices, duplicate attendance attempts, and approved work from home accounts.

The final design keeps the two flows easy to understand. Office attendance uses the employee’s current location and the approved office radius. Work from home attendance uses a separate status and validation path. Next.js manages the interaction, the server applies the rules, and PostgreSQL stores the final result. This structure keeps the experience simple for employees and makes the records easier to review.