You want someone to start a demo, mute a sound or change a light without opening an app. A flat touch surface would look tidy. A physical button would give them something to feel. Which belongs in the first prototype?
Start with the action the person needs to understand. Can they find the control, tell that it registered and predict what happens when they release it? On our bench we set up two GraftSense input modules, a mechanical push button and a TTP223-TD capacitive touch button, each on a GraftPort-Pico controller running MicroPython. Both read an input and print its state; neither yet proves that a finished product is easy to operate.
A press and a touch can mean different things
A mechanical button has movement. A capacitive touch pad detects a change at its sensing surface. For a desk object or exhibit, the choice affects the enclosure as well as the electronics: the mechanical part needs accessible travel, while the touch surface needs to work through the actual material placed over it.
Neither needs to dictate the product behavior. A momentary control changes state while it is operated. A toggle changes to a new state and stays there until the next operation. Decide whether the intended action is "hold to play," "start once" or "switch on and off" before choosing the input configuration.
An older model-railway panel discussion shows why this deserves an early mock-up. A builder mounting touch modules behind acrylic first reported unwanted triggering, then reported success after fixing the sensor to the panel before powering it. That is one builder's result with their assembly, not a thickness guarantee for another module. It is a good reason to test the assembled surface rather than a bare board.
The mechanical-button test
The mechanical module uses a TS665WS switch. Its circuit pulls the signal high when released and brings it low when pressed. We connected it to the controller's DIO0 connector, whose signal is GPIO6. One of our earlier code listings used GPIO15 instead; check the pin in your own program against the wiring before concluding that a button is dead.
The test used a debounced input class from our team's driver library. On an input edge it waits a settling interval, reads the pin again and calls a press or release callback. A state function reports whether the last accepted state differs from the configured idle state. The main loop printed that state every half-second, with a 50 ms settling interval and the idle level set high.
The recorded output showed press and release messages between the periodic state reports, so a short press can produce callbacks between two "Released" lines. The half-second print interval is not the input-detection interval.
The 50 ms settling interval is a setting for this demonstration, not a measured requirement for every button. The switch manufacturer supplies ratings; we did not capture a contact-bounce waveform or run a user-response test from which to tune that setting.
Configure the touch module to match the action
The TTP223-TD board has two configuration points, STG and SLH. Together they select momentary or toggle operation and the output polarity.
In momentary mode with STG=0 and SLH=0, the chip reference describes idle LOW and touched HIGH. With STG=0 and SLH=1, those levels are reversed. Toggle mode keeps the output state between touches, so reading it as "finger currently on the pad" would be misleading.
Our touch test reused the same input class with the idle level set high. That matches the active-low momentary configuration, not the chip's active-high default. For the active-high momentary configuration, the matching software setting is an idle level of low; verify the fitted pads and the actual signal first. This is a configuration reading, not a result we have rerun.
The TDSEMIC reference limits continuous touch duration to six seconds. A product that must recognize an indefinitely held finger needs further evaluation; a short tap demonstration does not establish that behavior. The chip's output level also follows its supply, so check it against the controller's input limits rather than relying on matching connectors.
The module's status LED lit when touched. That confirms something about the module's output; it does not confirm that a downstream light, sound or network command has completed. Give the user feedback tied to the actual action when that distinction matters.
One caution on our records: both tests share a single terminal capture. The physical demonstrations were recorded separately, but the terminal output should not be counted as two independent results, and it cannot show which touch mode was fitted.
Keep input handling separate from the work it starts
The driver we used creates a one-shot timer when an input edge occurs, and the timer callback reads the settled pin and calls the application callback directly. That is fine for printing a message. Avoid putting a long animation, network request or sound routine directly into that callback when expanding the prototype.
MicroPython's timer documentation describes callback constraints and differences between ports. A sensible next implementation records the requested action and lets the normal application loop perform the work. That change needs testing on the actual firmware; our terminal demonstration does not validate a larger application.
Test the surface the user will touch
For the mechanical option, make sure the enclosure does not hold the button partly pressed or prevent its return. A switch drawing describes the component, not a finished enclosure; leave room for the board and connector as well as the button.
For the touch option, build a sample with the intended cover material and mounting method. Try it after power-up, with nearby electronics operating and while handling the enclosure. In a 2020 Arduino discussion, a builder reported that a lighting setup behaved differently with its output hardware connected. That unresolved report is a reason to include the load in a system test, not a diagnosis of every touch problem.
Then ask someone to perform the intended action without coaching. Watch whether they can find the control, whether one operation produces one action and whether the feedback makes sense. Try a quick tap, a held press and an accidental brush across the surface. We have not run these product checks yet; they are the next milestone after a working bench input.