Do you train others in how to use Scrivener?

As Scrivener has become more widely adopted in many fields of writing, we have noticed the increasing emergence of training courses and other learning materials designed by third parties. Some of these are specific to particular fields or genres, while others are more general. None are officially endorsed by Literature and Latte.

Whilst we try to ensure that the interactive tutorial and user manual cover everything that users need to know about Scrivener, and to ensure that Scrivener can be picked up quickly and used progressively, Scrivener’s deep feature-set means that it can be used in many different ways. Third-party courses and books have been springing up to give pointers to users looking for a more personal guide (something we can’t provide at the price we charge for the software), and we are sometimes asked to recommend training courses to customers. In the longer term, we hope to look into the possibility of producing more training materials ourselves, and perhaps working with or endorsing some of the independent trainers and providing them with supplementary materials.

In the meantime, we thought that it might be helpful to add a page to our website, listing external courses (both local and online) which we believe may be of interest to users seeking a different learning approach to supplement the materials that we offer as part of Scrivener and through our various support mechanisms. We’re not sure at this stage how many independent trainers exist, so it may turn out that such a web page is neither necessary nor appropriate, and we can’t make any promises. Inclusion in the list will be entirely at our discretion, and it won’t imply any sort of endorsement by Literature and Latte — it will be intended just as a point of reference for our users.

If you offer training in how to use Scrivener, and if you would like to be added to this potential list on our website, please contact us via the email address: training AT literatureandlatte DOT com so that we can discuss your possible inclusion. We will not be vetting either the course itself or your delivery of it, but we will want to see your course’s content list so that we can understand what areas you cover, and we will review your website and social media to make sure that your portrayal of Scrivener is consistent with ours. We’d want to see how you advertise your training, and to see evidence that you have a body of satisfied users who are prepared to endorse your training course. We would also look at your pricing details, because we try to make Scrivener affordable and want our customers to receive good value for their money. Beyond that, we haven’t decided on the details yet.

So, if you train others in how to use Scrivener, please get in touch.

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!

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.

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 Licensing for Universities & Businesses

Some time ago, I wrote a blog post about ‘Becoming a Sales Affiliate for Scrivener’ http://www.literatureandlatte.com/blog/?p=98. This detailed how you could go about becoming a member of a virtual sales force for Scrivener, earning a 20% commission in the process. This method of getting a little something back as you spread news of Scrivener still exists, but what I wanted to cover today is bulk licence purchasing. This would typically be useful for a business or university.

We are fortunate that Scrivener is being adopted by numerous fields of practice http://www.literatureandlatte.com/whousesscrivener.php, so we’ve tried to automate our web-store as much as possible in order to cater for most purchasing requirements. If you go to our web-store here http://www.getscrivener.com you will notice a Volume Discounts Available link associated with all our Scrivener licence types. If you press the link, you will then be able to see that we offer pricing in discrete bands that depend on the number of licences being purchased in a single transaction. Taking Scrivener 2 for Mac OS X (Regular Licence) as an example, it is typically $45.00 for each licence, but if an institution were to purchase 51 licences then they would only cost $27.00 each.

Going the volume discount route and purchasing licences within a single transaction can obviously lead to a decent saving, but note the institution will only receive a single user name associated with a single serial number covering the number of Scrivener installation seats requested. It is therefore advisable that an institution name is used when going through the purchasing process. If you were purchasing on behalf of Stanford University, for example, using ‘Stanford’ as the ‘User’s First Name:’ and ‘University’ as the ‘User’s Last Name:’ would be advisable. If you were buying a number of licences for a particular department, perhaps the library, then ‘Stanford’ as the ‘User’s First Name:’ and ‘Library’ as the ‘User’s Last Name:’ would probably be a good way to go.

When buying in bulk, note that the number of licences purchased should equal the number of students or employees utilising Scrivener, not simply the number of computers within your organisation. Volume discounts have been tiered to ensure good savings are provided when there are a large number of users. For instance, if more than 250 licences are purchased within a single transaction, then you’ll save 60% on the normal licence rate for Scrivener. If your site or campus is in the order of 500 licences, please contact salesATliteratureandlatteDOTcom to get rates for site licensing.

If employees at a company want personalised licensing for Scrivener, tied to their specific user name, then going the volume discount route is not possible. Licences tied to a single user name need to be purchased separately.

Some institutions may be exempt from sales taxation. As there is no global database available detailing exempt universities or businesses, it is a limitation of the automated system that sales tax, if appropriate, will always be charged in the first instance. If you’re organisation is exempt from taxation, the value can be rebated to your method of payment once you’re in receipt of your STxxxxxxxx order confirmation. The order number is dispatched immediately to the given email address, and if you send this, along with your exemption certificate, to csfileattachmentATdigitalriverDOTcom then the sales tax portion of your order will be rebated to your method of payment.

The easiest methods of payment in our web-store are via credit card or a PayPal account, but if your order value is over $500.00 then the option to complete the transaction using a purchase order will open up. The company that run our web-store (eSellerate) manage the entire purchase order process. E-check (ACH) (U.S. only) and wire transfer are further payment options, with the wire transfer attracting a non-refundable banking fee.

I trust the above information will make the process of cleanly securing a bulk licence order for Scrivener easier to achieve. I hope any institutions that implement Scrivener into their workflows really benefit from the experience.

All the best, David.

The Mac Monochrome Trend – A Plea For Keeping Things Colourful

On Twitter today, someone posted some mock-up screenshots of their ideas for improving Scrivener’s interface:

http://dribbble.com/joostvanderree/projects/42516-Scrivener-UI-concept

(In his own words: “Based on the Scrivener. It’s an app with great functionality for storytellers. UI could be improved in my opinion. This is my approach.”)

Everyone has their own opinion about this or that UI, because visual appeal is entirely subjective. So, I’m not going to dissect these mockups; they are undeniably attractive, he’s clearly a talented UI designer, and it’s flattering that someone would be interested in Scrivener enough to spend time mocking up their own UI ideas. It’s also useful for me, because I get to see a different approach and think about it. I would say that the result isn’t very much like Scrivener, in that it doesn’t convey any of Scrivener’s core concepts beyond the corkboard (and throws in elements that wouldn’t work in Scrivener at all), as the designer himself admitted on Twitter; and, in my humble not-very-designer-y opinion, it also suffers from a problem you often see when a UI is considered purely from an aesthetic perspective with less regard for what the user actually wants to do with the program, in that it allows for very little data on the screen – you wouldn’t be able to get much of an overview of your writing on an 11″ screen with that UI as it stands. These aren’t criticisms of the artist, though – he was clearly just playing with ideas for his own ideal UI, and there are certain aspects of his design that I like. Over all, it looks very pretty and modern, in an iOS kind of way.

As much as I enjoyed looking at these mockups, though, they have reminded me of one thing I dislike greatly in many recent Apple UIs – monochrome icons. I will be striving to keep monochrome icons out of Scrivener for as long as possible. This was a trend introduced in Lion, as part of Lion’s attempt to be more iOS-like. Anyone using Lion will have noticed this trend – you can see it in the Finder, Mail and Preview, among other Apple programs. As of Lion, all the toolbar icons and all of the source list icons in these programs are solid grey – all colour has been drained away.

I’m going to take a wild guess that half of the people who read this will agree with me that the new grey icons are really annoying, and the other half will think, “So what? The new minimalist look is much smarter, less gaudy, and you can still easily tell the icons by the shape.” And I’d agree with the first part: at first glance, these programs do look a little smarter, a little less fussy. Monochrome looks good. The trouble is that, sometimes, making something look more coherent and better as whole can come at the expense of the unique functionality of its components.

As Joni Mitchell sang, you don’t know what you’ve got till its gone (although in all fairness she was talking about trees rather than colours in icons, and I’d concede that trees might be a little more important). When Apple decided to drain the icons in these programs of their colour, I learned something about the way my brain works that I hadn’t hitherto ever had to think about: my brain is an awful lot faster at processing colours than it is at processing shapes. This makes sense – I’ve never been very good with faces, for instance. Whilst I don’t have full-on prosopagnosia, there have been times when I’ve been talking to someone I know only in passing, unsure of whether the person I am speaking to is Bob or Jeff – because both Bob and Jeff wear the same brown corduroy jacket, NHS glasses and brown hair (names changed to protect the Morrissey lookalikes).

It also makes sense, I suppose, that just as some people are colour-blind, some people won’t be as quick at processing shapes in particular contexts. But what this means is that, since installing Lion, I spend a lot more time poring over the sidebar in the Finder and the icons in Mail’s toolbar looking for something I could find at a glance in earlier versions of OS X. I thought I’d get used to it, but I haven’t. Even a year later, I often click on “Get Mail” instead of “New Message” in Mail. In the Finder, I have found that I no longer even look at the icons in the sidebar: because my brain can process the words more quickly than it can the colourless icons, I just read the items in the list instead. The same in Mail – but with multiple email accounts resulting in the same titles in different places, I frequently find myself in the “Sent” list when I meant to be in the “Drafts” list. Before Lion, quickly finding the sidebar folder I wanted in the Finder was easy: I subconsciously found the Downloads folder by looking for a splash of green, the Documents folder by looking for mostly white, the Applications folder for sticks of brown. I didn’t consciously look for a colour: I just looked at the sidebar and my eyes were drawn towards the icon I was looking for. I didn’t know it was the colour that guided my eyes until after the colour had been removed and I found myself having to read the titles.

Yes, this is pretty much the definition of a “first world problem”, but it’s still one we have to think about as we continue to enhance and improve Scrivener and ensure its UI remains modern. And the simple fact is that an icon has a single job: to represent a feature of the program in a simplified pictorial form that can be immediately recognised by the user. How is this achieved? The icon designer has two main tools at his or her disposal: shape and colour. And while we may disagree about what makes an attractive or ugly icon, because aesthetics are very subjective (some users hate the Scrivener application icon, others love it; Ioa hates the tone of green used in the “Add” icon in Scrivener’s toolbar, but the palette is borrowed from iWork and I rather like it), shape and colour are the only information an icon can contain, and it is from that information that we ascertain meaning. An icon succeeds if we can find it quickly when we need it, at only a glance; it fails if we have to compare it carefully to the icons around it to discern its meaning, or if we have to read its title. With only 32×32 pixels to play with for the largest icons, getting this right is difficult enough; I have thus always been baffled by the decision by Apple – renowned, rightly, for its UI expertise – to remove half of the information (i.e. colour) from many of its icons and therefore make them a lot less readable to potentially half of its user base.

I know I’m not the only one to feel this way – I’ve spoken to a couple of other people who find icons difficult to read without colour, too – but are we in the minority? I’d be interested to know if other users have similar problems with these monochrome icons, or whether it is a complete non-issue for most people. Imagine, for instance, that all of the icons in Scrivener’s binder were grey – you’d no longer be able to pick out a PDF file by its red header bar, or the Research folder by its maroon border. I’d find that difficult, and so I’ll be resisting this trend for as long as possible, if only for my own sake. And I would beg Apple and other UI designers not to kill the colour in their icons, and to spare a thought for those of us who are a little shape-blind.

iBooks Author and Scrivener for Mac

Just a few quick notes on iBooks Author, as understandably we’re already receiving questions about the best way of going from Scrivener to Apple’s new e-book publishing tool.

To answer the most obvious question first, I’m afraid it won’t be possible to provide a direct export to iBooks Author, as the .iba format is proprietary and not in the public domain (and Apple hasn’t historically shared its file formats with third parties). At least, not to the best of my knowledge – if Apple did make it public then we’d certainly look at it.

So, for the foreseeable future, that leaves other formats for import and export. When I heard the rumours about an e-book creator being announced at today’s Apple event, I had high hopes that it would open and save .epub files. Unfortunately, despite iBooks Author having WYSIWYG editing and generating files that seem to be at least based on .epub, this isn’t the case. iBooks Author saves to the proprietary .iba format and publishes to the .ibooks format (which seems to be Apple’s version of .epub, much as .rtfd is Apple’s extended version of .rtf; iBooks Author cannot open or import .ibooks files, however). This is perhaps unsurprising, as Apple are obviously only interested in generating content for iBooks (iBooks Author – hmm, the clue might be in the name). What this means for Scrivener users, though, is that you can’t just export an .epub from Scrivener and open that up in iBooks Author.

Currently, the only way of bringing existing text into iBooks Author is by importing Word .doc and .docx files, or Pages .pages files (the latter being another of Apple’s proprietary formats). Moreover, each file you import is treated as a chapter or section – there is at the moment no way in iBooks Author of importing a large text file and splitting it up into chapters after it’s been imported, other than by using copy and paste. (In these regards, iBooks Author feels very much like a 1.0 release – given that it is clearly designed for laying out and producing beautiful e-books, not for creating the content in the first place, we can hope that the import features will improve in future versions.)

For Scrivener users, this means that the best way of getting your work into iBooks Author is to compile to the .docx format, and then drag the resulting file into iBooks Author. You’ll then have to copy and paste the text into different chapters in iBA itself. You could compile each chapter to a separate file, but that would be time consuming.

Scrivener for Mac’s .docx export isn’t, in truth, the best at the moment, as it tends to lose certain formatting and doesn’t support images, which may be a problem for some types of text but shouldn’t cause problems for novels and text-only first drafts (this is because it currently uses the standard OS X exporters, the same ones that are used in TextEdit – Apple uses its own proprietary .docx importers and exporters in its own programs, not the ones provided to third-party developers in the Cocoa frameworks). The good news is that I am currently working on better .doc, .docx and .odt support, so this situation should be improved in the next update. We’re also thinking about what better ways we can provide of going from Scrivener to iBooks Author – for instance, by generating different .docx files for each chapter – given that I’m sure that many users are going to want to do this after they’ve hammered out their text in Scrivener.

Please bear in mind that I have only had as long as anyone else to play with iBooks Author, so the above is all just based on a couple of hours of testing. Over all, iBooks Author looks very nice, and once we find the best workflow for getting your Scrivener text into it, then I’m sure it will be a great way of taking your Scrivener drafts and turning them into beautiful e-books on iBooks.

Scrivener for iPad and iPhone in Development

We’ve been dropping hints for a while, but can finally make an official announcement: Scrivener for iOS is now in development.

I’ve said all along that I wouldn’t develop an iOS version myself, any more than I would have tried to code the Windows version myself – with such a small team, I think it’s in the customers’ interests to have a dedicated developer for each platform to ensure that each version is always kept up-to-date, and my hands are full with the Mac version. To that end, I’m very pleased to announce that we have just signed contracts with a developer, Jen Yates, to develop the iOS versions for us. Jen has been beavering away in secret for two or three months now, putting together some proof-of-concepts:

Scrivener for iPad's corkboard

I have to say that moving index cards around on a touch screen is a lot of fun, and the corkboard implementation she has come up with is, I think, one of the nicest I’ve seen on a touch screen device in terms of selection and dragging.

It’s still early days, though – we are about to embark on the design process proper, and all we can say in terms of a release date is that our iPad and iPhone versions will be out some time in 2012. If you would like to share your own ideas about what you see as essential in an iPad or iPhone version, please feel free to drop by our special sub-forum for iOS suggestions here:

http://www.literatureandlatte.com/forum/viewforum.php?f=36

Thanks to everyone who has contacted us to show their enthusiasm for an iOS version of some kind – we hope you’ll like what we come up with – and welcome to Team L&L, Jen!

EDIT 17/12/11: Thanks for all the enthusiastic responses to this post, much appreciated. To those asking about an Android version, this is on our radar too, don’t worry. We have to take it one step at a time, though. Our design process for iOS will take Android into consideration (although our iOS version will be Cocoa and native), and we hope to investigate Android in more detail later in 2012.