Flutter NumberPicker
ArchivedJune 1, 2019
A fork of MarcinusX's Flutter NumberPicker — a scroll-wheel number selector that feels more elegant than a text field or stepper. The reason for the fork is lost, but the component points to a deeper question: when does making an input feel satisfying cross the line into making it addictive? A meditation on the black mirror in our pockets.
Purpose
Forked the NumberPicker because the scroll-wheel interaction pattern is a more elegant way to choose numbers than tapping plus/minus buttons or typing into a field. The physicality of the scroll — the momentum, the snap, the haptic detent — makes a mundane input feel good. That "feel good" is the starting point of a much larger conversation.
Stack
What I Learned
- A scroll-wheel number picker is technically simple — a ListWheelScrollView in Flutter with snapping physics — but the feel is everything. The difference between a good picker and a great one is in the deceleration curve, the snap tension, and whether haptic feedback fires at the right moment. Users cannot articulate why one feels better than the other, but they can feel it instantly.
- Input design is UX at its most fundamental. Every time you ask a user for a number, you are making a design decision: text field (flexible, error-prone), stepper buttons (safe, tedious), slider (visual, imprecise), or scroll wheel (physical, satisfying). The right choice depends on the range, the precision required, and how often the user will interact with it.
- The scroll-wheel interaction is a skeuomorph — it mimics a physical dial or slot machine reel. Skeuomorphism fell out of fashion in visual design (flat design won), but it persists in interaction design because physical metaphors give the brain something to hold onto. The scroll wheel works because your thumb already knows how wheels work.
- Forking a package to explore a UI pattern — even if you never ship the fix — is a valid way to learn. Reading MarcinusX's implementation taught scroll physics, custom painters, and gesture handling in ways that documentation alone never could.
Key Insights
- The phone in your pocket is the black mirror — a rectangle of glass that reflects whatever the designer wants you to see and feel. Every interaction pattern on that screen was chosen. The scroll wheel feels satisfying because someone decided it should. The pull-to-refresh bounce feels rewarding because someone tuned the spring constant. Nothing on your phone feels the way it feels by accident. Every micro-interaction is a design decision made by someone who understood what your nervous system responds to.
- The slot machine teaches the most important lesson in addictive design: more wins does not create more engagement. It is losing frequently with the intermittent chance of winning that creates addiction. This is called a variable ratio reinforcement schedule, and it is the most potent behavioral conditioning pattern known to psychology. Slot machines use it. Loot boxes use it. Social media feeds use it — most posts are mid, but occasionally one goes viral, and that unpredictable reward keeps you pulling the lever.
- The uncomfortable truth for UI designers: making something feel satisfying and making something feel addictive use the same toolkit. The scroll-wheel snap that makes a number picker feel premium uses the same haptic, momentum, and reward principles that make a slot machine feel compelling. The difference is intent and context. A number picker in a workout timer is a tool. A number picker in a gambling app is a weapon. The component is identical. The ethics are not.
- This is worth sitting with as a builder. Every time you tune an animation curve, add a haptic pulse, or design a variable reward — you are making a choice about what kind of relationship your product has with the user's nervous system. The Potatuhs brand leans playful, not predatory. That distinction has to be intentional, because the default trajectory of optimizing for engagement leads somewhere dark. Build things that respect the person holding the black mirror.
This post was composed through a conversation between Brett Owers and Claude Code (Anthropic). The content reflects Brett's recollection of each project and the lessons drawn from it. Some details may be approximate or omitted — the purpose is to paint an honest picture of a software engineer's development over time, not to serve as a precise historical record.