Alt+N creates new item in unexpected location

(You may want to reclassify this a feature change, but I’ve filed it here because I think the program is not doing what one expects it to do).

Select a container (in the binder or outliner) with child items

  • do Alt+N to create a new child item
  • the new item is inserted after the container’s last child item
  • IMHO, the user expects the new item to be created as the first item in the container. If I wanted to create a new item in last position, I would do so by selecting the current last item, and invoking Alt+N from there.

Sorry, but your proposal sounds completely unintuitive to me – as the vast majority of my new documents go at the bottom of the folder, so the current behaviour is exactly what this user expects and wants. So, definitely not a bug.

Changing it to add the document at the top would be useful every now and then, at the expense of making the more common operation more complicated, so I’d really hope that the default stays as it is.

Not saying your view isn’t worthy of consideration, just that it’s by no means a given that ‘create a new file at the top of the list’ is what all users expect and want.

The current situation gives us two equally accessible ways to create a new item at the end of a list, and no easy way to create a new item at the start of a list.

Wouldn’t it be better to have one of each?

I don’t think so. With your proposed way, you’d have to navigate to the last document in the folder every time by the keyboard, or use the mouse which is the same for both options (and which should be avoided as much as possible).

With the situation as it is, you only need a maximum of three key strokes once you’ve highlighted the folder to add a new file at the top of the tree.

  1. Down arrow to highlight the first document.
  2. Cmd-N (or whatever in Windows), enter the file name
  3. ctl-cmd-N to move it up one.

Better to reserve the single keystroke for the most common case, particularly as that’s the one people are used to.

Navigating either to the last document in the folder, or to the containing folder, from a random place in the project is likely to be the same number of keystrokes in either case, however you do it, mouse or keyboard.

In fact to move the new file from the bottom to top of the folder, the last step would mean a ctl-cmd-N for as many documents as there are in the folder - dozens, in some of mine. Which usually means resorting to the mouse, which, as you say, is undesirable.

We may have to agree to differ on this one!

Other way round – the current situation only requires 3 actions while your proposal needs multiple movements. Try it!

You highlight the folder, press down arrow to highlight the first child, cmd-N to create the new document and name it. It’s now second in the list, so all you need is the shortcut to move the document up one (ctl-cmd-up). Three actions.

If you have your proposal, then you need x number of ctl-cmd-downs to move something from top to bottom. :wink:

You’re absolutely right, it’s a matter of workflow which is the better option – that’s why I suggested the current behaviour isn’t a bug or unexpected by all users.

But I’m only a user, so if Keith thinks otherwise, that’s fair enough…

Not this user. I start at the beginning of my project and write until I get to the end. Why would I want Chapter 3 to appear before Chapter 2?

More generally, with all requests like this it’s important to keep in mind that documents in a Scrivener project are component parts of an integrated whole. They are not arbitrary, unrelated files in Finder or iTunes. The Binder doesn’t behave like a standard file manager because it isn’t a standard file manager.