Undelete
Firas Durri
trash/undelete system, triggered by a discussion on its implementation
but now mainly about its use/behavior. Which is probably something we
should figure out before we worry about implementation :)
First, why undelete?
My take: undelete is just a form of 'undo'. To the extent that its
reasonable, software should support undo to the extent it can. Don't
ask "do you really want to do this?" if you can avoid that. Let them
do it, let them change their mind. That's how human beings operate.
Current arguments are mainly about--when do we "really" delete?
--> Time based (after 30 days, eg. Gmail)
--> Item # based (after X deleted comments/posts, the overflow gets trashed)
---> Manual (purge only on user prompting, eg. Windows recycle bin)
--> Hybird/Options based (eg. default to time based, but allow deleted
items to remain deleted until a manual purge like the windows recycle
bin.)
Issues:
* We really don't want this to become a 'get this item out of my way
for now and I'll deal with it later' solution--it's not a draft
storage/archival system. It's a way to undo mistakes, like you deleted
a comment but decided that you don't mind it so much.
There are a lot of other issues being discussed, so here's a root
thread for us to start mulling this. Your 2c?
--
Firas Durri | http://firasd.org
Trevor Turk
> Current arguments are mainly about--when do we "really" delete?
> --> Time based (after 30 days, eg. Gmail)
> --> Item # based (after X deleted comments/posts, the overflow gets trashed)
> ---> Manual (purge only on user prompting, eg. Windows recycle bin)
> --> Hybird/Options based (eg. default to time based, but allow deleted
> items to remain deleted until a manual purge like the windows recycle
> bin.)
If we're just talking about database size, I think manually deleting
would be plenty. An Empty Trash link with a nice little garbage can
might be nice :) If there's going to be built in spam blocking stuff,
then I think there should be a 30 day running timer, a la spam folder
in email.
Michael Heilemann
Michael Heilemann
http://binarybonsai.com
Firas Durri
> Would it be interesting to do an undo stack which could be used by plugins
> as well? So say you have a plugin which has a range of options. Each time
> you change an option, it could write its previous settings to the undo
> stack, keeping perhaps the last 30 settings or whatever, and it would then
> be much safer to play around with settings?
Michael,
A point I was trying to get across--and your intriguing phrasing of
the concept gives me reason to advocate it again--is the usefulness of
a 'stack' based system rather than one in which, eg,
a) We add a deleted column to the db tables for everything that we
think might be deleted (posts, comments) and then put in a
when-deleted timestamp. This would be a very brittle undo system
specifically geared towards undeleting posts and comments,
On the other hand,
b) If changes are 'logged' to a dump, where we can just take a
specific item and revert it, undo can be almost pervasive.
Here's why it's easy: almost every change in habari will be something
to do with a database entry.
All we need to export to the dump is the reverse of the query we just
did. So, if we deleted a post, we first export that post to the dump.
Need to recover the post? No problemo--grab that chunk of sql from the
dump and run it. When a plugin's option is updated, log the function
call that'll revert that change--if that's to be undone, just exec()
that php. I know there are a lot of pitfalls we can spot in the last
couple sentences about how to implement this, but it'd be so awesome
if it can be done.
This is a lovely sort of notion because it's well within the art of
the possible, but I don't think *any* CMS software does this very
pervasive undo mechanism yet.
Jay Pipes
The schema I had initially proposed last week had a revision control
system built in to it that would save a copy of the blog text each time
you edited the page, so rollbacks would be trivial. If this sounds like
a worthy idea, I can work on such a system.
Jay
Owen Winkler
>
> The schema I had initially proposed last week had a revision control
> system built in to it that would save a copy of the blog text each time
> you edited the page, so rollbacks would be trivial. If this sounds like
> a worthy idea, I can work on such a system.
Jay! Spread yourself thin much? :)
Owen
BlueSaze
in mind when you planned Habari) you guys have taken the Undelete(Undo)
to a completely different Level. Now that I see the discussion it seems
it way more complicated than what I would have wanted :)
Matthias Bauer
Hash: SHA1
On 12.01.2007 16:37 Firas Durri wrote:
> First, why undelete?
>
> My take: undelete is just a form of 'undo'. To the extent that its
> reasonable, software should support undo to the extent it can. Don't
> ask "do you really want to do this?" if you can avoid that. Let them
> do it, let them change their mind. That's how human beings operate.
Agree completely. Don't bother the user, and make mistakes as cheap as
possible.
> Current arguments are mainly about--when do we "really" delete?
> --> Time based (after 30 days, eg. Gmail)
> --> Item # based (after X deleted comments/posts, the overflow gets trashed)
> ---> Manual (purge only on user prompting, eg. Windows recycle bin)
> --> Hybird/Options based (eg. default to time based, but allow deleted
> items to remain deleted until a manual purge like the windows recycle
> bin.)
I'm in favor of a time-based purge with a short limit, like 7 or 14
days. I really want the undo to be for 'oops, slipped' mistakes, not for
'I changed my mind about this four weeks later'.
Also, I believe we shouldn't expose much UI for this. Maybe a 'Recent
Changes' list which would contain 'Deleted post "foo". [Undo]'. No
Recycle Bin if we can avoid it, don't even tempt the user to use the
trashcan for storage.
The alternative, of course, is a full-blown revision control system. I'm
not sure how hard that would be to implement. Also, deleted items should
be purged some time, lest the database grow out of hand.
- -Matt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFFqFsaaINBKmOS2S4RArCcAJ4+xoE5RtkIMLLp4+pjs0bwPRyOfACfRthP
bOkJVO8CmeeiJo2WwjQ98VI=
=8OJC
-----END PGP SIGNATURE-----
Firas Durri
>
> The schema I had initially proposed last week had a revision control
> system built in to it that would save a copy of the blog text each time
> you edited the page, so rollbacks would be trivial. If this sounds like
> a worthy idea, I can work on such a system.
>
> Jay
Jay, I agree that a revision control system for posts/pages would be
awesome (and a hell of a differentiator, like for collaborative
writing.) My only two thoughts is that there's no hurry to build it
in, and that if we do it'd be different from the undo thing--revision
control would be its own a-class feature rather than shoehorned into
the 'undo an accident' stream. Text boxes already have their own undo
functionality.
phoenix
there is an auto-save feature like 2.1...or I will go crazy! I have
lost too many posts from crashing Firefox or computer freezing or just
being an idiot... auto-save is my savior.
Undo is just bloat in my opinion.
Robin Adrianse
I don't think so -- not if it's used well. Keeping the last 30 changes in the DB for rollback is a great idea, especially for those n00b users who will eventually make a mistake, and instead of them going "ah crap" they can just hit undo.
Scott Merrill
> I don't think so -- not if it's used well. Keeping the last 30 changes
> in the DB for rollback is a great idea, especially for those n00b users
> who will eventually make a mistake, and instead of them going "ah crap"
> they can just hit undo.
I think we need to make a clear distinction between helping users
recover from short-term mistakes, and encouraging sane backup practices.
I don't know where the sweet spot is for number of items to retain in
an undelete (and I don't know that it should be configurable). But
storing more than just a handful of mistakes from which we can recover
veers into the territory of long-term backup.
I'm squarely in the camp that says undelete should _only_ be used to
recover from accidental button presses. "Whoops, I didn't mean to click
that button!" rather than "Geez, I really wish I could recover that post
I deleted last month."
If people take regular backups of their database, they can tease out
deleted items from the backup file as needed. I'm sure an enterprising
plugin developer could permit the upload a SQL export, present the
deleted items discovered, and then make them available for import.
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
phoenix
tool.
Matthias Bauer
> I don't know where the sweet spot is for number of items to retain in
> an undelete (and I don't know that it should be configurable).
+1
> I'm squarely in the camp that says undelete should _only_ be used to
> recover from accidental button presses.
+1
-Matt
Matthias Bauer
> Yeah, just include a good backup script/tool and say "-1" to an undo
> tool.
If you accidentally delete a post, it's far easier to hit an "Undo"
button than to restore a backup and manually replay it into the DB, or
rollback and lose changes since the backup was made.
Also, what about posts that haven't hit backup yet?
I'm very much in favor of having Undo functionality.
-Matt
Michael Heilemann
Real backups are something entirely different and shouldn't even be brought into this discussion. And undo stack is 'click' and you've rolled back to a previous version of something. Restoring a backup is a much lenghtier and more complicated issue, which has a barrier-to-entry that is way too high for it to be used as a viable 'undo' solution.
- Mike
BlueSaze
>only save real saves.
I agree this seem to be the best solution.
On Jan 14, 2:18 pm, "Michael Heilemann" <heilem...@gmail.com> wrote:
> Just revoicing my support for an undo stack. It should ignore autosaves and
> only save real saves.
>
> Real backups are something entirely different and shouldn't even be brought
> into this discussion. And undo stack is 'click' and you've rolled back to a
> previous version of something. Restoring a backup is a much lenghtier and
> more complicated issue, which has a barrier-to-entry that is way too high
> for it to be used as a viable 'undo' solution.
>
> - Mike
>
> On 1/14/07, Matthias Bauer <moef...@moeffju.net> wrote:
>
>
>
>
>
> > On 14.01.2007 03:53 phoenix wrote:
>
> > > Yeah, just include a good backup script/tool and say "-1" to an undo
> > > tool.
>
> > If you accidentally delete a post, it's far easier to hit an "Undo"
> > button than to restore a backup and manually replay it into the DB, or
> > rollback and lose changes since the backup was made.
>
> > Also, what about posts that haven't hit backup yet?
>
> > I'm very much in favor of having Undo functionality.
>
> > -Matt--
> Aloha,
> Michael Heilemannhttp://binarybonsai.com
Scott Merrill
> Just revoicing my support for an undo stack. It should ignore autosaves
> and only save real saves.
>
> Real backups are something entirely different and shouldn't even be
> brought into this discussion. And undo stack is 'click' and you've
> rolled back to a previous version of something. Restoring a backup is a
> much lenghtier and more complicated issue, which has a barrier-to-entry
> that is way too high for it to be used as a viable 'undo' solution.
Yes, "real" backups are an entirely different thing. But as I said in
my email, I see undelete as a fix for unintentional mistakes, not as a
general long-term solution for things.
There are basically two models of "undelete" with which most folks are
familiar. The first is application-level undo (CTRL+Z), which undoes
some operation you've executed within the current running instance of
your program. This restores deleted paragraphs in word processing
applications, for example. Most current applications today have an
effectively unlimited undo queue during each execution of the program.
Once you close the program, though, the undo queue goes away.
The other undelete metaphor is the operating system trash. GNU/Linux,
Mac OSX and Windows all offer some mechanism to 'throw away' an item,
and these items may be retrieved from the trash at some point. When one
'empties' the trash, items in the trash are irrevocably deleted. Some
applications implement this model (email programs, for example).
I have personally witnessed people use the Windows trash or their
email's Deleted Items folder as a storage mechanism, like any other
folder. I desperately want Habari to _not_ support this kind of usage.
Things that are deleted should be irrevocably deleted at some point.
One ought not be able to use the Habari undo stack as another means to
store or categorize posts or drafts.
My mention of backups was to ensure that Habari provide only limited
undelete / undo functionality. If someone deletes a post or a draft _by
accident_, the undelete process should permit them to recover it. If
someone deletes a post, and then several weeks later decides they did
not want to delete it, I say "tough". I don't think it's our job to
cater to every workflow known to man, and I don't think we need to
facilitate an infinite undo queue for lapses of judgment or whenever
someone changes their mind.
A regular backup process and some clever plugins can handle the infinite
undo queue much better than we should ever consider as a core feature.
BlueSaze
>email's Deleted Items folder as a storage mechanism, like any other
>folder. I desperately want Habari to _not_ support this kind of usage.
>Things that are deleted should be irrevocably deleted at some point.
>One ought not be able to use the Habari undo stack as another means to
>store or categorize posts or drafts.
I understand what your saying. I initially requested this feature (if
you read my previous mail on Group Collaboration and writing) since
when your are running a group blog if someone deletes a post the admin
should be able to retrieve or restore it also view the changes that
have been made to the original post.
On Jan 14, 7:38 pm, Scott Merrill <ski...@skippy.net> wrote:
> Michael Heilemann wrote:
> > Just revoicing my support for an undo stack. It should ignore autosaves
> > and only save real saves.
>
> > Real backups are something entirely different and shouldn't even be
> > brought into this discussion. And undo stack is 'click' and you've
> > rolled back to a previous version of something. Restoring a backup is a
> > much lenghtier and more complicated issue, which has a barrier-to-entry
> > that is way too high for it to be used as a viable 'undo' solution.Yes, "real" backups are an entirely different thing. But as I said in
Michael Heilemann
That said, I do think there should be a 'empty after 30 days'-like feature. But I don't think we should force people 'only use paper for writing on, and not drawing', so to speak.
- Mike
Michael Heilemann
http://binarybonsai.com
Owen Winkler
> If people want to use their trash can as a storage room for things, I don't
> think it is our place to deny them that.
Sure, although I think that by saying we allow them to do what they
like, we are specifically missing the concept of creating a process
that they follow. If our purpose is to allow a user to recover
accidentally deleted items, then our process should address how that
happens and not concern itself with how they abuse it. But I think
that it's an important point that skippy raises about shifting the
paradigm mentally from "A place where deleted things are stored" to
"recovering deleted posts".
A lot of discussion has taken place about having buttons for whichever
purpose, and that's fine. Please remember that all of this has to be
implemented in the system, too. It's very simple to say "keep deleted
things for 30 days" but not much mention has been made of how that is
to be accomplished.
Also, I haven't heard much about usability. Nearly every opinion in
this list is from the perspective of "I use it this way", and I'm not
sure that sufficient thought is being given to what a person, fresh
from their first class on using Microsoft Word, is going to to think
about their first experience with this interface.
There are specific questions that I've asked about this before: The
software requirement ("requirement" meaning, "This feature must be
present in the software for it to be released") is that posts have not
only different types and statuses, but that they be defined
dynamically. In a default install, you get "draft", "published", and
"private", but these may be non-existant or there may be many
additional options, depending on what plugins you have applied.
If you specifically select for the post to be "private", and you click
a "publish" button, what happens? I don't know.
If a "deleted" status exists to maintain a "recycle bin", is it shown
in the status list for a user to select? What if there's more than
one kind of "deleted" status? Which one is applied when the "Delete"
button is pressed?
And finally...
Everyone loves the idea of undo/undelete/whatever. Nobody has
indicated any UI about how it works.
So you delete a post. Should it be displayed in a list of all posts?
I would guess not. Where should you see a list of deleted posts?
Does that add a new top menu to the UI? That's ugly.
What happens to the status of a post when you delete it? If it was a
private post before, how is it returned to private status? If you are
a site admin and you undelete someone else's post, are you the owner?
Are you even allowed to do that?
What I'm getting from this thread is a lot of noise about "There must
be a X button on the write page", and no contribution detailing the
functionality that needs to be implemented, the UI that would be
needed to support it, the database structures that would need to be
present to enable it, or ideally the code that would actually make it
work.
While I don't expect every person in this list to be able to hit all
of those points, I have this to say: It's likely that the solution
that offers the most detail in solving these issues will be the one
applied.
I suggest that we relax on the UI-only ideas, and try to get some
functional ideas out there as well.
Owen
Michael Heilemann
On 1/14/07, Michael Heilemann <heil...@gmail.com > wrote:
> If people want to use their trash can as a storage room for things, I don't
> think it is our place to deny them that.
Sure, although I think that by saying we allow them to do what they
like, we are specifically missing the concept of creating a process
that they follow. If our purpose is to allow a user to recover
Not at all. We create the process that best suits how we think the system should work, and how people otherwise use it, be it as a folder or a flower hat, is their problem.
This isn't rocket science; so I think we should care less right now about how the system might be abused and just design a system we think works. If it doesn't, change it. Rinse and repeat.
A lot of discussion has taken place about having buttons for whichever
purpose, and that's fine. Please remember that all of this has to be
implemented in the system, too. It's very simple to say "keep deleted
things for 30 days" but not much mention has been made of how that is
to be accomplished.
Impossible is nothing, as the saying goes. It's easier to scale an idea down than it is to scale it up IMHO. If you don't aim for blue skies now, you might as well not bother.
And besides, that's what the code monkies are for :)
Also, I haven't heard much about usability. Nearly every opinion in
this list is from the perspective of "I use it this way", and I'm not
sure that sufficient thought is being given to what a person, fresh
from their first class on using Microsoft Word, is going to to think
about their first experience with this interface.
Well that depends; I would never post anything on here if I didn't think it was the best solution, period.
If you specifically select for the post to be "private", and you click
a "publish" button, what happens? I don't know.
I don't know what your definition of 'private' is, but in my book doing that would publish the post, but keep it private (so only members of the blog can see it, or whatever your definition is). Publish != public.
If a "deleted" status exists to maintain a "recycle bin", is it shown
in the status list for a user to select? What if there's more than
I'd go with no. But whatever floats people's boats.
one kind of "deleted" status? Which one is applied when the "Delete"
button is pressed?
Why would there be more than one delete setting?
I would guess not. Where should you see a list of deleted posts?
Does that add a new top menu to the UI? That's ugly.
We'll worry about that when we know how the system will work. Can't design for a non-existant system.
What happens to the status of a post when you delete it? If it was a
private post before, how is it returned to private status? If you are
As far as I'm concerned, delete status is a mutually exclusive setting per post. Private stays private, even when it's delete and undeleted.
a site admin and you undelete someone else's post, are you the owner?
Good question. I'd go for a no. But I'd like to hear some opinions.
Are you even allowed to do that?
I've never run a proper multi-user blog, so I don't know what people's preferences are.
What I'm getting from this thread is a lot of noise about "There must
be a X button on the write page", and no contribution detailing the
functionality that needs to be implemented, the UI that would be
needed to support it, the database structures that would need to be
present to enable it, or ideally the code that would actually make it
work.
Again, and working in a creative industry (computer games), where we need to be open to ideas, this is very close to my heart: In pre-production, which this pretty much is, no ideas are stupid and no ideas should be shot down based purely on any technical problems there might rear their ugly head down the line.
Let code-problems be code-problems later, and aim for the sky.
Aloha,
Michael Heilemann
http://binarybonsai.com
Trevor Turk
> What I'm getting from this thread is a lot of noise about "There must
> be a X button on the write page", and no contribution detailing the
> functionality that needs to be implemented, the UI that would be
> needed to support it, the database structures that would need to be
> present to enable it, or ideally the code that would actually make it
> work.
I think the easiest solution would be to have a "deleted_on" DATETIME
field for posts and users. I'm not sure if there is anything else that
might need it as well, but at least posts would make sense.
If you "delete" an item, it would be given a DATETIME value on NOW()
and any queries asking for post listings would include a WHERE
deleted_on IS NULL. I'm not sure what kind of performance hit that
would be, but I don't think it would be terrible. Then, a "Trash" page
would have to be made for the admin area that listed items WHERE
deleted_on IS NOT NULL, or you could flip a switch to change the query
that builds the post listing - just to save code duplication.
I've hacked together a system for storing files online that did
something similar when deleting users. The only problem I ran into that
I didn't really hash out beforehand was what happens when someone tries
to make a user, say, that already exists. Basically, I put up a message
explaining that the user already existed, but was in the Trash - and
linked the user to the Trash page. People seem to have picked it up
pretty quickly. You'd also probably want an "Empty Trash" link that
REALLY deleted all posts WHERE deleted_on IS NOT NULL.
I think that having a 30 day timer on deleted items in unnecessary and
complicated (sudo-cron?), and I also don't think there is any reason to
try and prevent people from using the Trash as a storage bin -
especially if you don't build anything to automatically delete items
from the Trash. That's the bad thing about using the Trash in OS X or
Windows, right? I mean, if there is no storage limit or time-based
auto-deletion, then there's no reason they couldn't use the Trash as a
storage bin.
Frank Helmschrott
Habari should have a revision system and an undo stack - both seperated
from each other. Revision system for posts/pages (let's name it content
:)) and the undo stack for settings and other stuff man could thinkg
about. Also i second the idea michael brang up again (we had that in
another thread these days): auto saves must not go into the revision
system - only real hand made saves have to but probably could be
alternative. If we seperate the both systems (revision and undo stack)
from the productive database tables than they won't be a performance
issue at any time.
Additionally and if possible without too much humble both systems
should be choosen to be deactived by the blog admin if he wishes. I'm
not enough of a coder to see the possibility for that.