8. UI Overview

UI Overview

Language: English. Chinese version: 8. UI Overview (中文)

Trail Mate’s device UI is not a disposable shell. It directly determines whether a user can understand current state and complete actions without a phone, without a network, and under limited screen and input conditions.

This page does not document every pixel. It explains how the current device UI is organized and why the interaction differs across hardware targets.

What The Main Interface Contains

Based on the shared UI modules and application-shell assembly logic, the current main menu can include pages such as:

• Map
• Sky Plot
• Tracker
• Chat
• Contacts
• Team
• Data Exchange
• SSTV
• Energy Sweep
• Walkie Talkie
• USB Mass Storage
• Setting

That does not mean every device shows the exact same menu forever. Menus are built dynamically based on capability gates. If a target does not support Team, HostLink, or a required input model, the corresponding page is hidden instead of leaving a dead entry visible.

The Role Of The Main Pages

Map

The map page is the center of orientation and position awareness. It is not meant to be a complete navigation app. It is the device-side minimum viable map for disconnected field use.

Sky Plot

This page is primarily a status and diagnosis tool. It answers whether GPS is actually seeing satellites and whether a fix is being built, which makes it more useful for troubleshooting than just looking at one map marker.

Tracker

Track and route-related workflows are separated from the live map view. That helps distinguish between “what is happening now” and “which route or track files are being managed”.

Chat and Contacts

These two pages together form the communication view. Chat handles conversations and sending. Contacts are more about node presence, recent activity, and entering a conversation from a node list.

Team

When the hardware supports Team, this page is a coordination view rather than an ordinary group-chat page.

Data Exchange and USB Mass Storage

These pages reflect that Trail Mate is not designed as a totally isolated handheld. One is about structured device-to-host exchange, the other about resource and file handling at the storage layer.

Energy Sweep, Walkie Talkie, and SSTV

These pages are not decorative extras for a README feature list. They reflect extensions related to RF environment assessment, voice experiments, and more specialized field capabilities. Whether they appear depends on the current target and build path.

Menu Order Is Not Completely Fixed

The current code does not force PlatformIO and ESP-IDF routes into one identical menu order. Page composition is shared, but assembly order and visibility can vary by shell and capability state.

That reflects an important design choice: the information architecture should stay coherent, but platform and hardware realities should still be allowed to shape the visible shell.

Why Input Behavior Differs Across Devices

This is a normal consequence of a multi-hardware project, not a UI design mistake.

T-Deck

T-Deck combines keyboard, touch, and trackball. In Trail Mate, the trackball is mapped more like directional or rotary navigation input than like a free mouse cursor.

T-LoRa-Pager

Pager leans more on a knob, center key, and keyboard combination. That makes it well suited to text entry and layered menu navigation.

GAT562 Mesh EVB Pro

This is a monochrome route with a 5-way joystick. Its UI should be understood as a dense limited-device status interface, not as a reduced copy of the touch-screen experience.

T-Watch S3, Tab5, and T-Display P4

These targets lean more toward touch, but they do not all have the same maturity. The large-screen IDF route already shares substantial structure, but board-level interaction is still evolving.

Why The Project Does Not Force All Devices To Feel The Same

Trail Mate is optimized for “actually usable on this device”, not for “screenshots look uniform”.

If a board only has a joystick and a monochrome display, forcing it to imitate the page depth and pacing of a touch-driven large-screen device usually makes it worse, not better.

So the project aims for consistency in:

• information structure
• capability meaning
• page naming and page boundaries

It does not aim for identical interaction feel across every board.

Current UI Design Principles

Make state legible before making it playful

In disconnected, low-battery, and weak-link conditions, users need to know what state the device is in. Trail Mate therefore favors visible status, clear page boundaries, and direct interaction over visual flourish.

Keep the main path short

Map, chat, contacts, and settings are high-frequency destinations. The main menu stays organized around those paths rather than burying them under deep tree structures.

Gate capabilities by hardware reality

It is better to hide a page on a device that cannot support it than to display a uniform shell full of unusable entry points.

Treat outdoor conditions as real constraints

That means avoiding over-dependence on complex gestures, long text input, or long stays inside high-cognitive-load pages.

Current Known Device Differences

The following differences should be treated as expected facts, not assumed bugs:

• GAT562 follows a constrained monochrome route and does not include Team, HostLink, SD, or CJK
• T-Watch S3 is currently not the full map, GPS, and SD reference path
• T-Deck trackball behavior differs from pure touch targets
• large-screen IDF targets are not yet identical in maturity to the main PlatformIO handheld route

The Most Important Point For Future Maintainers

The easiest way to damage the UI is not through ugly code. It is by pushing the project back toward “every device should look like a small phone app”.

The value of Trail Mate’s UI comes from acknowledging device differences and constrained conditions, then choosing information carefully under those constraints. If a UI change makes state harder to read, depends more on touch, or assumes longer text entry everywhere, it is probably moving away from the project’s actual direction.

Information Still Worth Expanding

Good next additions would include:

• screenshots and structure notes for major pages
• input-mapping comparisons across devices
• a clearer explanation of monochrome UI versus shared UI
• the interaction split between small-screen and large-screen routes

For now, the most important thing is to explain how the UI is assembled and gated so that device differences are understood as design consequences rather than accidents.