How Do You Use Scrivener

We’re running a quick survey to find out how our customers are using Scrivener. This information will help us plan and prioritise new features, and to work out how to reach potential new users of Scrivener in the future. It should only take a few seconds to fill in, and we’ll be very grateful to anyone taking part:

https://www.surveymonkey.com/s/T7R2X3P

Thanks!

Customer Support closed for the festive break

If you have looked at our support web page this week, or read Keith’s message in the forum and the festive newsletter, you will have seen that our Customer Support is closed over the Christmas and New Year period.  Although we may get a chance to check emails occasionally during the holiday, we will do our best to reply to all e-mails as soon as possible after we get back in January.  If you have an urgent problem involving data loss, or a major issue that is time-critical, there is a link on our support page at http://www.literatureandlatte.com/support.php that will enable you to submit an urgent message.  We can’t promise a response in any particular timeframe, but we will try to prioritise genuinely urgent messages.

In the meantime, our Knowledge Base contains the answers to many of the questions that we are asked most frequently, and you can find this here: https://scrivener.tenderapp.com/help/kb.  Our user forum is also a very useful source of information, and you may find that the wonderful community of knowledgeable (and generous) users can help even if we are not around: http://www.literatureandlatte.com/forum.

If you do need to contact Customer Support, now seems as good a time as any to give an overview of how our support system works, so that you know what to expect when you send us an email, and how to make sure that your enquiry is answered as effectively as possible.

Where to send your message


To make sure that your message is seen promptly, please choose the most appropriate email address from those shown on our contacts page at http://www.literatureandlatte.com/contact.php. We have separate email addresses for Scrivener for Windows, Scrivener for Mac, Scapple, sales or purchasing, and general enquiries.

If you send your message to the wrong support address, don’t worry — we will move it so that the right people see it.  But please don’t send your message to more than one address, especially if you are doing so from multiple email accounts (which are hard for us to trace and link up on our system).  We will generally reply to only one of the duplicate messages anyway.  We are a very small team of people, and sorting out duplicates takes up valuable time that could be spent in helping customers.  And if you send duplicates, there is a risk that our support system may incorrectly identify your correspondence as spam.

Asking a new question


It’s best if you start a fresh email conversation for each new topic that you wish to discuss, especially if some time has elapsed since any previous contact.  It’s possible that the support person with whom you were communicating before might not be the most appropriate person to deal with your new enquiry, or that they might be out of the office.

How can you tell if we have received your message?


When you send us an email, you will know that it has been received, and is therefore in the queue for us to handle, because our support system will send you an automated message in reply.  As well as letting you know that your email has reached us, the confirmation email contains a link to your new ticket in our support system.  You will be sent an email reply from one of our support team in due course, but the web interface is an alternative which you may find useful, and it also allows you to log in to view any historic tickets that you may have.

If you do not receive this emailed auto-response, then check that you have “white-listed” the domains literatureandlatte.com and tenderapp.com in your email client, and that the message hasn’t been diverted to your spam folder, promotions folder or any other folder into which your email provider may sort messages without your specific intervention.  If the auto-response goes astray in your email system, then our actual response is likely to do the same.

Please remember that if you contact us for help or information, then it is up to you to ensure that your system is set up to receive our reply.  Disable any spam-avoidance system that might auto-respond by challenging us to prove that we are real people or demanding that we jump through hoops.  We are indeed real people, and we cannot spend time following up these requests.

How to avoid languishing in our spam folder 


If you have sent your message to several of our email addresses, or if your email address has been hijacked and sent us spam mail at some point, or if your message falls foul of the junk filter in some way, then there is a risk that our automated systems will interpret it as spam.  We do go through the spam folder manually to rescue wrongly-filed messages, but (as you can imagine) we get a lot of junk email, so it’s possible that we might not recognise every valid message that ends up there.  Our support system shows the initial two or three lines as a preview, with fifty such emails displayed per page.  Messages are therefore most likely to be rescued from the spam folder if they have an informative subject title, and if the opening lines of text seem relevant to a support enquiry or to a communication that is intended for us specifically.

How long does a response take?


In general, apart from the current arrangements for the Yuletide holiday, we try to respond to messages within (typically) 48 hours.  Please bear in mind that this is our target response time.  We may be quicker than this, or it may take us a little longer if the weekend intervenes, or if the nature of your enquiry means that we need to discuss it internally or seek more detailed technical advice before we get back to you.

How to recognise our responses


We use a web-based support system called Tender, and the email address that you will see in the “From” field will look a little unlikely, so don’t misinterpret it as spam! You will see the first name of the person replying, but the actual email address will start with “tender2+” followed by a long string of letters and digits.  This alarmingly complicated-looking email address links to the specific conversation stored in our support system, so that all relevant messages are kept together.

Helping towards a prompt reply


The best way of ensuring a prompt reply is to make sure that you have sent your email to the correct address, and that you have included all the information relevant to resolving your question or problem.  Please be as specific as possible in describing what is going wrong, because otherwise we will probably have no way of knowing what you mean, so our initial response to you will have to be a variant of “tell me more”.

If you haven’t heard back from us after receiving the automated response from our system, please don’t try to nudge a faster response by replying to your own message at a later date, unless you wish to add further information that will aid resolution.  If your message reached us, then doing this has the opposite effect to what you want to achieve, and will (unfortunately) delay a response further.  This is because support tickets are organised in our system according to the date and time of the most recent activity on the conversation.  If you add a reply, it places a later date stamp on your support ticket, which moves that ticket further back in the queue if we are trying to handle support tickets in chronological order of receipt.

Don’t forget your backups!


And finally, a note about backups, because we often find that people don’t know about Scrivener’s automatic backups, or that they forget about them in the panic arising from a syncing error or computer failure.  If you’re not sure about your current settings for these, I’d recommend checking them now, to make sure that they match your needs and the way in which you use the application.  You can find the settings in the Backup pane under Tools > Options… (on Windows) or Scrivener > Preferences… (on Mac).

If you have experienced data loss of some description, the very first thing you should do is copy your automatic backups to a safe location, in a separate working area of your disk, so that you can retrieve an older copy of your work if necessary.  You can read about restoring backups in section 7.8.4 of the user manual (available via Help > Scrivener Manual).  By default, Scrivener creates an automatic backup for you when you close your project, but only the most recent backups are retained.  Each time a new automatic backup is created, an old one is knocked off the list.  So if you carry on creating automatic backups of a damaged project, then you risk overwriting all of your good backups with bad ones.  Copying your backups to a safe and separate location before you try any other problem-solving measures will ensure that you have the best chance of retrieving your data.  And if your current project is damaged, you can tell Scrivener not to create any more automatic backups of it by using File > Back Up > Exclude From Automatic Backups.

Remember, as well, that you may have backups kept independently of Scrivener, for example via Time Machine in Mac OS X, or in the file versioning system in some versions of Microsoft Windows.  Creating backups that are stored externally (such as on an external disk or in cloud storage) is something that you will need to set up yourself, but it is worth doing, for your own peace of mind.


With best wishes for 2015


 

Novel-in-a-Day

For anyone hoping they’ll get their book finished by this time next year, the concept of writing an entire Novel-in-a-Day is enough to prompt a swift lie-down in a darkened room. But on October 25th this year, that’s exactly what a bunch of L&L staff and forum members did – one novel, one day. Finished. Complete.

Of course, it’s not as insane as I’ve made it sound. Or quite as heroic – though it is still one heck of an achievement. Created back in 2011 by L&L forum regular Pigfender – known better in the outside world as Rog, Novel-in-a-Day (NiaD) is a yearly challenge to writers to do exactly what it says in the title. Each participant takes charge of a chapter of a book, writes like a demon, then submits the results to Rog who puts the whole lot together (using Scrivener, of course!) to create possibly the world’s fastest-ever completed novel.

This furious writing extravaganza is open to everyone, whether you’ve been published before or not, and takes place every October – though if you’re new to NiaD and haven’t posted on the L&L forums much before, you’ll need to send in something such as a blog post to prove you’re serious and can write to the required standard.

All the ideas behind the chapters and novels are Rog’s own, which is rather awe-inspiring for someone like me who has been trying to come up with a half decent idea for years now, and without much success. But that’s the beauty of NiaD – being handed the freedom to write without the usual panic over whether the foundations you’re basing your book on are in fact made of jelly.

The basic process goes like this: just after midnight on NiaD day (that’s CST – Cornwall Standard Time, otherwise known as UK time), all participants are emailed a brief description of where their character should start – for example, this year, mine consisted of two East End thugs sitting at the wheel of their van – a brief description of what needs to be covered, and where the chapter should end – again, in my case this was back in the van, but with two intelligence officers tied up in the rear. This gave plenty of scope for anything to happen in between, as long as at some point it involved a kidnapping. You’re also sent a character sheet or sheets, possibly some location details, and there also may or may not be some information about what has happened beforehand, depending on the need for continuity and/ or Rog’s whims.

This is another great part of the process – the mystery. Until the final book is published, nobody knows what happens in the story outside their chapter, or where this fits into the narrative. I didn’t have any information about what had gone before, which convinced me I was writing the opening chapter. Actually, it turned out to be chapter 15. As long as you follow the brief, it doesn’t matter what you write – for the first time, this year there were enough participants to run two novels simultaneously, so I could compare my chapter to my counterpart Chanel Blake’s contribution to see where we’d taken things. Two identical briefs equalled two completely different chapters for two totally different novels.

You don’t have to be too much of a master of speed – each chapter needs to be a minimum of around 1,500 words long, and it’s the quality that counts rather than the quantity. This year, mine turned in at 2400 words, though past submissions have stretched to 5,000 words. How that author found the time to write all that in a day I’ll never know. Everything has to be in at 8pm to give Rog a chance to provide any continuity feedback and start compiling the books – but if you’re really pressed, then the absolute deadline is a minute to midnight (it’s a Novel-in-a-Day, remember).

All the sections are designed to be fun to write – so you won’t get stuck with a compulsory detailed description of the inside of a recycling plant (though if that’s your thing and it could conceivably fit the brief then feel free…). You can also amuse yourself, procrastinate hugely, or fish for ideas by hanging out on L&L’s NiaD forum with the rest of the usual reprobates.

In all, it’s a bit stressful but great fun. Personally, by taking the huge obstacle of actually finding a decent plot away, it actually gave me the chance to just sit down and write. I didn’t know where the story had been, but I knew where it was going, and who was taking it there – if you really are an adrenaline addict, it’s a great warm-up for NaNoWriMo, too.

If you are curious but aren’t sure if you have the nerve, Rog has put together a great Q&A, designed to counter all your arguments against taking part (or something along those lines):

http://literatureandlatte.com/forum/viewtopic.php?f=51&t=28574&start=0#p181923

There’s also a growing library of the previous years’ attempts available for browsing: http://literatureandlatte.com/forum/viewtopic.php?f=51&t=28582

And there might even be a t-shirt:

http://literatureandlatte.com/forum/viewtopic.php?f=51&t=29041&start=90#p187789

The forum post inviting writers to sign up usually goes live in August, and as we love the event and want everyone else to join in too, we’ll be making much more of a song and dance about it next year on our site, Facebook, Twitter and so forth, and expanding the number of books being written so that all those interested in joining in can find a place on a team. It’s also possible that we could run more than one story at the same time, provided there were enough people in the background to support this – though that would mean they’d have to step out of writing that year. Rog’s aim is to be able to accommodate entire writing groups or schools within a single novel, and to be able to produce non-English language versions of the books at some point. In short, the event has a lot of potential, and we’re all working hard to see where we can get it for 2015.

Anyway, if this has convinced you that you’d like to write a chapter next year, keep an eye out for more news around that time – and roll on next October. Here’s hoping to see some of you there…

Unexpectedly Catching Up with the GamerGate Controversy

I learned two new “G” words last night: GamerGate and Gawker. Perhaps I’ve been living under a rock, but until about 8pm yesterday evening, I’d heard of neither of them. Then, suddenly, according to the Twittersphere, we had come out in support of GamerGate – which was news to all of us. I’d therefore like to set the record straight.

First, as I understand it, what has been claimed is this: that we have withdrawn advertising from Gawker following pressure from GamerGate. It would, in fact, be impossible for us to withdraw advertising from Gawker, because we have never knowingly advertised through Gawker in the first place; we have never had any form of relationship with Gawker. Not that this was a conscious avoidance – Gawker just wasn’t something that was even on our cultural radar. We do very little advertising, as it very rarely has much effect for us. Back in the summer, we did run a promotion with StackSocial, who pushed Scrivener through social media and various sites, and from what I understand, we appeared briefly on Gawker through that promotion (although we never saw the advertisement ourselves, and Gawker wasn’t on the list of sites StackSocial advertises with).

Following that, we received a number of emails from apparently concerned Scrivener users, expressing disappointment at our involvement with Gawker, and providing numerous links purporting to show Gawker as an evil, sexist and bullying entity. (It turns out that these emails may not have been from Scrivener users, as I have since learned that GamerGate supporters routinely send these exact same emails to many companies.) This is where we went wrong. The person who responded to those emails (actually two people responded to the emails, but using the same reply as written by one person), having never heard of GamerGate or Gawker either, was somewhat naive in his reply. He thought he was merely reassuring an upset user that we wouldn’t knowingly get involved with companies with bad reputations for bullying or sexism. (If we ever receive a complaint from a user about a company we have been associated with, we always take it seriously as we do our utmost to work only with ethical and like-minded companies.) Unfortunately, then, he wrote his reply without knowing anything about GamerGate and without actually researching the allegations about Gawker, and also over-stepped the mark a little in his reassurances. He certainly had no idea that he was unwittingly stepping into the GamerGate controversy.

Below is his stock reply that was sent to those who wrote to us complaining about our apparent association with Gawker (to put it in context, all of the emails we received contained multiple links pertaining to Gawker, and claims about large and reputable companies dropping support of that site). This is the reply that was posted on social media by GamerGate as though we were coming out in support of them:

GamerGate Email

Our reply was ill-informed, since we knew nothing about Gawker Media beyond what the person writing to us had told us, and the person who wrote the above email should not have said that we’d be saying no to any further marketing approaches from StackSocial since no such decision had ever been made among the directors of L&L. (And, just for the record, I have no opinion on Gawker either way, as it’s not a site I’ve ever looked at or read. My wife looked at it briefly last night and was less than impressed, but that’s about the sum total of L&L’s knowledge of the site.) What the reply should have said is that we would look into their allegations before pursuing future marketing promotions, which is what we would do with any such complaint.

So, just to be very, very clear: we are not affiliated with GamerGate in any way, nor have we endorsed the movement. Nor have we withdrawn any advertising because of pressure from the GamerGate community, since there was nothing for us to withdraw anyway. We have simply been drawn into something of which we were entirely oblivious because of the over-zealous reassurances of a member of our staff to what he thought was a concerned user.

Our official statement, a version of which was sent to The Verge and which was also posted on Reddit last night, is as follows:


Literature & Latte is most certainly not aligned with GamerGate in any way, and we have been somewhat caught off-guard. To be honest, I hadn’t even heard of GamerGate until all of this happened. We have, unfortunately, been rather naive. We received several emails complaining about our involvement in promoting Scrivener through a particular company of which GamerGate disapproves. We were entirely unaware of GamerGate and its associations, and the emails we received provided links purporting to prove sexist and bullying behaviour on the part of said company. As our company is – naturally – against bullying and sexism of all kinds, the person on our team who responded to those emails said that we would refuse further marketing approaches, unfortunately before researching the matter further and without consulting other members of the team. That is the entire extent of our involvement. We have not withdrawn any advertising from anywhere, as there was no advertising in place to withdraw. Had our member of staff been aware of GamerGate and the harassment with which it has become associated, our response would have been much more circumspect. We were certainly most surprised to see our reply to what we thought was a genuinely concerned user posted on social media as if we were endorsing GamerGate – we were not.

Literature and Latte is committed to equal opportunities (our company itself comprises an equal number of men and women across all positions on the team). Bullying and harassment, whether online or off, is abhorrent and Literature & Latte does not tolerate such behaviour in any form.

We would like to apologise unreservedly for any offence we have caused in our naive and un-researched responses and the way they have been represented.


In addition to that official response, I will also say this: bullying and harassment, whether sexist, homophobic, racist or anything else, is never, ever acceptable or justifiable, wherever and however it occurs, and the effect it has on its victims is hideous. I’ve seen some of it first-hand. Julia, my wife and fellow director at L&L, is also a journalist, and some of the online comments I have seen about one of her articles in particular were absolutely disgusting and sickening, of a kind that would never be posted about a man. I’d like my daughters (and son) to grow up in a better world than that, and I have absolutely no time whatsoever for anyone on any side of any movement involved in the harassment of women or of anyone else.

Yosemite Updates

Yosemite is nearly upon us – the rumour is that Apple will release OS X 10.10 today, announcing it at their iPad event. Yosemite is a major upgrade to OS X, introducing a number of significant UI changes. (Sadly, it is not without its share of bugs at this stage.) Accordingly, we have just released Scrivener 2.6 for Mac, which adds support for Yosemite, fixing all known compatibility issues and updating several UI elements to better fit with the look of the new OS. We have also released Scapple 1.2 for Mac, which likewise addresses all known Yosemite compatibility issues.

Users who purchased from us directly can either update via the “Check for Updates” feature in the application menu, or re-download and re-install from our site. We’re sorry to say that Mac App Store users will have to wait a little longer for the updates – we have submitted the updated versions to Apple but they are still waiting for review. We had hoped they would have got through the review process by now, but presumably Apple has a backlog with many apps receiving updates for Yosemite.

There is one remaining known compatibility issue between Scrivener 2.6 and Yosemite: the Facebook and Twitter services integration in Scrivener (which allow you, for instance, to tweet your current word count progress) no longer work on OS X 10.10. This is because Apple has changed these services so that they no longer support 32-bit apps, and Scrivener is currently 32-bit. I brought this to Apple’s attention during Yosemite’s beta-testing period, but its engineers informed me that they had no intention of fixing it, meaning that only 64-bit apps can use these features moving forwards. Unfortunately, it’s not possible for us to update Scrivener 2.x to become a 64-bit app, because, owing to the frameworks it uses for features such as media file viewing, such a move would break backwards-compatibility with older versions of OS X.

I really like Yosemite’s new interface, and am happy to see Apple turning its attention to the Mac once more and giving it a facelift. (Let’s ignore the garish blue folders in the Finder – a number of developers asked Apple to fix that, but someone at Apple must like eye-bleeding colours.) Upon updating to Yosemite and acclimatising to the greatly-refreshed interface, however, some users might be forgiven for thinking that Scrivener’s interface isn’t yet fully adapted to its new environment (its binder is still blue rather than translucent, for instance). This is because we have so far focussed on functionality, ensuring that everything is working correctly, only updating the UI where problems arose. The changes in Yosemite are extensive, and the differences in its UI are only the tip of the iceberg – under the surface, in the Cocoa frameworks, almost everything has been modernised. This is an exciting time for Mac apps, but rather than try to rush through the changes, we have decided to take the time to get them right.

So, the good news is that, behind the scenes, we haven’t been slacking off – we’ve been quietly laying the foundations for development on the next phase of Scrivener – on both platforms. On the Mac, that means converting the codebase to be 64-bit compatible and to use all modern Cocoa and Objective-C conventions (and to be Swift-compatible – Swift being Apple’s brand new development language). It also means overhauling the interface to better fit in with Yosemite design aesthetics. On Windows, it means rewriting the way certain features work, such as scrivenings and outliner mode, to be more akin to the Mac, and catching up with Mac features while the codebase refresh take place in the Mac version. There’s a long road ahead, and we’ll bring more solid news of this next phase for Scrivener when things are much further along. Right now, though, Scrivener 2.6 is here and Yosemite-ready. Our iOS version is progressing, too, and we’ll be releasing updates for both the Mac and Windows versions of Scrivener next year to provide iOS sync functionality.

Just watch your eyes on those blue folders.

Collaborative Novel Prep for the NaNoWriMo Rebel

We’ve just entered autumn here in the northern hemisphere. To celebrate the changing seasons, the fiery landscape, the woodsmoke scenting the crisp air, I thought I would make this month’s post a simple (yet subtly complex and insightful) haiku.

Then I remembered I can’t write poetry worth fairy gold. Also, my autumn kicked off with unceasing rain, fog, and general unpoetical greyness. So instead I will regale you with the mostly-true tale of another autumnal event: writing a novel in a month!

My three best NaNoWriMo novels have three things in common: They were all meticulously outlined, collaborative, and written in Scrivener. Coincidence?

Yeah, possibly, but I’m going to blog about it anyway.

Although NaNoWriMo officially frowns on collaboration, NaNo Rebels have a special home in the forums, and I have no shame. My partner in crime and I churned out over 50K words apiece all three Novembers, and if alone we each only had half a book–well, 50K is only half a book anyway. Together, we had a complete beginning-to-end novel that included a middle thick with subplots. I won’t say the writing or plotting was staggering genius (I try to be humble) but it made a beautiful first draft ready to be ripped to pieces and redone. A definite NaNo win.

To make it work, we needed to be able to write at any time. We both had crammed schedules, and as we all know you can’t turn on creativity like a faucet. Sharing a single Scrivener project thus wasn’t a viable option, since we’d be too likely to run into conflicts. We also needed to have the novel planned enough that we could write without waiting on the other person’s instalment. But though we didn’t want to wait for each other’s scenes, we did want to see them. Purely from a desire to encourage, inspire, and applaud, you understand. Neither of us harbours a competitive bone in our body.

Not having had the foresight to write our collaborative NaNos while still housemates, my partner in crime and I turned to good old-fashioned email and instant messaging to plot the novel. The plan was to break down the novel scene by scene and split the total between us. We’d been tossing ideas around for a while, so we had a pretty good idea of the general shape of the story. Building it into a concrete, coherent outline was something else altogether, but November’s loom lightened the process. It’s difficult to be too perfectionist about a novel you’re going to bang out in a month.

Our handful of point-of-view characters divided the scenes among themselves without much bickering. We each took a few characters, and the count came out surprisingly even. I won’t speak to how well-balanced the scenes were, but it hardly mattered for NaNo. I can stretch the word count of anything, and my partner in crime writes fast. In the event, I foisted three scenes off on her and we ended happy.

Because I’d been the one insisting we use Scrivener (I wasn’t working for L&L at the time, so I was allowed to badger people like that), I took charge of creating the project. Into this went our research, emails, notes, and painstakingly crafted MorphThing character mugshots. (Procrastination: Never start NaNo without it!) Our outline became synopses of 781 Draft documents, labelled by point of view and assigned “author” custom meta-data.

I used the author data to build a collection of all my scenes and another of all my co-author’s. Once we forked the project so we could each work in our own copy, we set our collection as the compile group. That let us track our month’s word count independently in Project Targets and compile for the validation servers without cheating.

We shared our work during the month using Scrivener for Mac’s “Sync with External Folder” feature.2

External Folder Sync settings

This lets you keep text documents in your project in sync with an external copy saved in a designated folder. The external files can be edited in any word processor supporting the RTF format (most do) and changes will be synced back into the Scrivener project. Combined with a file sharing service like Dropbox, this is a great way to work with a colleague who isn’t using Scrivener.

Of course, we both were using Scrivener, so we had to get creative.

Let me take a step back at this juncture and clarify a point. Scrivener’s sync feature is not intended to share documents between projects, even copies of the same project. Attempting to do so is singularly inadvisable and will almost certainly result in corrupting both the projects you’re trying to sync, which in turn will result in tears, gnashing of teeth, tearing of hair, and great consumption of chocolate and/or alcohol.

Most of that is not conducive to writing.

Instead, we created two shared Dropbox folders, one for each of our projects, and limited the projects to syncing only a specific collection of documents. My project synced my scenes to Folder A but not my co-author’s. Her project synced her scenes, but not mine, to Folder B.

Both projects synced the research documents. Since these weren’t set apart for only one of us to edit, there was the potential we’d both update our own copies during the month and end with vastly different versions. Syncing the documents for both projects wouldn’t cause conflicts, because the Dropbox copies were entirely separate, but would alert us to any changes our co-author made. Then we could update our own project to keep the documents uniform.

To control whether a document was in the dynamic sync collection, we used Scrivener’s “status” meta-data. We replaced the default revision-state settings (“to do”, “first draft”, etc.) with two options: “private” or “shared”. All documents marked “shared” were automatically collected into the saved search and thus automatically syncing. In the meta-data settings we also made “private” the default status for new documents, so we could easily create personal notes that wouldn’t sync. If we did want to share the new document, just toggling its status added it to the sync collection.

Status meta-data settings

Any time my co-author synced her copy of the Scrivener project, all her updated scenes appeared magically in my Dropbox and a notification popped up. I immediately dropped whatever I was doing and ran to read all the updated documents. It’s possible my partner in crime displayed more discipline using the updates from my syncs as motivation to meet her word count before reading.

When so moved, we copied and pasted the scenes into their slots in the Scrivener project. (Since our projects weren’t syncing our co-author’s scenes, this didn’t create chaos with extra copies.) Because I am highly skilled in putting off writing, I usually found an excuse to do this with every sync. Dumping the other person’s text into our own copies of the project filled the gaps between our assigned scenes. We could see the novel growing as a whole. In Scrivenings mode, we could see how astoundingly well we’d transitioned blindly from one scene to the next, or how well I’d managed to drag out one person’s dialogue to the length of one of my co-author’s entire scenes.

Collaborating brought another benefit: instant positive feedback. Positive as a rule. No one wants immediate critiques on a draft written sometime past midnight in a caffeine and sugar haze. Under normal circumstances, I doubt anyone wants to read that draft. But a trusty collaborator in the NaNoWriMo trenches is uniquely positioned to provide encouraging words, humorous asides, and unexceptional notes to research those magical FTL particles later but carry on with them for now.

Before commenting on a scene, we checked via chat to make sure it wasn’t currently being edited. If my partner in crime synced at the beginning of her writing session and I started annotating the same scene in Dropbox, we’d end up overwriting one or the other in the next sync. Scrivener takes snapshots of updated documents as part of the process, but merging the changes takes time. NaNo’s gruelling pace leaves no room for such slipshoddery. So we’d wait for the all-clear, then comment to our heart’s content. The next sync pulled the marked-up copy into the original author’s project and she could fortify herself with crackpot comments before launching into the day’s word count.

We won NaNoWriMo this way with every book of our trilogy, clocking in around 70K words apiece each November. Starting in January we’d spend eight months tearing apart and reassembling the completed draft (usually with wholly new pieces). In October we outlined the next book and started the cycle over. My partner in crime zipped her project and dumped it in Dropbox. I made sure all her files were up to date in the master, trashed old snapshots, and handled the other housekeeping. A new copy went back out and we were set for another month of wild writing.

Project example

Now we’re out of first drafts for NaNo, but our project is still going strong. The expanded custom meta-data has transformed the outliner into a multi-coloured spreadsheet of subplots. Our comments are occasionally more pertinent (or impertinent). We attack each other’s scenes with red text. We write, sync, repeat.

When our book hits the shelves, I’ll let you know. Meanwhile, November’s just around the corner. You’ve got a novel to write.

 


1 Hush, it was NaNoWriMo. The count dropped in revision.

2 Although Windows doesn’t have this specific feature, you can mimic it using File > Export > Files… and saving to a shared Dropbox. The only difference is that changes made externally won’t be automatically pulled back into the project, but as you’ll see, our method uses copy and paste regularly anyway. A side benefit is that both projects can export files into the same Dropbox folder, whereas syncing requires a unique folder for each project. You just need to be careful to use unique names when exporting research documents–perhaps append your initial to the title directly in the project, to avoid accidentally overwriting the other person’s version.

The Vapour Trail of Scrivener for iOS

We’re over halfway through 2014, so I wanted to give our users a quick update on the progress of the iOS version of Scrivener. We receive emails and forum posts daily asking how it is coming along, and because of how long it seems to have been in development, we’ve even had users assume that it has been abandoned (we’ve even been accused of lying about it being developed at all, but I promise that’s not the case, even if we have continually underestimated the time involved).

The short version – the “tl;dr” version as the cool kids say – is that we still expect it to be finished this year, but now very much doubt it will be released until next year (2015) because of the amount of testing we need to put it through before letting it loose on the world. Don’t misunderstand – we are closing in on the final stages of development right now. But these final stages can still take a while, and I’d rather tell users now, in the middle of August, that we might be pushing into 2015, rather than keep my fingers crossed that we can squeeze it into 2014 and then only announce a delay at the last minute when we realise we aren’t going to make our target. Thorough testing of the iOS version is crucial, because it is designed to sync with desktop projects, and syncing can be a dangerous process – we want to ensure that any bugs that could cause data loss or corruption are truly ironed out before putting it into users’ hands.

I’m aware – if only because we’ve had it pointed out a lot! – that we have been saying “later this year”, then “next year” for two years now. Naturally, users wonder how so many delays can be possible. For a start, there’s a fairly obvious rule of software development: software development takes time (and developing good software takes a good amount of time). And then there’s the corollary to this rule: software programmers always underestimate how much time it will take (myself included).

Take the sync code, for example. Most iOS apps can take quite a simple approach to sync, using the built-in features that Apple provides for iCloud. Or they can use the Dropbox API to manage uploads and downloads. Nothing is so simple for Scrivener. One of Scrivener’s main features is that it allows you to bring in research files – photos, PDF files and so on – so that you can view them next to your text and keep everything together in a single project. In order to achieve this, Scrivener requires a file format quite different from most writing software. Scrivener, in fact, is something of a hybrid between a document-based program and a shoebox app.

Most writing software packages are document-based programs. A document-based program allows you to create, open and save documents, showing different documents in different windows. They use single, flat files that contain all the text and any graphical data for each document. These files are loaded entirely into memory when opened, and written out in their entirety as completely new files when saved.

A “shoebox app”, in contrast, usually has a single window that allows you to interact with many different files, opening them inside the one window. There will be a single folder on disk storing all of these files, but you usually won’t touch that folder at all. iTunes and iPhoto are examples of shoebox apps.

Scrivener is a bit of both. As a user, you interact with your Scrivener projects as though they were documents – each project is opened in a different window, and you have a .scriv file on disk for each project. But those .scriv files are really folders containing many different files – they are not flat files at all – and you navigate between them in the project window via the binder. This means that Scrivener doesn’t have to read these files entirely into memory on opening them, or save the whole file when saving. This is very important for projects that have a lot of research in them – you don’t want Scrivener storing a gigabyte of PDF files in memory while you are typing, or having to write all of this data to disk every time auto-save kicks in. This file format allows Scrivener to load into memory only the data that the user needs for a particular session, and it only ever needs to save what has changed (which also reduces the chances of catastrophic data loss caused by file system save errors).

The only downside to this file format is that whenever Apple introduces new technologies – Versions, iCloud, Handoff – it only provides out-of-the-box support for simple document-based apps. All of which to say: we have had to put together, from scratch, our own syncing solution so that our iOS version syncs with our desktop version. (We will use the Dropbox API, and hopefully other syncing APIs as time goes on, but all the conflict resolution handling has to be done by us.) Over the past couple of years, we’ve spent a great deal of time discussing how this could work, hashing out various ideas and solutions that could deal with the conflicts that will inevitably arise if someone works on both the iOS and desktop versions while offline so that the changes become out-of-sync. (Everything has to be considered: what happens if the user edits scene A on the mobile version but then also edits it on the desktop before there has been a chance for them to sync? What if the user’s kid opens up the app on the iPad and hammers away at their precious novel? How can we tell the difference between a scene that’s been deleted from one device and one that’s been added on another? And so on.)

Once most of this had finally been hashed out, it then took me a month to write out the design document that covers how the code will work (a design document is necessary for our Windows team to follow as well as for me and our iOS developer). And then yet another month to write the code itself, cross-platform for Mac and iOS (our Windows team will need to write this code separately). This has been what I’ve been doing for the past couple of months, and there is still work to do on getting all the sync components that have been written into place on the Mac and on iOS and then thoroughly tested (then testing on Windows).

So, that’s between three and four months on a single (but integral) feature. (And while I’ve been doing this, Tammy, our iOS developer, has been adding various “smaller” features that had to wait until late in development – printing, basic compiling, import and export, statistics, split and merge, find and replace… The sort of features that it’s easy for users to forget when suggesting that Scrivener for iOS should just be simple and only have the basics, but without which, Scrivener for iOS would feel crippled. And even some of these smaller features can take a couple of weeks each to implement, of course.)

The trouble is that it’s not only non-programmers who (understandably) don’t appreciate how long seemingly simple things can take to code – we do it ourselves. We’ll often think that a feature will only take us a day or two to complete, then find ourselves growling at the screen, desperate to have done with it, two weeks later. (This is no doubt why software and games are so notorious for being delayed throughout the industry.)

In a program as complex as Scrivener (even on iOS it requires a degree of internal complexity if it is to work with the desktop version), where various features can take a month or more to implement, the time creeps up on you and suddenly two years have passed… There are certainly programs out there that can be written in three or four months, but sadly, Scrivener isn’t one of them.

Not that “development takes time” is the whole picture. Something like Scrivener can easily take a couple of years to develop properly, but it has now been two and a half years since we started work on it; we had hoped it would be finished by now as much as anyone else – we don’t enjoy frustrating those of our users who write on mobile devices. The other big factor for us has been scaling up. Scrivener started out as a hobby – the software I wanted for my own writing. I wanted it so much that I taught myself how to code in order to create it. For the first couple of years, L&L was a one-man operation, and we are still a very small team. I work alone on the Mac version, two programmers work as a discrete unit on the Windows version, we have a couple of other full-time team members who write and maintain the manual and tutorials and handle all QC testing and some support, and we have a couple of part-time support staff. We have no central offices but are scattered across the world (the UK, US, Australia and Bulgaria). None of which is unusual for shareware, “artisan” software such as Scrivener.

The wonders of the information age make it easy for geographically-scattered teams to stay in constant touch and work together, but as a small company with such a setup, it meant that it was not possible for us just to hire some programmers and stand over them until the iOS version was finished. I was always adamant that I would not write the iOS version myself, because I’ve seen too much Mac software suffer as its developer has spent all his or her time working on iOS, and that would have been unfair to our existing user base. (Moreover, the Mac version is where I live for my own writing, and Scrivener is always going to be predominantly a desktop program.) So it was key to find someone self-motivated, with a good understanding of Scrivener, who could develop Scrivener for iOS and keep on developing it into the future, beyond version 1.0.

As I announced last year, unfortunately our first developer had to step away from the project because of family health issues, which had also stalled development progress throughout the eighteen months she had been working on it. We were very fortunate to find Tammy Coron, an experienced iOS developer and Scrivener user, to take over development. When she took over, she made the painful decision to rewrite much of the existing code, in part because of new technologies that had been introduced with iOS 7.0 (a rich text system at last!). Which means that while our iOS version has been in various stages of development since the end of 2011, the form it is in now has only been in development for just over a year.

We are really looking forward to releasing the iOS version – in many ways it’s become the proverbial albatross around our necks.* But it is getting there, and we hope the subsection of Scrivener users who are eager for an iOS version will be patient for a little while longer. We are genuinely grateful for your enthusiasm. I’m not known for great reserves of patience myself, so I do understand the frustration of some users who are more vocal in their eagerness, but to those I would say, please do try to remember that we want to get our iOS version into your hands as much as you want it. We’re a tiny company but we have put a lot of energy and resources into the iOS version (and for all we know it could be a loss-making venture), and we think Scrivener users will be happy with the final product.

I’ll post later in the year more on what sort of features to expect, but suffice to say that it has full rich text editing, a corkboard, an outliner, an inspector and, on the iPad version, the ability to view research alongside your text as you type. It is, essentially, Scrivener on iOS.

P.S. For anyone interested, I’ve uploaded a sort of developer diary for the iOS version here:

A Scrivener for iOS Developer Diary

If nothing else, it should show at least that the iOS version has been in continual development, hitting snags along the way, even if progress has seemed glacial to the outside world.

[*] “Way I remember it, albatross was a ship’s good luck, ’til some idiot killed it. Yes, I’ve read a poem. Try not to faint.”

Scrivener 1.7 for Windows Now Available

Hello Scrivener Users,

Nine months ago we decided to lay the groundwork for the biggest free feature update for the Windows version of Scrivener to date. We had an ambitious goal to bring as many of the features you’ve been asking for over the years as we could, all the while going through piles of existing code, refining and optimising along the way. It has been a long haul, but we are finally ready to make this available to all current Scrivener users on Windows. We hope you find the new version to be as much of an improvement to your writing projects as we have.

Special thanks go out to all of those beta testers that helped make this release as solid as it could be. We really appreciate the help!

Here are just a few of the things you can expect to see after you update:

Formatting Presets
If your writing calls for a lot of formatting, then you know that in the past it has been difficult to keep a consistent look without using a lot of settings. You can now save formatting into presets, making it easy to apply that same format over and over to different parts of your text. Additionally, we’ve added a feature that will make it easier to compile special formatting while also taking advantage of the compiler’s unique and powerful features for cleaning up your draft. Check out Preserve Formatting and Formatting Presets.

Special note: if you’ve customised your Format Bar, you’ll need to add the new preset button yourself, using the Tools menu.

Custom Meta-Data
Have you ever found yourself wishing you could track even more details in your projects? We’ve got an answer for you. It is now possible to add as many meta-data fields to your project as you wish. These can be displayed as columns in the outliner, or easily accessed in the Inspector sidebar. Keep track of dates, characters, names of flowers, who dunnit in the drawing room with the candlestick, and other matters of dire importance.

Custom Icons
Spruce up your binder with a broad selection of useful icons (or add your own). Nothing says fix me now! like a big yellow caution icon on the chapter you’ve been putting off. Or give yourself a gold star when you finish a scene. Sometimes it’s the little things.

Document Templates
They are kind of like project templates, but for documents in your projects instead. Set up boilerplate texts or even whole folder and file structures for easy duplication. It’s like adding new types of items to your Add menus, such as character sheets, references, to-do lists, or whatever else you can imagine.

Binder Favourites
There are some things we just keep coming back to. Now you can add those things to all of the main navigation and selection menus (such as the Move, Scrivener Link and Go To menus), giving you top-shelf access to these, no matter how buried they may be in your outline.

Multiple Project Notes
Open your project notes in a separate window, and create new notepads as tabs in this window to better organise your thoughts. You’ll still have access to all of them in the Inspector sidebar as well. No more lumping everything in one place!

PDF Display
This one has been a long time coming. We’ve completely replaced the PDF engine in Scrivener with a much improved system for both reading and exporting PDFs. Copy selections of text, or even whole pages at once with a simple right-click. You can also quickly navigate within larger PDFs that have a built-in table of contents, or by clicking on internal links.

Better Web Import
By default, websites will now be converted to PDF using the new engine. The result will faithfully preserve most websites into a stable format that will stand the test of time. We’ve also introduced support for Microsoft’s MHT website archive format. Although Scrivener cannot view MHT files (yet, don’t worry, it’s coming), you can easily open them in compliant browsers with a click of a button. If all you want is a selected piece of a page, you’ll find that copy and paste now works even better with most modern browsers.

Compile Support for Scrivener Links
It might sound arcane, but the ability to link from one piece of your draft to another has important implications: It means you can now cross-reference in a format that will be more useful for your readers, and it also means you can create a table of contents directly in your RTF files. We’ve included a special tool for easily creating a ToC. If you have MS Office installed, links are also supported for the PDF, DOC and DOCX formats.

All Project Templates and Compile Presets Updated
We’ve gone through every project template and compile preset to update them with the new capabilities in this release. You’ll find many more options in the compiler’s Format As menu, and project templates will come outfitted with convenient document templates, among other improvements.

There’s a lot more! If you want to review the full list of changes, please review the official change log.

Special Update Notice

We have identified an issue with the automatic updater that may cause it to fail on some configurations. If this happens to you, don’t panic, all is well! Just head on over to our main website and download the regular installer.

Once that is downloaded, you can run it against your current installation to upgrade it seamlessly. It is safe to run this .exe file without uninstalling first. As with all software updates, your work will not be disturbed.

This update is recommended for all users. You may use the Help menu to check for updates, and let the automatic updater run. However if you are running behind a proxy, would like to set aside a copy of the installer for safekeeping or have problems using the updater, you can always download a copy of the full installer using the link above.

Best wishes,
Ioa Petra’ka
(Documentation; Support; Design)

An Update on the iOS Version of Scrivener

Given the number of tweets and messages we get enquiring after the progress of our iOS version (thank you everyone for your enthusiasm!), I wanted to give everyone a quick update, since there have been some important developments recently.

As many of you know, development started on Scrivener for iPad and iPhone early in 2012, and we had hoped that we would have it ready for the end of that year; we later revised that estimate to the first quarter of 2013. And, as many of you have pointed out to us, here we are in April – so where is it?

 

 

I’ll provide the information you are most likely after first: it will still be a little while–certainly much longer than we had hoped. We can give no firm release date yet, and given that past estimates have been wildly off, I’m not even going to make a guess at this stage. We very much hope it will be out this year, in time for National Novel Writing Month, but we’re not going to make any promises at all until we know for absolutely sure that we can keep them.

The frustrating part for us is that, for the past four or five months, we have had a version of Scrivener for iPad that is in many ways so nearly there and yet still not ready for beta-testing. We hit snags with the rich text system (or iOS’s lack of one) and building the synchronisation code is incredibly complicated because of Scrivener’s package-based file format, but we had most of the other basics in place and felt we were really making good progress.

 

 

Unfortunately, however, owing to unforeseen and serious health problems in our iOS developer’s immediate family, over the past few months our original developer has been unable to spend the time on the project that is required to get past the final roadblocks and finish it. It’s been a difficult time for everyone as we tried to work out the best way to proceed, all the while hoping things would get back to normal even as time slipped by, especially since she has done such an amazing job so far (the iOS versions of the binder and corkboard are a joy to work with). It gradually became clear, sadly, that our iOS developer had no choice but to officially reduce the time she could dedicate to the project so that she could concentrate on her family, and that we would need to find someone else to step in. But because we’re a small company with limited resources and no headquarters or offices, it’s not as though we could just throw money at the problem by hiring a bunch of developers and supervising them until it is done; we’re not Microsoft, Apple, or even Omni. We needed to find another iOS developer not just passionate about coding, but passionate about creating an iOS version of Scrivener in particular.

 

It is with great pleasure and some degree of relief, then, that I can now announce that we have found a new developer to focus on getting Scrivener for iOS completed. (The original developer will continue to work on it too, as much as her current circumstances allow.) The new developer is Tammy Coron, an experienced iOS coder who is also involved with Nickelfish and developed the iMore app. She’s a dedicated Scrivener user and, like many of our users, is desperate to have the iOS version for herself. (It’s not just our users eager for this–I want to be using the iPhone version as soon as possible too.) There’s an interview with Tammy available online for anyone interested here:

http://www.imore.com/debug-10-tammy-coron-nickelfish

Tammy can also be found on Twitter @Paradox927 (which is the same user name she uses on our own forums).

Tammy has been getting up to speed with the project for the past fortnight and has now started diving into the code proper. We hope to provide more news over the coming months, but we’re all excited to have her on board and to once again be forging ahead with getting our iOS app completed.

 

 

To those desperate to have an iOS version as soon as possible, we are very sorry for the delay, but remember that in the meantime Scrivener for Mac already has some great ways of working with mobile devices (e.g. via external folder sync). We know we’ll get a bunch of angry emails and tweets over this, but I hope that most of our users continue to find Scrivener one of the best desktop writing packages around, and that the iOS version will be worth the wait when it is eventually in everyone’s hands. We also hope that everyone will understand why we haven’t wanted to say too much about what has been holding up development until we really had to and had already got a solution in place.

 

Scrivener Temporarily Withdrawn from MAS – UPDATE: Scrivener is available again

UPDATE 20/03/13: Scrivener is now back up for sale on the Mac App Store, and runs fine on 10.6.8. Thanks to all our Mac App Store users who have been very understanding about the issues we faced.

— ORIGINAL POST —

Scrivener has been temporarily removed from sale on the Mac App Store. We are very sorry for any inconvenience this will cause to our Mac App Store users, but unfortunately we have been left with little choice other than to take this measure. I’d like to stress that this is only a temporary measure and we hope that Scrivener will be available on the Mac App Store again within the next few days. (Note: As I write this, you may still see Scrivener available – we’ve pulled it, but it will take up to 24 hours before it disappears from all stores.)

The reason we have taken this action is that the current version available in the Mac App Store, Scrivener 2.4, will not install or run on OS X 10.6 and Apple will not allow us to release a bug-fix for this problem in a timely manner. This 10.6 problem is due to a bug in the receipt validation code that crept into this release – please see a full explanation in my blog post of two days ago:

http://www.literatureandlatte.com/blog/?p=340

2.4 was released on the App Store last Thursday night, after a week in the review queue. On Friday morning, as soon as I found out about the bug in 10.6’s receipt validation code, I submitted a bug fix, Scrivener 2.4.1, to Apple, and I asked for an expedited review. With this all in place, we had hoped that Scrivener 2.4.1 would be available to our Mac App Store users by Tuesday at the very latest, so that our 10.6 MAS users were not inconvenienced for more than a few days at the most. (There is no way to upload an immediate bug-fix to the Mac App Store – every update has to go through the review process, and even when an expedited review is granted, it can still take a while.)

Unfortunately, this has not been the case. It is nearly a week now since 2.4 became available, and we still do not know when 2.4.1 will pass review and be made available on the store. 2.4.1 was rejected on Monday night for a reason that didn’t make sense (the reviewer said it wasn’t sandboxed when it was). We followed this up and resubmitted, but were then told that the reviewers needed more time. Yesterday, I was informed that they want us to make some changes to Scrivener 2.4.1 before it can pass review. I was also informed that Scrivener 2.4, 2.3.1 and 2.3 should really have not passed review either, given the things they want us to change. (Please note that the things we have been asked to change are not bugs, but features Apple interpret as not meeting their App Store review requirements.) I asked if we could roll back to making an earlier version of Scrivener available on the store while we address these issues, but the only way to do that, apparently, is to resubmit the older version, but because the older versions have the same “issues”, then doing so wouldn’t help as the reviewers would reject the older version that had previously passed review anyway. In other words, we currently have no way to get a bug-fix to our 10.6 MAS users other than to keep going back and forth with Apple until they pass 2.4.1 for release. Nor is there any way to prevent 2.4 from being available to 10.6 users.

We can therefore not in good conscience continue to sell Scrivener on the Mac App Store knowing that any 10.6 users who buy it will not be able to use it.

As soon as 2.4.1, which fixes the problem, passes review, we will immediately make Scrivener available on the Mac App Store again. We very much hope that this will be in the next few days.

Again, I’d like to say sorry to any of our Mac App Store users that this will inconvenience. We will not leave you without a working version of Scrivener, though. If you are a Mac App Store user and this temporary removal of Scrivener from the store leaves you without a working version of Scrivener, please contact us. If you are on OS X 10.6 and bought Scrivener in the past week so that it will not run on your system, again, please contact us – we will get you up and running. Email us at mac.support@literatureandlatte.com with these issues. Thank you for patience and understanding in this matter.

(Incidentally, because of some of the changes we are being required to make, we cannot guarantee that Scrivener on the Mac App Store will have as good support for .docx, .doc and .odt formats in 2.4.1 and future releases. This does not affect the version on our site.)