[Usability] Reducement of confirmation pages / Allow undo

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The next feature release of phpBB 3 will be 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.2.x. If you need support for phpBB 3.2.x please visit the 3.2.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Desdenova
Registered User
Posts: 13
Joined: Wed Jul 22, 2009 6:45 pm

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by 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).

User avatar
imkingdavid
Registered User
Posts: 1050
Joined: Thu Jul 30, 2009 12:06 pm

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by 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. :D
I do custom MODs. PM for a quote!
View My: MODs | Portfolio
Please do NOT contact for support via PM or email.
Remember, the enemy's gate is down.

bobtheman
Registered User
Posts: 63
Joined: Sat Dec 19, 2009 4:00 pm

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by bobtheman »

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

User avatar
onehundredandtwo
Registered User
Posts: 33
Joined: Mon Feb 02, 2009 6:55 am

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by onehundredandtwo »

imkingdavid wrote: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. :D
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.
Need help preventing spam? Read Preventing spam in phpBB 3.0.6 and above

User avatar
ameeck
Registered User
Posts: 86
Joined: Sun Nov 13, 2005 6:43 pm
Location: Prague, Czech Republic
Contact:

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by 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.
bobtheman wrote: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.
Please think before you post.

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by 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.

User avatar
Dog Cow
Registered User
Posts: 271
Joined: Wed May 25, 2005 2:14 pm

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by Dog Cow »

SyntaxError90 wrote: 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
Registered User
Posts: 57
Joined: Mon Jan 23, 2006 3:38 am

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by 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.

User avatar
Eelke
Registered User
Posts: 606
Joined: Thu Dec 20, 2001 8:00 am
Location: Bussum, NL
Contact:

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by 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
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: [Usability] Reducement of confirmation pages / Allow undo

Post by 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.

Post Reply