Question: Rather than show a confirmation dialogue when someone wants to archive a project (each row in the animation is a 'project'), I've decided to immediately archive, with the option to undo.

My question is, should this row disappear after a certain time? Or should it persist until the user visits another screen?

[![Archiving a row](https://i.stack.imgur.com/gxZEf.gif)](https://i.stack.imgur.com/gxZEf.gif)

Answer: 
I think that choosing when to remove a deleted item from view depends heavily on four things:

* **Impactfulness** - Is the impact of the action high or low - are the consequences significant or trivial?
* **Immediacy** - if it's *impactful*, is a user likely to *realise* they've made a mistake in taking this action straight away, or later on, when they've navigated away?
* **Frequency** - Is it likely that the user will be moving down the screen clicking delete on many, many rows or just picking one out to remove?
* **Next Intent** - What will the user be doing once they've deleted the row, and will the presence of residual content be in the way?

How do those affect things?
---------------------------

If it's *impactful*, then the residual undo message you suggest is helpful. But if they are going to be deleting many rows then multiple undo messages are likely to be unhelpful and intrusive. Especially if the *next intent* required the screen space that they expected deleting rows to provide.

If it's *not impactful*, then the residual undo message is just a requirement for an extra click before they can get their screen space back and get more rows they *do* care about back into view.

If it's *immediate*, then the residual undo message is helpful for a short time, and then just intrusive. In that situation, it could probably be displayed briefly (as a confirmation of the user's action) and then deleted. I'd suggest a very brief CSS animation (I'd go with .3 seconds as an upper limit) to shrink the height of the row to nothing and then remove it, rather than just deleting it - this allows the user to more easily track what's happening in the change and not lose their position with a sudden jump.

If it's a frequent action, and they'll be deleting (for example) 50 rows out of 80, then they probably don't want 50 residual undo messages - especially if they can't tell them apart. In that situation, they almost certainly want them to just go away - all at once and quite possibly without making subsequent items on the screen move around in unexpected or hard-to-follow ways. If mass actions like this are likely then you might want to consider a different way to handle them than per-row actions.

If their *next intent* is to move to the next item in the list and do something with that, then changing positions on the screen is likely to annoy... but if their *next intent* is to do a different task then it's not an issue.

Summing up
----------

So, all in all - you have quite a lot of different options for how to move forward, many of which depend on the balance of those four factors.

Ultimately, to get a good answer to this question, you'd need to spend a reasonable amount of time working out the balance that's appropriate for the work you are doing.

If you want a course of action that will help you find that balance, I'd suggest using some clickable mockups (or some other easily-disposable prototype) and running some user tests and/or interviews to find that balance rather than guessing or assuming.
Based on the following :

* **Consistency**. Keep the message always in the same possition. Also, this kind of modelles feedback is usually located on the top (see gmail).
* **Relevancy**. The message should be visible only for as long it is relevant, otherwise it is noise to the user. It will not be relevant when the user switches to another task.

I recommend :

Display the message always on the top of the block. Hide the message after 20 seconds or when the user performs another action (change screen, select another item etc).