Service cards surface functions at the desktop layer
Aliases: service card · minus-one screen · desktop card · HarmonyOS card
What it is
HarmonyOS service cards, and the home-screen cards and minus-one screen on Xiaomi, Huawei, OPPO, and vivo, move a function from “open the icon, then find it” to “visible on the desktop layer, often completable in one tap.” Weather, trips, parcels, payment codes, and commute times live in the launcher; they do not have to enter the app’s navigation stack. A card is a live slice the app hands over: the launcher owns layout and refresh, the app owns data and a small set of actions. Users treat the desktop and the minus-one screen as the first layer of the service; the icon becomes a deeper door.
This is how information architecture and interaction depth change once a function is promoted onto the system desktop—not the generic limit that lock-screen widgets are glance-only, and not how one codebase picks layouts by capability. The typical failure is a full home screen shrunk into an unreadable poster whose tap cold-starts the splash page.
Why it happens
The launcher owns layout and refresh cadence on the desktop; the app does not. A card must finish “current state plus one or two actions” in a tiny area, because other apps’ cards live beside it and the user will not stop for a tour. If the action can complete on the card (show a code, check in, next stop), the task need not enter the app. If the action can only send the person into a page, the card is a deep link, and that page must continue the same context rather than dump them on home to search again.
Refresh is scheduled by the system, not by a timer the card owns. Too frequent, and the launcher throttles it; too rare, and the desktop shows a stale state. People decide from what the desktop shows (leave now or not, already paid or not); stale is more dangerous than blank. Privacy moves forward with the card: the desktop and minus-one screen are visible before the app is unlocked, and to anyone walking by. Content on the card is a public glance by default. One-time codes, itemized amounts, and private addresses do not belong on a desktop layer that needs no further authorization.
Where it stops holding
In markets with no desktop-card ecosystem this is not the primary door; design the in-app home. Games, long video, and professional editors cannot finish in a glance; the card can offer “resume” or status, and should not pretend the tool fits on the desktop. The minus-one screen is each vendor’s launcher product; capabilities (swipe, location) differ, so one card must not be assumed to behave the same everywhere. Users can disable cards or never open the minus-one screen. The in-app path must still complete on its own; the card is an accelerator, not the only door.
Applying it
- Design a glance state and one or two completable actions for the desktop layer; do not shrink the home screen. If a tap enters the app, it must land on the page that matches the card’s state.
- Refresh decision-critical fields on the cadence the launcher allows. When data is stale, show it as stale; do not keep presenting it as current.
- Choose card fields as if a bystander can see them: one-time codes, precise location, and full account numbers stay off the desktop.
- Verify by completing the main task from the card and the minus-one screen, never tapping the app icon: is the state enough, can the action finish, or does the deep link land correctly? Then, with the screen on and the app closed, ask a bystander to glance at the card and list fields that should not have been visible. Finally disable the card and confirm the in-app path still completes the same task.
Related
- Same group: R4.04.1 Distributed continuation across devices · R4.04.2 Constraints of mini-programs inside super-apps · R4.04.3 Points of divergence from international platform conventions · R4.04.4 Multi-end deployment requires layout by capability, not screen name · R4.04.6 System-owned identity and payment change flow boundaries
- Adjacent: K1.06 Widgets and lock-screen entry · K1.05 Status bar and Notification Center
- Search terms:
service card·minus-one screen·launcher widget·glanceable
Cards in the same group
- R4.04.1Distributed continuation across devices
- R4.04.2Constraints of mini-programs inside super-apps
- R4.04.3Points of divergence from international platform conventions
- R4.04.4Multi-end deployment requires layout by capability, not screen name
- R4.04.6System-owned identity and payment change flow boundaries