Tags:
extract_idea1Add my vote for this tag extract_stuff1Add my vote for this tag interaction_design1Add my vote for this tag stale_content1Add my vote for this tag create new tag
, view all tags
When I started using TWiki I thought it was good that it's difficult to delete a topic. Here are the steps:

  1. More
  2. Rename/move
  3. Change Web to Trash
  4. Clear all checkboxes
  5. Rename/Move

Now that I'm a power user I find it irritating and it slows me down too much (especially during refactoring). I want a one-click "Trash" button.

Before you freak out let me say that I don't subscribe to the "Are you sure? Are you sure you're sure? Are you really sure?" philosophy of guarding dangerous features. Instead, I think the "make it easy and make it just as easy to undo" philosophy is better. I think the current system of having a Trash web fulfills this second requirement, but if it doesn't then let's focus our energy on making it easier to undo rather than harder to do.

-- TWikiGuest - 12 Sep 2002

This could be improved by putting a Trash button on the More page, with a link to custom trash options. The default behavior would be:

  • remove from all Webs
  • NOT update links, so you can see the deletions as now question marks appear after the former links. Note that this is different behavior than when you would rename (move) a page: then updating links automatically would be preferable.

Custom trash options (another page) would give the possibility to

  • remove from current web only
  • DO update links

Undoing is already very easy: just click on "Put it back" at the bottom of the page in the Trash web.

-- ArthurClemens - 01 Sep 2003

I like the Trash button idea. For consistency, better show a link instead of a button?

Suggested text in More page:

  • Rename or move topic:
    • Rename/move topic, looking for references in Codev web only.
    • Rename/move topic, looking for references in all public webs. (recommended)
  • Delete topic:
    • Delete topic, looking for references in Codev web only.
    • Delete topic, looking for references in all public webs. (recommended)

The Delete topic should lead to a confirmation page. Possibly show the Move page with referred topics unchecked?

Opinions?

-- PeterThoeny - 02 Sep 2003

I prefer to use the term "Move to Trash" as put forward in DeleteTopicShouldNotFollowIt.

A confirmation screen would not be necessary if you show also a link "View deleted pages" that links to the Trash web. I agree with our TWikiGuest above the "make it easy and make it just as easy to undo" philosophy. It is easy to undo trashing.

So you can have one link with an ellipsis character (...) to indicate that more options will follow, and one delete link without to indicate the command will take place immediately. An ellipsis character () after a menu item or button label indicates to the user that additional information is required to complete a command. source

And to reverse the options:

  • Delete topic:
    • Delete topic (recommended) does not update links
    • Delete topic ... custom trash options: looks for references in Codev web only; updates links

  • Rename topic:
    • Rename topic ... (recommended) looks for references in all public webs
    • Rename topic ... looks for references in Codev web only

  • Move topic to other web:
    • Move topic ... (recommended) looks for references in all public webs
    • Move topic ... looks for references in Codev web only

-- ArthurClemens - 02 Sep 2003

One of the other annoying problems with Rename/Move (and probably in the future a delete) is that the destination cannot previously exist. It would be very helpful to give an option to just push the existing destination into the archive as a previous revision on the Rename/Move (move to Trash web).

-- TomKagan - 02 Sep 2003

Huh? What do you mean with destination? And push as a previous revision?

-- ArthurClemens - 02 Sep 2003

It would be nice if you could delete a topic and redirect all link to it to another topic. This would be particularly useful to me in updating some badly designed TWiki Forms.

I think I understand what Tom is trying to describe. If when deleting the topic it is already in the Trash web then he is saying that the topic in the trash web should become a previous version of the newly deleted topic. The problem that I see is that there are two sets of history and it wouldn't make sense to merge them.

Maybe what we need are some kind of deletion "stubs" that are left in place of the original topic that contain meta data of where the topic has been deleted too. Then if it is recreated the topic picks up the meta data and if it is deleted again you are left with a "stub" pointing at two deleted topics. The filenames of the deleted topics, thier revision history and the attachments directory could all include the date-time it was deleted, those date-times would be stored in the deletion "stub". You could include similar information if a topic is moved. Then when you look at a topic that doesn't exist you could see a history of where it has been deleted or moved. This history could also be made available from the more page for existing topics. See also my comments in DeleteTopicShouldNotFollowIt.

-- SamHasler - 04 Sep 2003

>>Huh? What do you mean with _destination? And push as a previous revision? _

Move: from source to destination. 'Source' is the name of the topic to be moved/renamed. 'Destination' is the new name of the topic. By pushing as a previous revision, I mean that if the destination exists, it should automatically be put into RCS as the previous revision and the entire topic overwritten. If you think about it, this is sort of like what would happen if someone radically edited topics manually. However, if the Rename/Move/(Delete to _trash) worked this way automatically, A TWiki user would have a full ability to click on "put it back and revert to previous version" to unwind it.

-- TomKagan - 04 Sep 2003

I understand this is a feature comparable to creating a backup version? Could you label this feature then:

  • Create backup:
    • Backup topic this will be stored as rev. 1.6; the new working revision will be rev. 1.7

Or would the backup version go into _trash (or _backup?).

-- ArthurClemens - 04 Sep 2003

Since the _trash web is no different than any other web, it would make sense to just start using RCS for this case. I don't see this as a 'create backup' and thus, consider that to be unecessarily complicating things. I don't see a need for a _backup web needed by the UI.

To me, moving an entire topic source to a new destination, whether via Rename, Move, or Delete, should be identical to a radical edit of the source (new revision is empty) and destination (new revision is completely different but user sees deja vu of the original source topic).

-- TomKagan - 04 Sep 2003

Isn't that non-intuitive. I would expect that moving or move to trash would put the content of a topic and it's attachments somewhere else and leave nothing behind, and if the trash web is cleared out regularly this would eventualy free up the space used.

-- SamHasler - 05 Sep 2003

In my humble opinion, I don't think it's non-intuitive. If revision control exists, it is reasonable to to have prior versions of the topic available even if the topic's current iteration is, for all intents and purposes, removed.

Having a way to "take out the trash" seems like a reasonable idea, as long as a user has the ability to "undelete" (which they do now because of the existence of the _trash web) before triming prior revisions out of the _trash web.

-- TomKagan - 05 Sep 2003

It's not clear to me where (or how) the stored revision could be found. How do you provide access to the topic? Considering it was conceptually deleted.

-- ArthurClemens - 05 Sep 2003

In my humble opinion, deleted topics should be found via the exact same URL as a topic which exists. Requesting that URL would cause either a generic "oops - not found" page or find an actual topic that just happens to say "I was here before but now I'm not." Looking at the revisions would work the same way as now (the footer on the displayed screen would have: "Diffs | r1.36 | > | r1.35 | > | r1.34 | More" or something like). This would allow for "deep linking" into the website. The search could also be extended to provide a "find dead topics" capability (conceptually different than an "orphaned topic" or a "topic that petered out." smile )

Hey, I just thought of this: If someone subsequently creates an mew topic where one existed previously but was deleted, (or moves a topic on top of another from somewhere else), the revision could start with a new major number - Diffs | r2.0 | r1.36 | r1.35 ...

-- TomKagan - 05 Sep 2003

Now I get your idea. Interesting. It is not what you would expect normally from deleting things, but it can be useful. The topic text gets stored in a revision, and is replaced by a default text "This topic was deleted" (perhaps with a date). This would make the Trash web unnecessary. Perhaps the topic would get a META variable that denotes the 'deleted' status.

If you are serious about it, could you work it out in more detail? For instance what happens to links that are updated?

-- ArthurClemens - 06 Sep 2003

Looking at the above proposal for Delete/Rename/Move, I find it looks too complicated: too many options. I want to move the options of Rename and Move to their own page, and also to simplify the explanations. So the simpler layout becomes:

  • Move to Trash:
    • Quick delete recommended: does not update links (View earlier deleted pages)
    • Custom delete ... options to update referring links

  • Rename topic

  • Move topic

-- ArthurClemens - 08 Sep 2003

I made a set of changes listed in BetterMore. This is work in progress; you can try it out here on TWiki.org.

Please discuss "Delete" spec on this topic here (BetterMore is the doc topic)

-- PeterThoeny - 31 Mar 2004

Looking at the implementation, it is a bit strange to see "Delete" and "recommended" so close together. I now prefer to put "recommended" at the end of the phrase.

-- ArthurClemens - 31 Mar 2004

Moved "(recommended)" to end of line. Change is in TWikiAlphaRelease and TWiki.org.

I was considering the "quick delete" option, but I am not sure if this is the right thing to do. Unlike in a file system, linked topics are the norm, not the exception. Therefore it is important to know what topics link to the topic to delete.

One alternative would be a quick delete with a result page showing a list of topics that show now unresolved links.

-- PeterThoeny - 31 Mar 2004

Please have another look at the flow diagram in PatternSkinCodeChanges: Flow_More.pdf.

-- ArthurClemens - 01 Apr 2004

Arthur, quiet detailed graph! Same idea with quick delete, followed by a result page showing back-links smile

Separating Move from Rename can be logical, but it also clutters the screen. Moving both to a separate screen whould reduce the clutter but requires an additional click.

-- PeterThoeny - 02 Apr 2004

Regarding screen clutter: it is not so clear to me why we offer 2 options for both deleting and renaming. We can simplify things by creating 1 link that goes to the "recommended" page. I think that there are only relatively few cases that the user wants to update links locally. And with delete, updating links is not set to on.

To have a separate option for Quick delete, yes there needs to be a page that shows rotted links. But that is a conceptual problem: where is that page located? Because the topic has moved to the Trash, the More page it is not accessible from the web it was on before.

And I propose to use the name "Advanced actions".

-- ArthurClemens - 03 Apr 2004

I had a situation the other day where I wanted to delete a topic and rename all its links to a different topic. Could the page that shows rotted links allow you to rename them?

-- SamHasler - 06 Apr 2004

Edit | Attach | Watch | Print version | History: r31 < r30 < r29 < r28 < r27 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r31 - 2005-03-03 - WillNorris
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.