Navigation and information architecture findings¶
Status: Complete and rechecked
Findings: 6
Why the method was expanded¶
The first navigation pass relied too heavily on depth, menu length, and touch-target size. Those checks matter, but they do not show whether a choice is necessary, whether its label matches the user's goal, or whether specialist actions consume attention on a common path.
The earlier "nine items means the menu passes" rule was removed. PR #894 showed why: a Home Settings row could fit on screen while still adding Printer and Encryption choices to every Home visit. PR #894 is closed and issue #790 remains open.
The expanded method records:
- the choices on each screen and the meaning of each branch;
- minimum M5StickV inputs and recovery after a wrong choice;
- whether labels predict their result;
- whether common and specialist actions have equal prominence;
- whether the required context is visible before commit; and
- source, tests, screenshots, user reports, and current PR overlap.
Exposure uses descriptions such as "every mnemonic load" or "settings users only." No usage percentages are claimed.
Evidence used¶
- Current Krux source for Login, Settings, menu rendering, touch handling, and mnemonic loading.
- Focused tests for 12-word, 24-word, and double-mnemonic wallet loading.
- The existing TZT, M5StickV, and Amigo simulator screenshot set.
- M5StickV input counts using the forward and previous buttons.
- Issue and PR discussions where they changed the interpretation of a finding.
Findings¶
| ID | Finding | Exposure | Severity | Evidence boundary |
|---|---|---|---|---|
| N1 | Some touch targets clear 24 px but remain below the 44 px enhanced target; no project guardrail exists | Touch users on affected screens | Medium guardrail | Source and screenshots; no user study |
| N2 | A Home Settings shortcut fits but adds permanent attention for specialist tasks | Every Home visit if added | Low-medium | PR #894 review; shortcut not shipped |
| N3 | The shared wallet-summary actions are unclear after mnemonic creation | Every new or loaded wallet | Medium | Current source, screenshots, and focused tests |
| N4 | Generic exit prompts do not always explain what will be discarded | Users exiting affected flows | Low-medium | Source review; overlaps PR #806 |
| N5 | Load Mnemonic starts with input method rather than the backup the user has | Every mnemonic load | Medium | Current source, screenshots, and input counts |
| N6 | Numeric-setting editors omit unit and range before commit | Settings users only | Medium | Current settings data and number-entry flow |
N1: touch-target guardrail¶
The checked targets clear the 24 px WCAG minimum but some remain below the 44 px enhanced target. That does not prove a current task failure. It does show that Krux has no project-level minimum to catch future regressions across its different screen sizes and input methods.
This remains a measurement and review concern. PRs #771 and #797 overlap menu and touch behaviour.
N2: screen fit is not enough¶
PR #894 tested a Home Settings shortcut for Printer and Encryption. Both settings were already available before wallet loading. The extra Home row therefore helped a narrower post-wallet case while adding attention cost to every Home visit.
The finding is not that Settings can never appear on Home. It is that a row should not be justified only because it fits. Frequency, existing access, and the cost imposed on the common path also matter.
N3: wallet-summary handoff¶
Krux does not return to Login after mnemonic creation and does not ask the user
to enter the new mnemonic again. Login._load_key_from_words() proceeds from
mnemonic review to the wallet summary. Focused 12-word, 24-word, and
double-mnemonic tests confirm that transition.
The issue is the handoff. Krux then shows Load Wallet, Passphrase, and
Customize at the same level. The summary already contains useful context:
fingerprint, network, policy, derivation, and passphrase state. Load Wallet,
however, can sound like repeating the task just completed, while the optional
branches receive the same prominence as the normal continuation.
This correction comes from current source and tests rather than relying on the original description in issue #829.
N4: exit context¶
Some flows use a generic exit confirmation even when the important question is what state will be discarded. This is a clarity issue rather than a missing Back path. PR #806 already claims this area, so the audit records the overlap instead of treating it as unclaimed work.
N5: mnemonic loading starts with the input method¶
The first Load Mnemonic choice is how data reaches the device. The next menu
then asks what the backup is.
| Current branch | Choices |
|---|---|
| Load Mnemonic | Via Camera, Via Manual Input, From Storage, Back |
| Via Camera | QR Code, Tinyseed, OneKey KeyTag, Binary Grid, Back |
| Via Manual Input | Words, Word Numbers, Tinyseed Bits, Stackbit 1248, Back |
| Word Numbers | Decimal, Hexadecimal, Octal, Back |
A person arriving with words or a QR code must translate that familiar backup into Krux's camera/manual grouping. This is an information architecture finding. The audit does not claim that another grouping is more discoverable without user testing.
Current M5StickV inputs from the first row of Load Mnemonic to launching each
handler are:
| Backup | Inputs |
|---|---|
| QR Code | 2 |
| Words | 3 |
| From Storage | 3 |
| Tinyseed camera | 3 |
| Tinyseed Bits | 5 |
| OneKey KeyTag | 4 |
| Binary Grid | 4 |
| Word Numbers | 4 |
| Stackbit 1248 | 5 |
PRs #771, #839, and #862 overlap the menu or specialist formats.
N6: numeric settings hide context until an error¶
NumberSetting stores the allowed range, but the number-entry screen receives
only the label and current value. The range appears after an invalid commit and
the unit is not shown in the editor.
| Setting | Current default and range | Missing unit |
|---|---|---|
| Screensaver Time | 5; allowed 0-30 | minutes |
| Shutdown Time | 10; allowed 0-60 | minutes |
| Buttons Debounce | 50 on M5StickV, 80 elsewhere; allowed 20-500 | milliseconds |
This creates a preventable information gap. A user can be asked for a number without knowing what it measures or which values are accepted.
Audit conclusions¶
- Menu depth and screen fit are not enough to judge whether a choice belongs.
- N3 is the strongest current label and prominence concern.
- N5 records a mismatch between Krux's categories and the backup a user has.
- N6 records missing information at the point of entry.
- N1 remains a useful guardrail question, but the checked screens do not prove a current task failure.
- N2 shows why review evidence can justify stopping a technically valid patch.
Evidence boundary¶
The screenshots on this site show current Krux behaviour. The audit does not claim user testing, firmware changes, or device validation for an altered flow. It records what the current interface does, where the clarity risks are, and which findings overlap work already in progress.