Interaction is tightly capped by the system
Aliases: app widget · widget tap target · deep-link launch · interactive widget
What it is
A widget looks like a miniature interface; the system will not let it become a miniature app. Tappable pieces are typically a few buttons or one whole hit region, and a tap usually opens a page inside the app. Scrolling, typing, and arbitrary drags are absent or cut down to a whitelist. A to-do checkbox may complete one item; “add” on the same block can only enter the app; a quotes block cannot place an order on the home screen. This entry is only about the capability ceiling. It is not about whether a glance can read the number, and not about whether a bystander can see the content on the lock screen.
Why it happens
Widgets run inside the launcher or SpringBoard process, not in the app’s own foreground session. The host limits the view tree, the refresh budget, and which actions may be registered—for battery, stability, and safety. Otherwise every app could plant a permanently input-capable surface on the home screen. Artboards full of fields, pagers, and gesture stacks collapse on device into “the whole block is tappable → opens the app.” Whitelists differ by system and version—some allow buttons and list scrolling, some long allowed only a deep link—but the ceiling logic is the same: an interaction not explicitly allowed does not exist. People try what they see; when the try fails, blame looks like the product’s, while the host swallowed the event. Writing a widget as “do the whole task on the home screen” promises capability the host will not grant.
Studying it
Audit actions: list every element that looks tappable, try each without opening the app, and record what the host allows (toggle, refresh, deep link) versus ignored taps. Compare capability tables across OS versions.
Independent variables: control kind, system and version, whether the widget is declared interactive, whether the action needs text input. Dependent variables: steps completable without a launch, empty-tap count, regions mistaken as editable, whether the task still enters the app.
Telling lab participants “this is a widget, many taps will fail” suppresses empty taps. Closer to use: give the task without explaining the cap. Do not substitute in-app completion for on-widget completion. Cloud screenshots can hit pixels; they cannot feel “tapped, nothing happened.” On-device tap logs are more useful.
Where it stops holding
Android collection widgets historically allowed list scrolling and multiple buttons, a higher ceiling than early iOS, but that does not extrapolate to “Android can host a full app.” Later interactive widgets still forbid arbitrary views and continuous gestures. A smart stack rotates several blocks; interaction first has to land on the one currently visible. Watch complications cap even lower; phone-widget buttons do not move there. A developer’s own desktop program is not a system widget and is not under this host.
Applying it
- List actions against the host whitelist: what can finish in the widget becomes a button; anything that needs a form, search, or multiple steps is only an entry that opens the matching page, visually distinct.
- Do not draw fields, sliders, or handles that look draggable unless that system version will actually respond.
- Do not fail silently: if a tap can only open the app, the landing should honour that action rather than dumping on home.
- Verify by walking, without entering the app, every step marketing describes as “doable from the home screen,” on the target OS. Write the actual result of each step (completed / ignored / opened the app). Any step sold as desktop-complete that still requires a launch is a ceiling drawn as a full UI.