behavior of ... button

Synopsis creation and behavior of … button:

Although the ability to create a synopsis from the first few lines of the text in the editing panel is potentially useful the present implementation seems less than optimal. The problem is that clicking on the three dot button overwrites, without warning, any existing synopsis, even when the editing panel is empty. This is, of course, entirely the result of one’s own carelessness and easily reversed with Undo, but still irritating even if a lesson learned.

I feel that it would be better if clicking on the three dot button only created a synopsis if the index card was empty, or generated a warning and option to overwrite if it was not.

On balance even a provisional synopsis is likely to be more useful than the first few lines of a text, and I am probably not alone in tending to jot down brief notes on the index card long before I have started on the main text.

While we’re talking about synopses…

How about a “set selected text as synopsis” command, parallel to the existing “set selection as title” command?

For nonfiction projects, I’ll often have a detailed chapter by chapter synopsis from the client. I like to split this monolithic file into chunks, making each chapter a subfolder under the Draft heading. Scriv.'s Split commands already make this much easier, but being able to set the index card synopsis in this way would save quite a few mouseclicks.

Thanks!

Katherine

I suggested this a while ago, and the response was an alteration in how the 3 dots work. Before it just snagged the first bit of the document, no matter what. Now, if you have some text selected in the document and click the dots, the selection will become the synopsis. So – there is still no keyboard short-cut for doing it, but at least it is possible without a bunch of copy/paste shuffle.

To the original suggestion: This would bother me a great deal. Sure, with documents that are new and unformed that is one thing, but quite often I am writing a summary for some bit of research, or text from other programs that I have imported. In these cases, the synopsis field is initialised with the first few lines of text from the existing document.

Your proposition boils down to this:
In every case where the user makes a mistake and presses the dots, they have to:

  • Press cancel, either by hitting the key or using the mouse.
    In every case where the user wants to overwrite, they have to:
  • Press confirm, either by hitting the key or using the mouse.

This is opposed to the current behaviour:
In every case where the user makes a mistake and presses the dots, they have to:

  • Press Cmd-Z to undo, or use the menu with the mouse.
    In every case where the user wants to overwrite, they have to:
  • …do nothing.

Now, arguably, the number of people summarising and organising pre-existing notes and research is probably vastly greater than the number of new users who accidentally click the dots once or twice before they learn to avoid it until they really want it. Further, your proposal does not actually make the mistake correction process any easier! Cmd-Z is just as easy to press as , and both have the same result. The only thing this proposal does is needlessly complicate the intentional usage of the dots, an action which is much more common.

Excellent. Thanks!

Katherine