Flight Details and Precision Timing Schedule (PTS) - Interactive web application for flight operations management
Open v1.22 stable: https://jackyyouyang-commits.github.io/PTS-FlightApp/PTS_FlightApp.html
The three updates below are now included in the existing stable v1.22 app. Its version label, installed-app identity, saved-flight storage, 1.1-second QR cycling and transfer-file format are unchanged. Open the stable app online once to receive the updated offline assets. No Fast or Compact QR experiment is added to stable.
In Flight Info, Arrival Info and Departure Info now open dropdown navigation links to their respective sections. Choose a link to scroll to that section without hiding fields or changing flight data. The menus support touch, keyboard navigation and Escape to close. The toolbar occupies its own non-scrolling row below the app navigation, rather than relying on mobile browser sticky positioning. It stays visible while Flight Info scrolls, including after a section jump, and hides on other tabs. On narrow screens the toolbar remains horizontally scrollable, while open dropdowns fit inside the viewport and scroll vertically as needed.
Special handling keeps the complete Excel value. Arrival Loading and Final Loading show counts together with seat numbers and notes, for example 4 (22G 23DK), across all special-handling categories. Long values wrap within the summary; import preview, fields, reports, saves and transfers retain the text. Previously saved arrival WCHR/S details are recombined with their count when available. Earlier departure imports discarded WCHR/S details, so re-import the original Excel data to restore those missing details.
PTS variance uses local clock times, not the age of the saved Flight Info date. All arrival/departure rows and printed variances use the nearest signed time difference across midnight: target 21:06 / actual 21:26 is +00:20, 23:50 / 00:10 is +00:20, and 00:10 / 23:50 is -00:20. The ATD disruption delay uses the same rule against STD; ETA HKG uses that same inferred ATD day. Arrival actuals still adjust subsequent arrival targets; departure targets still use STD and the 95-minute turnaround rule, not departure actuals. Time-only entries cannot distinguish genuine delays longer than 12 hours or multiple days; exactly 12 hours keeps the same-day sign. Reopening a saved flight on another day does not add 24 hours to its variance. Scheduled ETD/boarding countdowns retain their existing flight-date behavior.
Open v1.23 beta: https://jackyyouyang-commits.github.io/PTS-FlightApp/beta/PTS_FlightApp.html
The separate beta also includes the three updates above. Saved beta flights and its installed-app identity are retained, separate from stable and the deleted per-tab experiment. In beta, select Connect, then choose Normal (1.1 seconds/QR) or Fast (0.5 seconds/QR) on the laptop. Normal is the default on each page load. The QR grows to at most 480px where the viewport permits and shrinks on small screens; the dialog scrolls to keep controls reachable. On the other device, use Scan QR Code to Connect.
Speed changes affect only the outgoing timer: the current frame, complete payload, transfer ID and collected receiver parts stay unchanged. One QR remains static in either mode. The dialog shows the actual part count and selected-mode minimum full cycle. For 1,000 parts, Normal takes at least 18m 20s, Fast 8m 20s per cycle. Missed frames require extra cycles, and Fast may miss more; no physical iPad speed improvement has been measured. Enlarging the QR does not reduce the part count.
The stable complete-flight protocol, 650-character parts, integrity checks, viewing-copy quality, every image/PDF page, and all flight/schedule import and auto-field behavior are retained. Flight data travels in QR images only: no backend upload or device-to-device network transfer. Loading the app/PDF.js may require internet access; content is processed locally.
Fast QR beta uses a new isolated storage namespace, distinct from both stable and the deleted per-tab beta. To seed it without re-entering a laptop flight, Save in stable, then open beta Connect > Whole-flight beta help / copy saved stable flight > Copy saved flight from stable v1.22. Confirm replacement of the entire beta flight. This explicitly reads a detached copy of stable’s complete snapshot, without changing stable or falling back to stale standalone fields. The existing local transfer-file import/export is also available.
Its separate PWA identity and beta-scoped worker use only Fast QR beta caches, never an old per-tab cache or stable cache. Open online once to replace an old beta worker and install this experiment’s offline assets. The stable worker can evict other caches on activation; reopen beta online if its offline cache is lost. PDF viewing-copy preparation may still need PDF.js online; the original-attachment fallback remains explicit.
In Connect, select Download Transfer File to save one compressed *-PTS-Connect.txt file containing the complete flight and original attachments. Move it to the iPad using a company-approved method, then choose Save to Files and select a folder such as Downloads. In the app, use Connect > Upload Transfer File (or Read Transfer File Locally in beta) to select it. This reads the file on the device; it does not upload flight data to a server.
Existing .pts files remain compatible. The picker no longer filters by extension or MIME type, which can grey out custom file types on iPad; the importer still checks the PTS transfer contents and rejects unrelated files. New downloads use the standard .txt extension and text/plain type without changing the compressed format. Renaming an unrelated document does not make it a PTS transfer file. Company restrictions on Safari accessing a file or its storage provider can still prevent selection.
The transfer includes Flight Info, PTS actual times, all operational text tabs, rich formatting, pasted images, and imported PDFs. Data is imported only after the complete sequence passes its integrity check, then saved immediately on the receiving device. It remains compatible with the single- and multi-part QR formats introduced in 43e25dc.
A single QR is intentionally static. When all current data fits in 650 compressed characters, the status reads QR 1 of 1. Larger payloads automatically cycle through 650-character parts every 1.1 seconds, with the same 320px QR display. Parts are chunks of the complete flight, not one QR per tab.
QR transfer uses viewing copies, not smaller desktop originals. Plain text, table data and rich formatting are preserved; no tab, image or PDF page is discarded or cropped. Suitable images are reduced to at most 1600 pixels wide (long screenshots retain their full height at that scale). Opaque images may use JPEG quality 0.8; transparent images retain transparency, and vector/animated images remain intact. PDFs are rebuilt as readable page images with every page and its aspect ratio preserved; these PDF viewing copies do not retain selectable/searchable text. All processing is on the sending device. PDF rendering uses the app’s existing PDF.js loader and may need internet access to load that library, but flight content is not uploaded. Desktop attachments and saved state are unchanged.
The dialog compares original and outgoing payload sizes and shows the outgoing QR part count and minimum full-cycle time. For source payloads up to 8 MB, it also compares original QR part counts and keeps the smaller complete sequence; larger source payloads skip that extra compression pass to limit memory use. Allow additional cycles for missed scans: for example, 1,000 parts require at least 18 minutes 20 seconds per cycle and can still take much longer to receive completely. This is not an instant transfer. Individual attachments are kept unchanged when their viewing copies would be larger. If preparation fails, the dialog names the failed attachment and offers an explicit Use original attachments (slower) fallback; nothing is silently omitted. Closing the dialog or switching to the scanner cancels preparation.
The Connect dialog shows how many operational tabs on this device contain content. If it says no flight data is loaded, populate the laptop app before sending, or use the scanner on the receiving device. The laptop only displays the QR and does not need camera access. Cancelling scanning or encountering a camera error returns to the outgoing QR display and resumes any multi-part sequence.
No file picker, download, upload, or account is required for QR transfer. The iPad must permit camera access to the HTTPS app; the app cannot override company device restrictions. If storage is full or blocked, Flight Data Retrieved - Not Saved warns that the received flight is not yet saved; keep the page open and retry Save when storage is available. Complete-flight ten-minute autosave and save-before-suspension remain in place.