Warning on Delete Text Document or Folder or make Undoable?

Actually, single key deletion using either backspace or delete is very common amongst Mac apps for deleting items in a list or an outline. Try it in other areas of the application to see. Deleting keywords, custom labels, and so on. The Binder is not meant to be thought of as the Finder, and the items within it are not technically represent files in the Finder sense. You cannot create new files with a single keystroke, either. That is an outliner convention, as is . You cannot arrange files beneath each other, or up and down in a list. Files cannot be converted into Folders and vice versa. A single click does not open them. And so on. The whole thing feels like an outline – why should item removal feel like something else?

I agree that it would be nice to have an Undo command for putting files in the trash, because this would be more consistent with programs like iPhoto and the Finder (or HBN/Mori).

But for the very same reason (consistency with other programs) I don’t want to see a warning dialog when I delete a document. You don’t get such a dialog in the Finder or in iPhoto either. You only get a warning when you empty the Trash.

Well, you do. Or at least you should :wink: Everyone who knows that Scrivener has a Trash folder also knows where to look if he/she has accidentally deleted a file.

iTunes is a bad example in this context, because it doesn’t have the safety net of a Trash folder. This is why it gives you a warning when you delete a file, and why programs with a Trash folder don’t.

But I do agree with you (and Maria, and cruxdestruct) that cmd-Delete would be a better, safer shortcut for trashing files than Delete. This would prevent users who only want to delete a word in the editor pane from accidentally trashing a file in the Binder.

Ideally, a future version of Scrivener could work like this:

  • No warning dialog when you delete files in the Binder.
  • [Modification:] Files can be deleted using the menu command, the toolbar, or the shortcut cmd-Delete.
  • [New:] Trashed files can be retrieved with the Undo command.
  • You only get a warning dialog when you empty the Trash.

Now that is something I can agree with. I think any other modification would destroy the outlining style experience. It is a little thing, Cmd-delete, but it makes a difference. And all of this talk is about the Binder, what about Outliner and Corkboard views? They are just re-visualisations of the Binder – should they be constricted too? I think messing with them at this point would be detrimental.

What AmberV said. :slight_smile:

I think that you have identified the main source of disagreement on this topic. :slight_smile:
It is not clear what metaphor to use when thinking about items in the binder.

I think the binder metaphor should be based on the common “files” and “folders” metaphor. As a program user, I am impatient and hate to read manuals. I feel I represent the majority of users in that regard. When I look at the binder, I see files and folders, because the UI elements represent “Files” and “Folders,” concepts I am used to (as a computer user). This metaphor is further supported by the fact that every Document in the Binder exists as a File in the project bundle.

What I do not see is an outline. Outlines are numbered and have super and sub-headings. The binder is a hierarchy of files arranged into folders—it is a branching data structure but clearly not an outline, even though it has some nifty file clustering and arrangement features.

When was the last time you used a key-combo to create a list item? Scrivener is pretty clear that each new item in the binder is a document, since the command is Documents>New Text, not Outline>New Entry. The conventional way to create and delete documents is with a key-combo or menu item. The confirm dialog when pressing the delete key is for users who do not know this, to gently prod them to adopt power-user habits.

I must concede the point about single click to open, though in these new-fangled sidebars, single click to view is the new convention. See xCode, iTunes, Mail.app. iTunes may be a UI travesty, but it still follows the “viewer” convention.

Using the return key to create new documents and the delete key to eliminate them is somewhat inconsistent given the status Scrivener assigns to objects in the binder (Documents) and the presentation of folders and documents as the UI elements Folders and Files. It would be more consistent if highlighted the name of the selected file for editing and was ignored. Programmers can choose to implement however they want but using standard UI elements is like a contract with the user because it creates reasonable expectations on the part of the user about how the program behaves. Violating reasonable user expectations confuses and annoys the user.

Thanks to all of you taking the time to read and comment on this thread,
Chris

Actually, that is not not technically true, only superficially. Each item in the Binder represents at least two, and potentially up to four different files in the underlying filesystem (to my knowledge). The main context area is an RTFD file. Likewise, if you have entered notes for the item, that is created as another RTFD file. If you have links, these are stored in another file. Finally, if there are Snapshots these are stored in yet another binary file. Further, the issue is complicated by types. If every “document in the Binder exists as a File…” why doesn’t every folder in the Binder exist as a Folder in the project bundle?

Since I use TAO, constantly. TAO has several different commands for making a new item, depending on whether you wish to make that new item a child, sibling, or aunt. Likewise, in Tinderbox there are several different keystrokes used to create different types of items. But – as I said in my previous post – Scrivener doesn’t require you to use a combo, it just lets you because that is the convention on the Mac. Hundreds of applications use that same keystroke to add items into lists.

I would have to disagree with you on this, too. Scrivener actually makes it quite clear that the “The Draft,” is a document. When you are done with your project and you export it – you get one file. The bits that go into the Binder are merely components of that file. Mine are broken down by scene so I can do better arrangement and searching. It would be a royal pain to write a book like that using hundreds of RTF files in the Finder.

If you go back and read the design concepts for the Binder and its ancillary visual views, the Corkboard and Outliner, they were all optimised to promote rapid brainstorming on one end, and flexible editing on the other end. The manner in which you can construct a branch of thoughts with index cards, or in the Binder itself as an outline, is very fluid and doesn’t require up-front decisions. Files can become Folders if the need arises, or vice versa. New entries can be as rapidly entered as when typing in a spreadsheet, using the key. Stuff can be moved around, grouped and un-grouped, and so on. Why is it that I can put pages of notes into a Folder? None of this is anything even remotely like the Finder, or any file manager / filesystem I have ever used.

Maybe I’m just used to it, but when I look at the Binder, I don’t see “files and folders,” in the traditional sense. I see pieces of my book. I see an outline. Part 2, Chapter 32, section D.

So basically, your debate comes down to which icons are being used, because nothing in the actual usage of the Binder is exclusive to file management (saying they form a tree is not exclusive, many things form a tree). Would this entire thing not be an issue for you if it looked more like Mori (which, now that I think about it, is also quite similar to Scrivener, with the exception of the Bullet icon for end-node document types)? Because speaking from usage and functional end result, the two are extremely similar, and I’ve never heard anyone say that Mori should act like the Finder because its outliner contains document-like items contained in folders.The stack of papers icon doesn’t look like a filesystem element. The document icon could go either way, but since on the Mac documents nearly always have a page curl, it doesn’t quite feel like a “File” to me – more like a page, or a section.

Where your argument starts to make more sense to me, is outside of the Draft, especially in the case of external media that has been imported into the project. But, would you really want the application to act differently in different parts of the same outline tree? Either you sacrifice the rapid addition/subtraction brainstorming qualities in the Binder, or you have that kind of flexibility everywhere. Back to the Corkboard, should the delete key do nothing when you try to delete an index card? According to your primary argument about usage contracts, that would be a violation. So if Outliner and Corkboard should remain the way they are – given that they are just different ways to look at the Binder – why tie up the Binder with warning klaxons and Finder metaphors?

Now i’m getting annoyed. Since when did

come to mean “there should be no need for a manual”? Because of this sort of argument people like Keith are increasingly forced to forgo genuine functionality for the sake of simplicity (not to say simple-mindedness). Fer chrissakes, it’s not gone! It’s in the friggin trash!
Must we dumb everything down?

E :imp:

p.s. I hate reading the manual too, but if Im confused I check it. No Big Deal.

Proposed changes for users:

  1. Read the tutorial.
  2. Um, that’s it.

:slight_smile:

Look, this won’t change. End of. The only point I agree on is that it would be better if Undo worked in this situation, but Undo is a prickly topic and we don’t live in a perfect world. Unfortunately I had to make the decision to destroy the binder’s undo stack whenever a new document is loaded into the editor. (Note that if the editor is “locked in place”, any changes made in the binder are undoable - it is only the changing of the document in the editor that destroys the undo stack; this was a technical rather than a UI decision, because of the number of elements that would suddenly no longer be available for undo when the document is switched. The creation of Scrivener - as is true for the development of any program - has been a constant balancing act between the ideal and the achievable-in-a-realistic-time-frame-for-one-person.)

As for all this stuff about UI consistency, contract with the users and all that - go tell Apple. Apple themselves are so brazenly inconsistent in their user interfaces (ProKit, iApps, Keynote and Pages, iTunes something else altogether) that it is no wonder independent developers cannot keep up. But really, I designed Scrivener to work how I wanted it to work. I’ve never tried to pretend otherwise. :slight_smile: And I like hitting delete to move a document to the Trash. Simple as that. It feels right, it feels good. And if I made a mistake (and I should say that I have never done this by accident), I could just drag it out of the Trash back to where it should be.

My main question to users who think this is an issue is: Really, what did you think the Trash folder was for? When you first opened Scrivener, you would have seen three folders on the left. Of these three folders, I would have thought that the Trash would be the most self-explanatory - given that it works like the Trash folder in any other Mac application. And frankly, if you can’t be bothered to read the tutorial, the Trash is the least of your worries. You will have hell exporting anything, given that you really need at least to read the tutorial to understand the special significance of the Draft folder. And if you don’t know how Trash folders work in OS X apps, is that Scrivener’s, or my, fault?

Now I wonder why no one has ever posted asking, “Why can’t I drag image files into the Draft folder?” Because to me, for users who have not read the tutorial, that would be far more confusing than the function of delete and the Trash folder, which really are consistent with many other programs.

Anyway, that’s a lot more words added to this topic, but in short: this will not change. The current set up makes more sense. No, really. :slight_smile:

All the best,
Keith

EDIT: If this post comes across as a little rude, I apologise. I wrote it between getting home and having to go back into school for the class’s Christmas performance. :confused:

I don’t quite get the big deal here either–though I do get it is to some. I greatly dislike warning dialog boxes and get rid of them wherever possible. So I’m glad there will be no such annoyances with Scr. I was so glad when the import dialog box went away!

The only time I accidentally deleted something it was because I thought the focus was on a piece of text and it was actually on the file in the binder. So, poof, it went into the trash. And then I went in and got it out.

Having an Undo ability would have been a nanosecond quicker, I suppose. Okay, maybe a whole second. :slight_smile: