About a Button

This is one of my favourite buttons in Scrivener:

It sits in the footer bar below the outliner and corkboard, and it has sat there for several years now. Maybe you use it all the time; maybe you’ve never noticed it; maybe you’ve clicked on it and wondered what it’s for. It’s called the “Selection Affects Other Editor” button, and that’s exactly what it does.

Here’s how it works:

  1. Split the editor so that you have two editor panes open.

  2. Load the corkboard or outliner in one of the editors (usually the top or left one if you work in a left-to-right language).

  3. Click on this button at the bottom of the corkboard or outliner so that the arrows turns blue.

Now, whenever you click on an index card in the corkboard, or on a row in the outliner, the document it represents gets opened in the other editor. Thus, you can use the corkboard or outliner to navigate instead of (or as well as) the binder.

In this way, Scrivener’s two editors can operate independently, or they can be linked so that one is used to navigate the other. It’s a feature I use all the time (I like being able to navigate from the outline, where I can see all my synopses), and it’s a feature that’s going to become even more useful in the future. It’s also a feature that, although it might at first appear trivial, had a deep influence on how we approached navigation in the iPad version. (But more on that soon.)

A Quick iOS Update

We have a lot of people asking after the iOS version given that I haven’t posted much about it on here recently (although I have been giving incremental updates over on the forums). The lack of updates isn’t intended as a slight against our very valued users; it’s just because we’ve had our heads buried in code and haven’t been coming up much for air.

The good news is that our iOS version is (at last!) feature-complete and is currently in internal beta-testing. We’re in the process of smoothing out the rough edges we find through use and fixing bugs before we make it available to our wider beta-testing group. Having taken so long to get to this stage (we know), we don’t want to fall at the last hurdle and rush beta-testing. After all, the sync code is complex (it was a three-month job in itself) and we want to ensure it’s never going to cause any data-loss in the real world (it is holding up well in testing so far, though). Once it’s out with our wider beta-testing group, I’ll start posting some screenshots and showing off the features. Given past debacles, I’m hesitant to talk about release dates, but we expect a summer release, though whether mid or late summer will depend on what is thrown up during beta-testing, of course.

To answer some common questions we’ve had about the iOS version:

  1. Version 1.0 will sync with the desktop version using Dropbox. The sync code has two components, the Dropbox-specific code, and the code that handles merging all the changed files between platforms and dealing with conflicts. This second part of the code has been designed for reuse with other sync clients, so we plan on adding support for sync solutions other than Dropbox post-1.0 (Cubby is one that has been requested several times, for instance).

  2. There is no iCloud syncing in 1.0 because iCloud does not work well with package-based file formats such as Scrivener’s. We were hoping that iCloud Drive would provide a solution, and are still looking into it, but the APIs don’t seem to provide the flexibility we need on the iOS side. (The reason syncing is more complex with Scrivener than for most apps is because .scriv files are really folders, which is how we can allow you to import any sort of research file and only load files into memory as they are viewed in the app.)

  3. You can also transfer projects simply using iTunes, of course.

  4. When the iOS version is released, there will be simultaneous updates for both Scrivener for Mac and Windows that provide sync features. So don’t worry, Windows users, we have no plans of leaving you unable to sync!

  5. Version 1.0 will not have any dedicated screenwriting features, but scriptwriters will be able to sync their scripts using Fountain syntax for paragraphs.

  6. Scrivener for iOS is a full-featured writing environment – the binder, corkboard, outliner, full rich text editing (with comments, internal links and so on), import, export, reference to other documents (including images, PDFs, media files) – all the core features of the desktop version are there in the iOS version, but with a UI designed from the ground up for mobile devices.

  7. Scrivener will require iOS 7.0 or above.


It’s been a long journey, but at last the light at the end of that proverbial tunnel is in sight. I can’t wait to start showing you screenshots and talking about it properly.

It’s not all about the iOS version, however: our heads have been buried deep in code working on serious and extensive (and exciting) updates for our existing platforms, too. But we’re not yet ready to talk about those, and we want to get the iOS version out first.

EDIT: We’ve had a lot of users ask about how to get involved in beta-testing the iOS version (thank you!). In the past, the way we have always selected beta-testers has been to look out for users on the forums and social media pages who know their way around Scrivener, are good at reporting bugs or giving constructive feedback, or who post useful information on using Scrivener for fellow users. We continue to look out for new beta testers that way, and from that, we already have quite a large pool of testers for the Mac and Windows versions to whom we’ll be sending out iOS beta invites to begin with. Once we’ve got a better idea of what the numbers are like, and when the time comes, I’ll post more information here on how to apply to become a beta-tester for anyone else interested. Please note that it’s not a good idea to apply to beta test if you just want early access, though – the beta-testing stage is where we find the most bugs, so you have to be prepared for crashes and even possible data-loss (obviously we hope to have ironed out data-loss bugs by the beta, but beta-testing is where users find the things we’ve missed and we cannot guarantee that there won’t be hideous bugs lurking – beta-testers are guinea pigs). Beta-testers also have to be prepared to spend time trouble-shooting and providing us with detailed reports on every issue they find. We’ll provide more details once we’re nearing the end of internal testing.

Site Licensing

We’re always trying to make it easier for institutions, along with individuals, to adopt Scrivener into their writing workflow. To this end, making it more readily available to larger organisations, we wrote a blog post back in November 2012 that covers the process of obtaining Scrivener licensing for universities and businesses http://www.literatureandlatte.com/blog/?p=329. It details the steps involved and options available when using our direct web-store http://www.getscrivener.com, and provides information about securing volume discounts. It also mentions site and campus licensing for institutions requiring 500 or more Scrivener licences.

A number of institutions have been good enough to contact us over the years requesting pricing, and we thought we’d mention a couple with site licensing. The first place of learning that wanted to utilise Scrivener in their curriculum was Korea International School (KIS) back in 2009. They have a Mac 1:1 laptop program for their students (Scrivener is also available for Windows users) and wanted to use Scrivener in their language classes. The children were even good enough to produce a YouTube video showing Scrivener in action at KIS:

A prestigious site to which we’re very happy to be providing Scrivener over the next 4 years is the University of Cambridge. This is a massive institution, steeped in history from 1209, with an incredible academic record and alumni that includes the names Charles Darwin and Isaac Newton! The site is somewhat bigger than it used to be in the 13th century and now includes over 6,000 academic staff, more than 3,000 administrative staff, and well over 18,000 students. All those involved with the University of Cambridge now have access to Scrivener, and we naturally hope they take full advantage of the application when wrestling with their papers and theses.

If you’d like to use Scrivener within your business — maybe you work for a law firm http://www.literatureandlatte.com/casestudies.php?show=david_sparks, or you’d like your students or peers to benefit from Scrivener’s organisational and research gathering benefits — do not hesitate in contacting us at sales@literatureandlatte.com regarding site licensing. Alternatively, go directly to our online store here http://www.getscrivener.com to obtain licensing for a single user, or up to hundreds. Many thanks.

All the best, David.

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.”