Warning on Delete Text Document or Folder or make Undoable?

If the side bar (Draft, Research, Trash) has focus, pressing delete erases the highlighted “scrivening” (text document or folder) without a warning or the ability to undo. I love the multiple view mode but combined with a dual screen I sometimes forget where the focus is!

I think it would be a good feature to add a confirm dialog before erasing the file. Use command-delete to erase without a prompt (this is an iTunes convention). If that is not possible, making the action undoable in the edit menu might be a good alternative. The danger here is that it is possible to make big changes to your project without realizing it.

<< I just realized the file went to the trash, so this is much less critical than I first thought. Still I think this would improve the user experience since focus confusion seems to be a common consequence of the very helpful split view feature>>

Scrivener is my favorite writing environment and I am looking forward to purchasing version 1.0 when available! Thanks for all your hard work.

Edit: I cleaned up the title a bit

You figured out the key point, there is a Trash and it gets used. :slight_smile: Other than that, depending on your highlight colour setting, one visual cue that can help you out is the intensity of the selection bar in the Binder. When you are off in a split or the Inspector, the selection bar because a much lighter version of itself. A dark bar means you are in the Binder.

Accidently deleting files from the binder is most likely to happen when the binder has focus but the user is not looking at it, so it does not really matter what it looks like when it has focus.

This is a human interface limitation, not a Scrivener limitation. Nevertheless, there are plenty of users who have posted various solutions to the “focus problem” and most of these have been rightly rejected. Each post should be taken as an indication that users sometimes fail to distinguish between the screen element they are looking at and the screen element that has focus.
Given that users make mistakes that are easily anticipated, how costly should those mistakes be?

Yes, given that this is in the Help file and the FAQ, I think this should stay as it is. It is possible to delete accidentally, but only if you are not keeping track of where the focus is - which is a user error, not a Scrivener error. And given that files are only moved to the Trash in the binder - and therefore not permanently deleted - the error is not very costly. It happens once, you realise it is in the trash, move it back to where it should be, and then, from then on, you remember that you need to remember where the focus is. It is a learning experience that causes no loss of data, so I think the current set up is best. Any other set up only annoys users who have already learned these things. :slight_smile:
All the best,
Keith

I for one would find it annoying. Given the fact that nothing is lost, I think a warning would be a solution in search of a problem.
E

I’ll have to admit that the first time I accidentally deleted a Srivener file, on which I had worked for an hour, was a scary moment. I sat there for a long while, trying to figure my options: close without a Force Save? Copy last night’s backup to my prime drive? And then I finally noticed the Trash icon.

Possibly a first time warning would help: “You are about to delete a file, which will go into the Trash. It will remain there until you delete the Trash.”

And some users may not realize that you mean Scrivener’s Trash rather than the Finder’s. Not the current beta-testers, of course, but consider a college-level writing class!

Users should just read the Tutorial.scriv that comes with Scrivener, which is really the quickest way to learn how to use Scrivener anyway - in its explanation of the binder, in Step 1: Basics, it says:

[quote]
The “Trashâ€

Yeah, other programs (like Mori) have a trash folder with no warning. Not that I’m totally against the idea, but just that Scr.'s way of doing this has precedent. I used to actually be annoyed that I had to ‘double dump’ something when I wanted to delete it–dump it first into a trash folder than empty that. But of course the Finder works this way, without warning as well.

At that moment, a rush of adrenaline coursed through parts of your brain and chemically reinforced the lesson. Bet you never had to be told again how the trash works in Scrivener. Fear is our friend and teacher. :slight_smile:
E

The only difference is that in the Finder, the command is cmd-delete, rather than just delete—a more sensible adjustment, if one need be made, than an ‘are you sure?’ dialog.

True. Unless you use the delete icon (I put) in the finder toolbar, which is what I do. Then it works just like Scr. :slight_smile:

Proposed changes for binder:
1] delete brings up a confirmation dialog
2] command delete moves to trash without dialog
3] Make delete file undoable

Why this is a Good Thing:

There is precedence:
Take a look at Mail.app, which uses the same panel layout. Notice that you cannot accidentally delete a mailbox while composing an email if focus is not where you expected. Of course Finder does delete without a warning but we do not write in the Finder and every object in the finder is the same class (file system object). We use a key-combo, not a single key, to delete files. The delete action in also undoable.

There is consistency:
It takes special effort (menu bar action, button click, key combo) to create a file, so by symmetry, it should take a special action to delete a file. I cannot create new file simply by typing its name when the binder has focus.

Documents are a different class of object than words. I expect documents to have some permanence and I do not delete them frequently. For those of you who do use “delete” to put documents in the trash, how often do you do so? Once a day? Words, on the other hand are created and destroyed thousands of times a day. My point is that words and documents should be treated differently because we use them differently.

This change improves usability.
Imagine you contracted for a usability study. How likely would it be that the report would say: Users sometimes lose track of where focus is and perform unintended commands?

I keep many documents in my binder, such that the elimination of one of them is not immediately apparent. To the user, this feels like Scrivener is losing documents. Sure they are in the trash, but who looks in the Trash? People who are annoyed by confirmation dialogs will learn to use command-delete. It took exactly once for me to learn this in iTunes.

//
Users should just learn the command line, its all in the man files! :wink:

I second these motions. Eiron may be right, that fear is a good instructor, especially for seasoned scribes like the present beta-testers, but one day Scrivener may be used in schools to teach writing, and THEN you have users who need dialogs, warnings, and some mercy mixed with justice.

And KB is right, too, that we should read the manual first, but (and I say this as the author of many manuals), that’s not how most users work. They launch a program, fiddle with its buttons, and see if they can learn intuitively how it functions. The more self-evident the interface, the more they like it. Later on, they may read the manual for reinforcement or to learn more complex functions.

In my own case, I was used to the Delete warning that Devon products make when I delete an item. It’s a simple “Are you sure?” and to confirm, I just tap the Return key. That seems to me enough, although I realize that a separate Scrivener Trash does provide even more protection from accidental deletions.

del

I understand what you’re saying, Howarth, but the point is that this lesson comes very cheap and even students and beginners won’t really suffer from not having their hands held. Basically the lesson is:

If you’re sloppy, or don’t bother to read the manual you may be mildly inconvenienced by having to retrieve your document from Scrivener’s trash. At the worst you might one time think for a few moments that you have lost something when you haven’t.

Not exactly what I’d call justice without mercy. If they can’t deal with that, maybe they should stick to crayons.:slight_smile:

I don’t really mean to be this prickly and Chris’s suggestions are not unreasonable, but those “are you sure?” messages really get my goat.

If a sidewalk is cracked and uneven, how should a community respond?

a) Blame people who trip on the crack because they should watch where they are going.
b) Create a pedestrian handbook and identify the potential hazard.
c) Post a warning sign near the broken sidewalk to alert pedestrians.
d) Fix the sidewalk surface.
E) Declare it a feature and preserve it as a cultural treasure.

(Thanks Erion, I have added a choice E in your honor) :smiley:

Regardless of Keith’s choice, he has built a great app and I will happy to use it, even if I have to pick myself up and dust off after the occasional fall. :wink:

If a country path --that people like-- has bumps in it should we pave it over and turn it into a sidewalk, just in case someone is inconvenienced? :slight_smile:
E

del

It is a fact that users make mistakes related to this implementation. Whether you personally have tripped over the design or not is not at issue.

Part of good program design is identifying areas that confuse users and smoothing them over.

I personally dislike confirm dialogs and learn shortcuts to avoid them. Yet, I still think a confirm dialog is a good idea as long as the delete key moves files in the binder.

I would personally prefer that the delete key do nothing (silent fail) in the Binder, but I think a dialog is more appropriate since some users, including yourself, obviously think pressing delete is the correct way to delete a file and you would be confused if nothing happened. :slight_smile:

del