I think the worklist distinction is important here. On a paper list,
the user will strike through the completed task, rendering it visually
different but often still visible/readable.
You could do something similar to signify state change, or move the
"worked on" items to a different labeled area of the screen. This makes
sense for tasks, but not for search results whose state in context is
not going to change.
[Please voluntarily trim replies to include only relevant quoted
In our desktop application, which is essentially a document
management/pubishing system, we have a powerful, multi-purpose search
function. After retrieving a list of hits, users can perform any number
of actions on the result rows. For instance, they can look for
unassigned items and assign them (to users).
The question is, "Should the results list automatically remove rows that
are disqualified each time the user performs an action?" For instance,
if you find 10 unassigned items and assign one, should the results
remove that one... without the user explicitly re-executing the search?
There are reports of users being confused because the results do not
currently auto-update, and in fact, I can recall experiencing this
perception myself. I believe there's a split between "search" and
"worklist" that's at play here.
Note a subtlety: There's no issue about automatically "re-invoking the
search." We won't consider that; it would be disruptive. I only want to
know, should I recommend that we automatically remove disqualified rows?
Are there models out there for searches that auto-update? Or should I
just accept that if it supports "worklist" functions, it should meet the
expectation of updating, like a worklist?