PunctuOwlity exists as two parallel implementations of the same product: a native Android application written in Java and a static web application built with plain HTML, CSS, and JavaScript. Both versions present an identical user-facing workflow and the same visual design, but they rely on entirely different technology stacks to store data, manage navigation, and handle permissions. Understanding both sides of the project reveals how a mobile-first interface can be faithfully reproduced without a framework, a build tool, or a backend server.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/apursley2012/PunctuOwlity/llms.txt
Use this file to discover all available pages before exploring further.
Navigation Flow
Both versions follow the same linear onboarding sequence before landing the user on the main event grid. First-time users complete account creation and are then asked about SMS/notification preferences. Returning users go straight from login to the events screen.Login
The application opens on the login screen. The user enters a username (or email on the web version) and password. Invalid credentials show a toast/snackbar message.
Sign Up (new users only)
From the login screen, the user navigates to the sign-up form. After a successful account creation, the app returns to login.
SMS / Notification Preference
On first access to the events screen, the user is asked whether they want to receive alerts. This step is skipped on subsequent visits once the preference has been stored.
Events Grid
The main screen displays all saved events in a two-column card grid. Cards can be searched, filtered by category, edited, or deleted. A floating action button opens the add-event form.
Platform Structure
The two implementations share a workflow but differ substantially in how that workflow is built.- Web App
- Android App
The web application is a set of static files with no build step, no bundler, and no third-party dependencies. Every page is a standalone HTML file that loads a single shared script (
app.js) and one stylesheet (styles.css). Navigation between pages uses location.assign() and location.replace(). No server is required — the project can be opened directly from the filesystem via a file:// URL or hosted on GitHub Pages.| File | Role |
|---|---|
index.html | Login page (data-page="login") |
signup.html | Account creation form |
sms.html | SMS/notification preference prompt |
events.html | Main events grid (data-page="main") |
add-event.html | Add and edit event form (data-page="add") |
app.js | All application logic — auth, storage, rendering, normalization |
styles.css | All visual styles |
app.js uses document.body.dataset.page to detect which page is active and runs only the relevant logic for that context. There are no imports, no modules, and no compilation.Shared Visual Identity
Despite being built in different technologies, both versions implement the same visual design derived from the original Android XML layouts and screenshots.Coral Toolbar
The top toolbar uses a coral background (
#f1575d). In the Android project this value appears in drawable tint attributes; in the web app it is declared as the --coral CSS custom property in styles.css.Teal Date Banner
The month label below the heading appears on a teal strip (
#2fc7c9). In the Android project this is referenced via date_banner_teal.xml; in the web app it is the .date-banner element styled with the --turquoise CSS custom property in styles.css.Navy Text
Body text and card content use a dark navy color (
#000050) throughout both versions. The Android project references this value in drawable tint attributes; the web app declares it as the --navy CSS custom property.Two-Column Event Grid
Events are always displayed in a two-column card grid. The Android layout uses
GridLayout; the web version uses a CSS grid. Both versions maintain exactly two columns across all supported widths.Responsive Scaling Strategy
The web version does not reflow the grid to three or four columns on wider screens. Instead, the entire interface scales proportionally — text, controls, spacing, and imagery grow with the available viewport width while the two-column card arrangement is preserved. Only extremely narrow screens fall back to a single column to prevent clipped content and unusable controls.This approach was intentional. The case study explains the guiding principle directly: “responsive conversion is not the same thing as redesign.” The goal of the web version was to protect the existing visual relationships first, then make those relationships flexible enough to work across screen sizes — not to produce a different dashboard layout for desktop users.