Back to 5.1 User Interface (GUI)

Design and Ideation

Before any code was written, three design decisions had to be resolved. Each had direct consequences for feasibility, usability, and maintainability. The options considered for each decision are documented below.

The starting point was not the software stack. It was the training product brief: boxers needed a way to start sessions quickly, follow drills without confusion, and review progress without leaving the training flow. The ideas below were selected against that use case first, then against implementation constraints.

V-Model alignment: This page corresponds to the left side of the V, where product needs from Appendix 6 are decomposed into concrete GUI design decisions.

Need-to-Design Translation Product needs are translated into interface choices before implementation begins. Appendix 6 need Training, usability, progression, feedback GUI concept Flow, touch targets, state visibility Design choice PySide6, stack navigation, curriculum pages Training effect Fast, readable, coach-like flow

Framework Selection

The project had a four-month development window from December 2025 to April 2026. The chosen framework needed to run on the Jetson Orin NX without additional configuration, support touchscreen interaction natively, and be learnable quickly enough to leave adequate time for feature development. Four options were evaluated.

The decision was also driven by training UX. The framework had to support large touch targets, fast page switching, and layouts that stay readable during movement and short glances between punches.

Evaluation criteria: native compatibility with the Jetson Nano (Ubuntu 20.04), touchscreen layout support, development speed relative to existing Python knowledge, quality of community documentation, and open-source licence.

PySide6 was selected. It runs natively on the Jetson Orin NX, has mature touchscreen layout support, and builds on existing Python knowledge. The extensive Qt documentation reduced the risk of hitting unresolvable blockers within the compressed timeline, while still leaving enough headroom for a training-focused interface.

Navigation Architecture

Three navigation paradigms were evaluated against the core requirement that any feature must be reachable within a small number of interactions from the main menu, and that the interface must remain usable via both touchscreen and physical button input.

In training terms, this was about preserving rhythm. A boxer should be able to move from login to drill selection to session start without breaking focus or hunting through menus.

Evaluation criteria: operability via the robot's padded controls (large touch targets to accommodate reliable padding-based screen presses, minimal precision tapping), efficient use of the 7-inch screen area, support for multi-step sequential workflows, and clarity of navigation state for non-expert users.

Flat menu Rejected Tab-based Rejected Hierarchical stack Selected 44 pages on one screen Unusable at this scale Tab1 Tab2 Tab3 ... Reduced content area Tab bar always visible Wastes screen space Main menu Training ... Combo Spar Navigation stack Automatic back-button Full screen per page

The hierarchical page stack was selected. This approach naturally models how a boxing training session is structured: the user makes a series of sequential choices to configure a session, trains, and then reviews results. The navigation stack implementation meant that back button behaviour was handled centrally rather than being manually coded per page, which kept the codebase manageable as the page count grew past 40.

Data Storage

Multiple users share a single BoxBunny unit, so a data isolation strategy was needed to keep each user's training history private. Three strategies were evaluated.

Evaluation criteria: complete user privacy (no cross-user data leakage), implementation complexity, portability of individual user records, and support for add and remove account operations without a centralised admin database.

A per-user database file approach was selected. Each user's data is stored under users/[username]/ in two SQLite files: one for combination training progress and one for performance test results. Adding or removing an account is as simple as creating or deleting a folder, which also eliminated the need for a centralised account management database.

From the product side, this supports a personal training history. A boxer expects their progress, scores, and test results to stay attached to their own profile, not blend into someone else’s session record.

Combo Curriculum Learning Approach

The combo curriculum needed a learning model to govern how users progress through the 50-combo library. Three approaches were evaluated against the requirements that progression should feel structured, mastery should be measurable, and the system should mirror how boxing coaches actually structure pad work.

This is where the product story matters most. The curriculum is not just a list of combinations. It is the training path the boxer sees over repeated sessions, so the structure had to feel like coaching progression rather than arbitrary unlocks.

Evaluation criteria: alignment with established mastery learning theory, measurability of progression, implementation complexity within the project timeline, and whether the resulting progression would feel structured and coaching-like to the user.

Sparring Sequence Generation

Sparring mode requires the robot to generate punch sequences that feel unpredictable and stylistically coherent. The Function Analysis (Section 3.1) identified "Unpredictability in sparring" as a key function, with solution principles including pose estimation, hardcoded random sequences, and wearable sensors. Three software-side generation strategies were evaluated.

The product question was simple: would a boxer feel challenged by the session, or would it feel scripted? That user experience target drove the choice of generation strategy.

Evaluation criteria: perceived unpredictability from the user's perspective, ability to incorporate a per-user weakness profile, computational cost on the Jetson Nano 4 GB, and implementation complexity within the remaining development window.

Display Hardware Selection

Original Display

The original display was a 7-inch resistive touchscreen at 1024x600 resolution, selected for its low cost and direct DSI compatibility with the Jetson Orin NX. All six development iterations were built and tested against this display. The layout, font sizing, and touch target geometry were designed for a 7-inch form factor.

This decision had a direct training effect. The display needed to stay readable while users were moving, sweating, and glancing at the screen between drills.

User Observations at the Showcase

During user testing at the "Robotics Meets AI Showcase" event (within the Robotics and AI in Work and Play segment), two displays were available: the 7-inch screen mounted on the robot and a larger monitor connected to the same system. Observers and participants consistently gravitated toward the larger monitor for reading analytics and navigating the interface. Feedback indicated that users preferred larger text, more visible statistics during training, and found the smaller screen difficult to read during active sessions.

Display Upgrade

Based on these observations, the display was upgraded to a 10.1-inch IPS capacitive touchscreen at 1280x800 resolution (DSI interface, Raspberry Pi compatible, also confirmed working on the Jetson Orin NX). The timeline did not allow for a full redesign cycle, so this is framed as a hardware revision informed by user observation rather than an iterative software redesign. The existing layout scaled to the larger display without breaking, as the GUI used proportional sizing rather than fixed pixel coordinates for most layout elements.

Phone Dashboard Companion

A companion interface was needed to let users review training analytics and control the robot from their phone without walking to the touchscreen between rounds. Three approaches were evaluated.

The dashboard existed to extend the training product beyond the robot itself. A boxer should be able to check progress, adjust sessions, and review results from the side of the gym as easily as from the touchscreen.

Authentication Method

The touchscreen authentication method was designed for quick bare-hand use, with a pattern lock that avoids fine-motor input and keeps login fast at the start of training. The pattern lock interface is documented in Appendix 3.

This was not just a security choice. It was a product usability choice, because login had to fit the same physical constraints as the rest of the training flow.

The proficiency assessment presented during signup determines the user's initial skill level and adjusts the default training tier accordingly.

Design System

A centralized design system was established to ensure visual consistency across all pages and to make future modifications straightforward. All visual tokens are defined in a single theme.py file, and no inline hex codes appear elsewhere in the codebase.

Design System Snapshot A high-level view of palette, typography, spacing, and punch-type accents. Background color so the interface stays calm and low glare. Foreground and action contrast so buttons stay readable. Typography scale so headings and body text feel balanced. Punch colours so training states stay consistent across pages. Touch target scale so controls stay easy to hit.

The key design decisions include a dark theme with a deep navy-black background (#0B0F14) chosen to reduce glare under bright gym lighting, a warm orange (#FF6B35) primary accent for call-to-action buttons and active states, and the Inter font family loaded as a custom variable-weight font. All interactive elements maintain a minimum 60px touch target so they remain easy to hit with bare hands during normal use, while the padded targets feed the training interactions during drills. Each of the six punch types is assigned a distinct color (blue for jab, coral for cross, green for lead hook, amber for rear hook, purple for lead uppercut, yellow for rear uppercut) used consistently across combo displays, charts, and analytics. The UI is designed at 1024x600 pixels and uniformly scaled via QGraphicsView for fullscreen display, ensuring proportions hold regardless of the actual screen resolution.

References