Skip to content

Week 03 - Jun 1-7, 2026

Focus: Layout consistency audit, navigation kickoff, and a rethink of how I pick what to contribute

What I did

  • Finished the layout consistency audit. Six findings, none critical or high. Two medium, four low.
  • Started the navigation audit: depth map of five core flows, touch target math, and a triage of the open issues in my scope.
  • Checked the live GitHub state for everything before committing to a contribution target. This changed my plan.
  • Settled on a clearer rule for choosing contributions: start from a finding, not from an issue.

What I found

Layout is in good shape, which honestly surprised me a little. The reserved-region system (status bar at top, prompt area at bottom) is well defined and respected. I didn't find anything overlapping or clipping on the flows I captured.

What I did find is consistency debt. The same job gets done different ways in different places. A few examples:

  • One screen positions a progress bar with a hardcoded per-device pixel table instead of deriving it from the screen height like everything else does.
  • There's a helper for vertical centering, get_center_offset_y(). It's used in 3 places. Meanwhile there are 34 spots doing the centering math by hand.
  • Menus on touch devices and button devices use two completely separate layout algorithms with different spacing logic. The same menu doesn't measure the same across device types.

None of these break anything today. They're the kind of thing that produces drift later, especially when a new device gets added.

I also chased down a suspected bug in the Stackbit backup screens, where the import and export views use different spacing. Turned out to be intentional: the entry screen uses taller cells on purpose, to make a bigger touch target. So, not a bug. Worth confirming before flagging it.

Things I noticed

  • Two of the issues I had listed as in scope are actually open pull requests from a maintainer, not open issues. So they aren't mine to build. At most I can review and test them on hardware.
  • More than that, the maintainer has a whole cluster of UI work in flight right now: menu visuals, touch handling, screensaver behavior. That's the exact area I'm auditing. I need to be careful not to propose things that are already being built.
  • The contrast work from last week is the opposite situation. Nothing open touches theme palette contrast. It's the most rigorous result I have, it maps cleanly to specific WCAG numbers, and nobody else is working on it.
  • I caught myself doing something backwards. My first instinct was to pick the easiest issue to ship and then justify it with the audit. That's the wrong order for an audit project. The contribution should come out of a finding and point back to it. I reworked my plan around that. The honest version of this week is that the most useful thing I produced was a correction, not code.

Next week

  • Finish the navigation audit: trace all five flows in the simulator, confirm the depths and item counts, measure menu regions with many items, and pin down the smallest touch target that actually appears.
  • Draft an issue for the contrast failures, citing the ratio table. That issue is what opens the contribution.
  • Sort out the back/escape coverage across non-root screens.