L6.10.4item-level versus global resetdesignresearch

Deleting one record and resetting everything solve different problems and both must exist

Aliases: surgical versus nuclear · per-record delete · class-level clear

What it is

A child mis-tapped one title, a gift was bought once, a film should not be continued — the need is to take that one row out of the profile. Taste changed, a move, a shared account to split — the need is a global reset. Item-level versus global reset means the two repairs aim at different error units. Offering only one forces people to use the wrong tool — either collateral damage to everything, or helplessness against a frozen class.

Seeing is the prerequisite; cost has to be disclosed. What is nailed here is grain: the size of the object must be choosable.

Why it happens

Error units come in sizes. A global reset for a single noisy point is pulling every tooth for one. “Don’t like this row” for a frozen class lets the class grow back from neighbours. When tool and unit mismatch, users are not “bad at the product”; they lack the matching verb. A product that only offers the red button prices every local problem as cold start; one that only offers per-row delete makes a class-level problem take dozens of deletes, and people quit.

Per-row delete must also hit the feature, not only the visible history of that line. Deleting a play record without taking it out of counts and neighbours lets it return next time as “similar.” A global reset must walk the profile’s layers: ticks, counts, inferences — whether they clear together should be choosable, not one key wiping three layers.

Studying it

Two kinds of error: one mis-tap, one frozen class. Four tool combinations: global only, per-row only, both, both and per-row hits the feature. Dependent variables: task completion, collateral damage, steps to finish, abandonment. Independent variables: whether delete also updates counts, whether global is layered.

Do not take “reset was used N times” as health. A high count may be forced by a missing per-row tool. Cut completion by error unit.

Where it stops holding

Safety blocks and legally required deletion have their own grain and must not be overwritten by preference tools. When an item is already taken down, the object of per-row delete becomes “residue of this class,” and the tool should upgrade to class-level rather than deleting a 404. This entry chooses grain. It does not treat whether the post-off default is an arrangement, and it does not treat contextual inference.

Applying it

  • On the profile page, each record is deletable, each class has “stop using this for ranking,” and the footer offers a layered global reset. All three verbs present; none impersonates another.
  • The per-row confirm states whether it will disappear from counts and neighbours; the global confirm lets people tick which layers to clear.
  • Check: a mis-tap should clear in three steps with other classes unmoved; a frozen class should not require deleting every row under it. If only one of those is possible, a grain is still missing.

Related

  • Same group: L6.10.1 Being able to see the profile is a prerequisite of being able to reset it · L6.10.2 Reset has to say what will be lost, or users will not touch it · L6.10.3 The default ranking after personalization is off is still an editorial choice and must be intelligible · L6.10.5 Still inferring from the current context after personalization is off is undeclared personalization
  • Nearby: L6.09 Feedback Loops and Preference Entrenchment · L6.13 Negative Feedback Channels for Recommendations · L6.05 Turning Personalization Off
  • Search terms: item-level versus global reset · surgical reset · feature-level delete

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L6.10.4