Hi,
I use Scrivener on a daily basis for scholar writing, and I really enjoy the clarity it brings into the writing process. Although I would expect a couple of improvements (e.g. the choice of presets instead of styles is still a drawback when exporting to a publishing software), my main concern is at the present time with the compile function. Even after using it multiple times, and having read and re-read tutorials, forum threads and the manual, I still struggle with its many and scattered options. I even developped a kind of psychological apprehension at clicking on the compile button because it brings me into an unchartered territory, where one never knows if the result will match one’s expectations. One main reason for this discomfort is that the compile function is not for a daily usage, which means that the learning efforts made the last time it was used will be partially forgotten the next time. This is especially the case with lengthy academic works which do not need a compilation until they are completed.
So here is a suggestion: compilation is not a mere function of Scrivener, like adding a comment or a folder to the binder, it’s a decisive and necessary step of the writing process. Wouldn’t it be more adequate to implement it accordingly, with a full-size window management interface, with a real wysiwyg editor, with more intuitive and visual options, ordered more logically. In a nutshell, I would expect the compile function of Scrivener to be as clear to manage as the writing function of Scrivener. For the present time, it looks more like the compile fonction of a computer code writing software. And a computer code writer I am not…
Thanks for taking this request in consideration.
Hi Manu
Sorry to hear you are struggling with the compile process. The flexibility and power offered by the compile function do necessitate a bit of a leraning curve as you go through all the different functions. It’s worth persevering, though. Once you get comfortable with how the program turns the vast number number of different sources into a single coherent and predictable format it becomes a lot quicker to get some quite clever outputs, and the way the UI is set up - and the “Formatting” pane on the the compile dialogue in particular - allows fast and easy tweaks of settings going forward.
For example, I have a couple of presets set up to suit my own binder structure that produce a pretty good book for printing. If I want to tweak something, eg remove the Chapter Taglines, I just remove the tick from the appropriate checkbox. I don’t need to re-engineer the whole thing each time.
I would also point out that the Formatting Pane, and the “Modify” options within that pane do have their own ‘preview’ windows that give you a very clear idea of what you are including and what it will look like.
My advice would be to jump right in (embrace the fear!) and try out lots of different things in compile. Then figure out exactly what you want your document to look like and it should be a relatively straightforward process to work through methodically and get the results you are after.
I should also add, if you have any specific questions about ways to achieve certain things in compile, a quick post in the tech support bit of the forum usually gets a helpful steer.
The choice, as you put it, is more of a decision based on what is reasonably feasible. Full-blown stylesheet based systems are very complicated to implement, even in a single file, and even more so across dozens or hundreds of them, and that doesn’t even get into the underlying format itself where all of this is saved and recalled. They are also demonstrably unpopular. Those who get them and take the time to learn them do appreciate having that ability, but most people never pick up on them and just go on using the basic font and attribute pull-downs to change the basic appearance of the text, rather than attach meaning with styles. It’s a rather more complicated aspect of word processing. Keep in mind many people still press the Tab key in front of every paragraph instead of using the ruler settings to indent the first line. So while it is an admirable feature, I do wonder just how much of a practical day-to-day problem it solves for most people.
The compile system offers an alternative to the style system in that it defers final appearance for most things you need stylesheets for. In a way, setting up the Formatting pane is like setting up stylesheets. I wouldn’t argue that it is however any more or less complicated than setting up a stylesheet. Like I say, the principle reason for using appearance-only presets is the difference between a massive development effort from interface design all the way down to document format design, and something that affords most people with what they want to do. They just want to make it look right. Presets serve as a way of bundling those decisions into a macro of sorts, making that task easier. I wonder if turning them into full-blown styles would end up causing people to stay away from them and just go back to using pull-downs for everything.
I would argue that the large majority of people do not have to put that much effort into it. The provided presets cover a large territory of what people need to do in professional or academic writing, and where they do not, a post-compilation finale in software more dedicated to the purpose of the appearance of a document is a good way to go about things. Certain texts do struggle with this more than others. Some people are required a great amount of typesetting precision of them, rather than a publishing agency, especially in academia, and this can become compounded when a complex document lacking stylesheets (for the aforementioned reasons) needs them for certain post-compile tasks like assembling an MS Word compatible table of contents.
I would also argue the point there that Word and many other word processors have very adequate tools for converting a style-less document into a styled document via the ability to search for formatting and match styles to them. I think some people try too hard to hit the nail on the head with Scrivener, when in fact what would really be most efficient are very distinctive and utterly non-representative appearances applied to the various elements of the text, to make the task of converting a non-styled document to a styled document easier. Consider if your level-one headers are all red, and your level-two headers are blue and then extend that theory to all of the basic elements of your document. It now becomes much easier to see what is what and how far you’ve got to go in converting the document. I’d bet most documents, even complex ones, only have a shade over a half-dozen variants of basic styles they need. So bulk conversion like this isn’t something that should take long, and the end result would be a document at the level of precision and functionality required for publication.
Well there are two problematic points with that theory:
- It assumes that WYSIWYG is actually a good thing and that controlling it is ultimately intuitive.
Yes, I know, some really do swear by it, and absolutely can’t stand to be writing in anything other than what their laser printer produces. I’m not sure how they got along prior to the '90s, but there is a contingent now that expects that. With Scrivener, you can do this to a degree, and you can turn all of the formatting stuff off in the compiler. You don’t stare at literal pages most likely while writing, but you can get pretty close if that is what you really want. The manual suggests some tweaks for doing so in the section on page view. There are a lot of people though that rather like not having to stare at the end result. They might dislike the fonts they are required to deliver in, or don’t want to look at double-spaced lines all day. So Scrivener gives you that choice. Stylesheets, when properly employed, can give you that choice as well—but like I said before, these systems are often neglected because of their complexity, so I’m not sure if it is a valid alternative in the debate. I’m doubtful that a perfect mechanism could exist that addresses both the need for simplicity (as easy as hitting Cmd-B) and the need for the broad typographic and typesetting ranges required from a system designed to produce publication-ready text. To put it to analogy, there is a large gulf between iMovie and an Avid workstation for that very same reason. I personally think it is a pity that writers are being expected to learn how to use the equivalent of an Avid in the numbers they are these days. They should be the ones handing in the raw video to the editor, not the ones using InDesign and systems like Word—unless they really want to, of course. These are programs that command entire bookshelves of painstakingly detailed literature on how to do this or that. You equate WYSIWYG as being intuitive, and on the surface I would agree the premise of it is, but in practical usage, learning to pilot all of the hundreds of small details that go into that is anything but intuitive. It’s just moving the complexity of the compiler into the text editor, which gets in the way of creative writing, or one just throws their hands up and types and hopes for the best. That is how most use the system you are proposing as easier. They just give up and type. On our side the compiler might make you feel like throwing up your hands and just exporting it. But at least that’s not getting in the way of your inspiration. - The second problem is less philosophical and more just again the matter of technical limitation. I think there is a very good reason for why you don’t see word processors with Scrivener’s breadth of writing support tools. Software must choose a focus, and doing so means some things need to be cut, not only for the sanity of the developer (of which Scrivener for the Mac only has one person doing, incidentally) but the sanity of the users of that software as well. Word is a classic example of a program that has grown too large for the average person to even want to fathom, and I think it’s important to point out that even at that point, it still doesn’t address even the highlights of what a writing platform like Scrivener can give you. To try and fathom a program that can handle a full production and publication environment and a full everything-else-Scrivener-already-does is, well, not even Microsoft, who has no fear of bloat, has taken on a challenge of that magnitude. Perhaps some day it will be plausible, it is folly to try and predict what computers will or will not be able to achieve in time, but it strikes me just as much a conceptual problem as a development problem. There is a very good reason the cockpit of a 767 doesn’t look like the interior of a Ford.
So in summary, I don’t necessarily agree with you in that the systems you are proposing are any better or more intuitive than what you’ve got now. You may not be used to them, but that is something else entirely. Using a word processor may be easy for you because you’ve dedicated a lot of time in learning it, and years of use, but to a person approaching the problem without knowledge of either system (which many people are, even those coming from word processors), I wouldn’t state that a full-blown layout engine is any better than a two-stage system of either an appearance mutator, like Scrivener’s rich text arm is, or a codification translator, like its MultiMarkdown arm is. There is definitely a degree of subjectivity here. What you classify as computer code is to many, easy to learn and intuitive. That isn’t an indictment of intelligence or anything as mundane as that, but rather as I said just a subjective psychological attunement to the system. Some get it in a snap. They look at the Formatting pane, they see how the levels match the icons and the outline structure, and they can go off and make a nice output design based on that. Others have a hard time grasping how all of it fits together. Again, I’m not so much saying the compiler is better than stylesheets, but I would have to point out that it is much the same in the word processor court. For every person that gets stylesheets and can make Word do their bidding, there are others who just can’t, and so they change the font by hand or end up with a mishmash of styles that don’t actually adhere to anything semantic. Neither is really right or better, I would contend; work gets done with or without it.
I suppose my closing argument would be that the compiler is only complicated as you want to make it to be. Yeah, it can do a lot of fancy stuff. It can do things that turn your work into a pretzel if you want. That stuff is incredibly useful if you want to use it and have a need for it, but I think there are alternate ways of doing most things like this, which sure might involve a little more work afterward than clicking a few options and hitting a button, as a compiler guru might be able to do, but are valid alternatives. If all you want to do is change the font, you don’t even have to leave Summary mode for that. If all you want to do is stitch together the pieces you’ve written, as you’ve written them, you can just select “Original” and forget about all of those checkboxes in there. If you need something predictable that a lot of other people need in the profession, chances are there is a preset that will get you almost if not all the way there. If you’d rather exert your knowledge of a word processor to close that gap, it’s encouraged to do so. If you want to become a compiler guru, then more power to you.
Like pigfender, I would advocate that learning the compiler is only to your advantage. As I’ve stressed, you can get by largely without it, but if you can make that 80% document a 97% document and save your five hours in Word, well maybe that’s worth five hours of time to figure it out, especially if you can apply that knowledge in the future. If you routinely publish to a particular style guide, then you can save your settings as a preset and forget about it. Next time you can either just hit that preset and be done with it, and use the time you saved to learn just a little bit more and refine it further.
And yes, do contact us. Support is a big deal for us, we feel it’s an integral part of the software package. The documentation and tutorials are all great starting points, use them, but if you have a specific problem we can probably help, or at the least tell you which parts you should save for after you compile so you don’t have to spend a lot of time trying to do something you couldn’t have even done in the first place.
I would also add that it is impossible to add a WYSIWYG preview for how your text is going to look in anything but the print or PDF options (and even then you’d pretty much need to do a full compile in the background each time you changed a setting to show exactly how it would all look). Scrivener cannot show you exactly how an .epub will look, as it will look different on iBooks and in Adobe Digital Editions; it cannot show how a .mobi file will look, because it will look different depending on the Kindle model you use to open it; it cannot show exactly how a Word document will look, because it will look different in OpenOffice, and besides, Scrivener has no access to Word’s text rendering engine. And so on.