The only way that’s going to happen is if you overlooked the item or you pressed Esc.
And yet, it has.
Here’s a worldshaking thought for you. Perhaps Scrivener has imperfections.
I give my structure temporary names that are meaningful to me and use templates, so I don’t run into unnecessary hassles of pre-populated Binder items, but it’s there for others who want it, and it works—I’ve tied it, like most things Scrivener.
All-in -all, Scrivener is a perfectly stable experience with no complaints about which I’d care to smoke my socks.
2 Likes
On the few occasions that I have needed to bend Compile to publisher’s wishes I have started by watching the video tutorial on the topic. After that it makes more sense and I get what I want; however, since the last time I did it all is forgotten but the next time there is a need to Compile I will be following the same process.
1 Like
Again, I’d have to look at the project. The screenshot alone tells me nothing except that you have accurately described the formatting you see.
That’s one of the reasons for our new application, now in beta testing:
I can’t say much about it, but I can say that there have been a lot of feature requests in the beta forum to which Keith has responded “that’s what Scrivener is for.” Every single feature in Scrivener’s Compile command is there because someone wanted it.
2 Likes
Can you not see if you can replicate what I’ve described happening? Sending you 17 megs of my WIP project to leaf through seems overkill.
You could duplicate the project and strip it down to the minimum necessary to demonstrate the problem.
In my experience, “grey italic” means that the text (either Binder title or Synopsis) has been auto-generated. If you are seeing an exception to that rule, then you’ve identified a bug. We’d be happy to look at your reproduction case.
[deterrent-level complexity] is one of the reasons for our new application, now in beta testing
I’m not necessarily advocating removing features so much as taking more a user-centered centered approach to explaining them, precisely because they’re so complicated.
Sadly, I am not as confident as you are that improved documentation is the answer. The number of times I find myself explaining very basic features in response to support requests is … not small.
3 Likes
Sadly, I am not as confident as you are that improved documentation is the answer. The number of times I find myself explaining very basic features in response to support requests is … not small.
See, to me, that would demonstrate that improved documentation is in fact very necessary. There would still be a hardcore of people apparently wanting to user a writing app without being able to read, but you’d triage out a lot of them.
When the very first section of the Tutorial project says that you can drag and drop documents in the Binder to rearrange them, having users complaining that they “put the document in the wrong place, help?” is NOT a documentation issue.
You do have a point about the Compile command, though. I’ll see if there’s interest internally in creating some kind of “Compile FAQ.”
1 Like
Honestly, I do think documentation would help. A short screen recording of documents being rearranged back and forth in the binder, for instance, annotated or with a voice over explaining ‘I can move it here, maybe change my mind and put it back again’. People get to understand things in different ways. Put it this way - the time it would take to do be about the same time it takes to answer one of those queries.
You mean something like this?
https://www.literatureandlatte.com/learn-and-support/video-tutorials/organising-1-the-binder-the-heart-of-your-project
Something like that, yeah, except that it doesn’t explicitly say ‘you can move things from place to place, more than once’, which you would think is obvious, but as you say, apparently not. It might even be possibly to drop an audio line into that video to say that, I dunno.
It does fit into the general drift of Scrivener support though, which is to point people to short lectures on functionality, rather than framing it as ‘this is how you achieve the specific result you want’.
I’m assuming that most users will be compiling an MS, a script, an outline or collecting a whole bunch of notes and randomness into one (EG Word) document. I would bet five how-to’s describing how to create those, each with a few simple tweaks to cover, say, font changes, margins, excluding levels, and including notes/synopses, would cover 80% of frustrations. A lot of people would be satisfied with knowing where to click to make limited changes to those templates; and for others (probably the likes of me), they could use it as base to figure more things out without having to dive into a list of variable functions. That final level of detail is probably only for people who want to create an Amazon friendly ebook, and they’re going to have to get their heads round it whether on Scrivener, Calibre, Vellum, or where-ever else.
As previously discussed, that’s because there are hundreds of slightly different “specific results” that people want. At some point we’re always going to lose people who are unwilling to read.
2 Likes
Excuse me butting in uninvited…
I have sympathies on both sides, which is useless information, but I have certain bona fides in the difference being discussed having once written (and had published) a book about a complex piece of software – a so-called DAW (Digital Audio Software).
Simplifying greatly, such a task is basically translating the “important bits” of the reference manual into something more digestible for the average user, with a few extras thrown in that stretch things into the expert domain. Just to buff up the reader a bit.
Borrowing language from elsewhere, I like to call the main thread through the text the critical path.
Now, I think of Scrivener as two distinct parts: the compiler, and everything else. I’m pretty sure I once suggested on the forum that the compiler should be a separate program and was shot down by Keith, as I would have expected. But maybe I chickened out, knowing the response, which I fully understand. I’m cowering still. That’s not in any way meant to criticise the compiler. It’s an amazing piece of work, as anyone who know TeX/LaTeX will attest.
Anyway, I do think that a document that describes the “critical path” through the compiler would have value.
I suspect one of the problems is that folk don’t use the compiler until they need it, which is entirely reasonable. The problem is that by then they have a complex project to wrangle, and most likely, a fear of altering one of the compiler’s illimitable knobs, dials, and switches in such a way that they may never be able to recover. But perhaps that’s just my experience.
As an experiment, yesterday I created a new blank project, and then built it up by adding scenes and chapters, with styles and other stuff, one by one, bit by bit, driving everything through repeated compiles, producing a pdf. It was enlightening, and I soon encountered areas of confusion. I think something of that nature would be useful. By which I mean showing the model/abstraction rather than telling it, I suppose.
3 Likes
I once suggested on the forum that the compiler should be a separate program and was shot down by Keith
The same thought crossed my mind but I was already getting enough flack. It’s odd that there is literally one menu item that says ‘Compile’, like it’s an afterthought. Which it isn’t - the point of Scrivener is to things in small units so they can be rearranged. Half of that is the editor, binder, outliners, cards etc.and they get all but one of the menu items. The other half, putting it all back together, is squished into one menu item, leading to everything else squeezed into three dialogue boxes.
As well as people not using the compiler till they have something they really don’t want to screw up, I suspect a lot of people just never get that far with their projects at all, or if Scrivener is being used to organise shorter things like blog posts, just cutting and pasting it into a CMS.
And often a looming deadline. My number one recommendation for Compiler wrangling is to start early.
Edit: Which is, I think, part of why Word is seen as “easier.” The WYSIWYG nature of Word encourages tweaking as you go along. (Of course Word also has a vast library of pre-existing templates and similar resources.)
2 Likes
Reading this thread was enlightening. I felt quite identified with both points of view and can clearly see where they are coming from.
I’ve been a Scrivener user for more than a decade, with several hiatus in the middle, and I must confess that every time I take a new project, “relearning” to compile has been the most difficult part.
I guess that with great power you no only get great responsibilty, but great effort as well. 