[Usability] Reducement of confirmation pages / Allow undo

[Desdenova]

Well, that's for anything that you use a POST form for, but it does not cover things like the delete post button's link, which the submission is just sent via GET (which is why the confirmation page exists).

[imkingdavid]

On the topic of deletion, how about implementing a soft delete type feature. In other words, posts don't get deleted from the database but they are removed from view except of mods and admins? Or maybe a Trash Bin forum where deleted posts are automatically moved.

Also, I'm not sure if this qualifies as a confirmation page, exactly, but it is annoying in a similar fashion: login success pages. Quite honestly, I don't care to be told when I've logged in successfully, I just want to be logged in. I'm not interested in having an extra layer of notification. Just skip the redirect and let me in.

[bobtheman]

ajax jquery should help reduce these also ... improvements to ucp acp mcp ... etc etc

[onehundredandtwo]

On the topic of deletion, how about implementing a soft delete type feature. In other words, posts don't get deleted from the database but they are removed from view except of mods and admins? Or maybe a Trash Bin forum where deleted posts are automatically moved.

Also, I'm not sure if this qualifies as a confirmation page, exactly, but it is annoying in a similar fashion: login success pages. Quite honestly, I don't care to be told when I've logged in successfully, I just want to be logged in. I'm not interested in having an extra layer of notification. Just skip the redirect and let me in.

Why would the moderators or admins need to see deleted posts? What if they deleted them?
If posts were marked as deleted in the database, and then added to the cron job to delete (although that might add too much to the cron job), I could see a possible solution for deleting posts.

[ameeck]

The easiest implementation is simply through a status column in the database. The implementation is not a problem.

As for GET requests, there are ways to make them safe as well. First line of checks are referrer checks, hashes/keys can also be used. phpBB3 already has in-built functions for this.

I wouldn't like to go through Soft Delete / Trash can features. You should use Move topics/message/whatever for that. Using undo should be possible just on the immediate next page of the request.

ajax jquery should help reduce these also ... improvements to ucp acp mcp ... etc etc

Please, comment on the topic with concrete statements. This is a constructive discussion, not an overview of how many cool web technologies you know.

[code reader]

this is Off-Topic, because this topic is about usability, confirmations and undo, not about "how to implement soft delete", but since this seem to have crept in anyway, just a small comment about soft delete:

we already have a "status " field in the post record, which can very easily be modified to support soft delete and probably some more features.
this field is currently called "post_approved".
this field should be converted to a slightly more generic form of "post_status", but the neat thing is that all the places in the code that display a post *already* ask about the status (except, of course, they formulate the question incorrectly for the more generic use...)

extending the "post_approved" to a more generic bit-mask that support other status such as (softly) "deleted" should be a relatively trivial task.

again, this is not too related to the topic of this thread, which is usability, confirmation and undo.

peace.

[Dog Cow]

it would probably be better if you simply set a 'status' column to on-queue-to-delete or something of that nature, meaning the data is not gone, but is in limbo before it leaves the undo history and a garbage collection action is taken and it is purged from the database. It is much easier said than done programatically, but it isn't impossible.

Agreed. One would only need to delete anything if one is running low on disk space.

[jwxie]

If you need to do undo history, a good way to purge old revisions is to set expiration.
Whether it is done by the scripts or by users, they generate heavy load to the server anyway, because you might have 100+ revisions just in 10 minutes.

[Eelke]

One possible way would be for undo-items to be tied to sessions. If the session is no longer valid, there will be no need for the undo anymore (at least not if it's purely limited to "immediate" undo, i.e. you took an action, you are notified it was carried out, and you regret it immediately). In case of deleting, it makes sense to tie the undo functionality to soft delete functionality, but remember there are more areas where this principle would apply (editing, moving, banning users, etc. etc.). Basically, anywhere you might traditionally ask "Are you sure?", you would now say "Done. Undo?"

[code reader]

one meaningful distinction you may want to make is among *user actions*, *moderator actions* and *admin actions*.
user actions are pretty limited: user can edit their profile, post, edit their post and delete their post.
(phpbb also has a small perversion, in that it gives the user one-way lock, where they can lock threads they started but not unlock it. but adding an "undo" here is no more than fixing what many, including myself, consider to be a simple bug, i.e. allowing the user to unlock a topic she locked).

for any user-driven post-related activity, we already have significant part of the machinery we need for "undo": the machinery that lets you save a draft can be converted to a "post versioning system" (think wikipedia articles).

being able to undo profile changes is a bit more interesting problem.
all these do not necessarily have to be "session mapped", they can be "user mapped".
it is true that the same user might have more than one active session at a time (e.g. using two browsers), but it is conceivable that the ability to do something in one session and undo it in another might be considered a plus, or at least acceptable, if it turns out that mapping the "undo" to user is easier than to session.
it also might be desirable to be able to undo an action from previous session.
the "user undo stack" might be purged periodically, either as a manual or automatic action, although *some* actions may become "undoable" after some events, e.g., once there is a reply, you might not be able to "undo" a posting.


next, we have the moderator actions.
those, IMO, are much less performance-sensitive because even on the busiest forums i do not think that *that much* moderation action happens simultaneously.
or rather, the ratio of moderator actions to user actions is fairly small.
so the problem of implementing "undo" for moderator actions has a slightly different emphasis: here we care about integrity and completeness, but less about performance.
here, too, we can tie the "undo stack" to a specific user (the moderator in this case).

and lastly, we have the admin.
here, it is arguable that the possibility of having two simultaneous admin sessions should even be considered a bug, so maybe the right thing is to lock the ability to have more than one active admin session, and then have a single "admin" undo stack.


peace.