Edit Mac Scrivener 3 With iOS Ulysses, Part 1: Prepping Your Brain (Changing Your Scrivener Habits) #amwriting

Scrivener and Ulysses CAN get along

So you’re frustrated by iOS Scrivener’s limitations compared to Mac Scrivener 3, and by its old-fashioned (by iOS standards) interface. You may or may not loathe Dropbox, but you’re definitely frustrated by iOS Scrivener’s “stop everything” sync. You look at iOS Ulysses with its slick interface and wonder why you can’t just use it to edit your Scrivener project. After all, you don’t get full-up Scrivener on iOS, anyway…

Well, dear reader, you can! You can have Scrivener and Ulysses sync with either an iCloud Drive-based sync, or a Dropbox-based sync. But—it involves changing the way you use Scrivener, and effort to adapt your existing Scrivener projects. (Sadly, Mac Scrivener itself will need a “stop everything” sync, but you won’t have to start it and it will go by fast.) Still interested? Read on.

What do you mean, “prepping your brain”?

You’re going to learn to work with Scrivener projects in Scrivener while keeping (eventual) editing with iOS Ulysses in mind. No matter how much you do in Ulysses, there will be a lot that you still need to do in Scrivener; Scrivener has far more robust organising tools, and Scrivener’s compiler provides customisable output not possible from Ulysses.

You’ll need a new attitude towards using Scrivener if using iOS Ulysses as editor is to work well for you. You’ll have to mentally “forget about” certain Scrivener features that cause a lot of friction going back and forth with Ulysses. In some cases, you can add these back after you’ve finished your first draft and have moved on to working with beta readers, editors, professors, publishers, etc. Others features will leave your project forever.

This may be your workflow if:

  • You much prefer Markdown-style editing to Rich Text (WYSIWYG) editing. If you love Scrivener organisation tools (Corkboard! Outliner! Scrivenings!) or Scrivener’s output flexibility, but hate its editor, this may be the workflow you’re looking for.
  • Dropbox gives you hives. If you’d much rather have your project on iCloud Drive than Dropbox, yet be able to edit on iOS without copying the project, this may be the workflow you’re looking for.
  • You do most of your work in simple prose. Maybe you use a bulleted list of your acknowledgements in the back pages, or a table of… something in your preface, with a modest title page and an illustration or 3 and that’s about it. If most of your work is straightforward prose, and you like it that way, this may be the workflow you’re looking for.

This workflow may not be for you if:

  • You’re not going to use Scrivener’s compiler. If you’re not compiling for final output in Scrivener, this workflow may not be for you.
  • You use elaborate list formatting inside Scrivener documents. If you need anything more than web-style bulleted or numbered lists, you may need to adjust them in your compiled output. If this won’t suit, this workflow may not be for you.
  • You use anything but the simplest tables inside Scrivener. Only very simple tables typed in as text in MultiMarkdown format will work well. If you need fancier tables, you may need to adjust them in your compiled output. If this won’t suit, this workflow may not be for you.
  • You need Inspector comments and footnotes (show up in the right-hand column) as opposed to inline annotations and footnotes (placed in the midst of the text itself). If you absolutely need Inspector comments or Inspector footnotes while drafting, this workflow may not be for you.
  • You use Scrivener styles. A lot. Every use of a Scrivener style is a friction point with Ulysses. If you can’t use Markdown instead, your use of styles is widespread, and you’re not willing to consider doing without some of this formatting, this workflow may not be for you.
  • You don’t want to learn or use Markdown and some features of MultiMarkdown. You will need to type Markdown formatting in by hand in Scrivener. If you don’t want to fuss with (Multi)Markdown, this workflow may not be for you.
What this guide won’t do:

I won’t give detailed directions for every single step—or this would be novel-length! Instead I’ll refer you to the Scrivener, Ulysses, or Markdown documentation.

Suggested Scrivener Work Habits when planning on using iOS Ulysses

All of these are habits that will either let your project compile smoothly with the “Convert MultiMarkdown to Rich Text” compile option on,1 make the round trip from Ulysses with less formatting loss, or both.

In general, avoid using non-Markdown formatting as much as practical. The less you have, the less you’ll need to reapply after you edit with Ulysses.

  • Learn Markdown, and how to use MultiMarkdown tables. Visit CommonMark if you don’t know any Markdown—their ten-minute interactive tutorial rocks. Read Fletcher Penney’s MultiMarkdown tables documentation. Scrivener will not help you with this. Ulysses will help with Markdown, but with MultiMarkdown tables, you’re on your own.
  • Get rid of any body or “normal” style. It will cause a lot of friction with Ulysses. (For why, see 1.1.1 below.) Most of your Scrivener work should be in unstyled text. For how to get rid of a body text style, see this post on the Scrivener forum: https://www.literatureandlatte.com/forum/viewtopic.php?p=316480#p316480
  • Change your default formatting (“no style”) in Scrivener to block paragraph style—no paragraph indent, and no spacing between paragraphs. Use an extra return to space paragraphs apart. (For why, see 2.1 below. The exceptions are Markdown lists, code blocks, and MMD tables.) To change your default formatting for current and future documents in your project, see this thread on the Scrivener forum: https://www.literatureandlatte.com/forum/viewtopic.php?f=2&t=62229
  • Don’t bother with making text italic or bold; use _surrounding underscores_ for italics and **surrounding double asterisks** for bold. Use Markdown links for any external link you need. Use Markdown image insertions. (For why, see 1.1.1 and 2.2 below)
  • Use Scrivener-style internal links. As these show up in Ulysses as plain text with no link evident, you may want to use an inline annotation to mark them as links.
  • Use Markdown lists and MultiMarkdown tables if you need any. (For why, see several items below.)
  • Use Scrivener inline annotations and footnotes if you need comments or footnotes. Avoid Inspector comments and Inspector footnotes.(For why, see 1.5 and 2.10 below.)
  • You may need a few styles for things like blockquotes, attributions, centred text, etc. I suggest using an inline annotation in each styled paragraph noting the name of the style.
  • If there are non-Markdown character attributes you need (highlighting, etc.), again you’ll have to use Scrivener styles. Using an inline annotation to tag each paragraph containing these will help you out later.
  • Make the styles you do use obvious in Scrivener. Figure that you’re going to need to reapply them occasionally. If you never use coloured text even for links, give your character attribute styles a text colour. If you never use highlighting in your final output, give them a background tint. You can deliberately strip those attributes in compile, but the colour or tint will show up in the automatic snapshots that Sync to External Folder takes. Thus, it will be easier to spot and reapply those styles. Even for pure paragraph styles, tagging styled text with an inline annotation will make life easier.

Conclusion

To sync your project with Ulysses smoothly, you’ll need to use Markdown and MultiMarkdown features within Scrivener text documents instead of many of the native Scrivener features. This way of working quickly becomes a habit, but it isn’t for everyone.

Appendix: What Happens in the Scrivener ↔︎ Ulysses round-trip—and in MMD→RTF compile

  1. Ulysses round trip effects:
    1. Any paragraph that you edit with Ulysses will
      1. Lose its formatting. Italics, bold, underline, and other character attributes will disappear from Scrivener. Indeed, any change from Scrivener’s default style (font, font size, alignment, etc.) will be erased.
      2. Lose Scrivener styles. Any style you truly need will have to be reapplied.
      3. Have Inspector comments and Inspector footnotes (linked notation) stripped out.
    2. Scrivener-style lists will show up as code blocks inside Ulysses, with only one level of indentation. If you edit them, your list formatting will be lost for the items you edit. (see above.)
    3. Scrivener-style tables will just show up in Ulysses as a series of paragraphs. Once again, the table’s formatting will be damaged if you edit its cells in Ulysses.
    4. Scrivener-style image insertions and external links are invisible inside Ulysses. If you edit their paragraphs, they disappear (see above).
    5. Scrivener ((inline annotations)) and {{inline footnotes}} do show up in double parentheses and double braces, respectively, in Ulysses. You can add new comments and new footnotes by enclosing comments in (()) and footnotes in {{}}.
    6. Scrivener internal links look like plain text. MMD-style internal links are ignored.
    7. MMD tables in Ulysses will look like plain text with some vertical bars thrown in, just as they do in Scrivener. You can edit them just the same as you would in Scrivener.
  2. MMD→RTF compile effects:
    When compiling a document in Scrivener with this option on, first the MMD→RTF translation is done, then styles (if any) are applied, and finally the compile layout formatting is done. In practical terms,

    1. Paragraphs separated by only one “enter” are compressed. You must type “Enter” twice between paragraphs in order for the Scrivener MMD processor to recognise them. The exceptions are Markdown lists, code blocks, and MMD tables.
    2. Non-Markdown character formatting is stripped. Underlines, highlighting, strike-through and more will vanish in the compile. If you absolutely need any of these in your output, you’ll need to use styles for them.
    3. “Inline” Markdown definitely comes through. Italics, bold, external links, and images all end up in the compiled output if they are designated in Markdown in the text.
    4. Markdown lists and MMD tables appear in the compiled output as well.
    5. Scrivener lists show up as a series of paragraphs with hand-bulleting or numbering. Indents are lost.
    6. Scrivener tables appear in the compiled output as a single massive collapsed paragraph. No “table-ness” survives.
    7. Markdown and MMD “blocks” in general do not pass through compile intact. They are wiped out by the section layouts unless they are styled. This includes both code blocks and blockquotes.
    8. On the other hand, code blocks surrounding Scrivener styles are absolutely essential to retaining things like intra-paragraph tabs during compile. Without code blocks, tabs don’t survive the MMD→RTF process long enough to be styled.
    9. Strangely enough, MMD-style footnotes have formatting problems.
    10. Scrivener-style external links disappear.
    11. Scrivener inline annotations and inline footnotes work just fine.
    12. Scrivener-style internal links compile just fine.
    13. Compile ignores Dividers (four hyphens).

  1. You can get by without using this compile option, but at the cost of having to do much more “fixing” of your edited files in Scrivener when you get them back from Ulysses. In my opinion, it’s not worth it. 

Beyond iOS Scrivener 1.2.1 #amwriting

Back in December, I wrote that I hardly use iOS Scrivener any more, and that remains true.

I’ve had a lot of time on my hands, lately, what with my coworking venue going out of business, and all the coffeehouses being closed (at least for purposes of sitting and writing for long periods.) The time I spent commuting had to go somewhere, and when I wasn’t too depressed to do anything except play video games, I found myself niggling at The iOS Scrivener Problem. (Yes, I know, I could have been productively writing. Still…)

Abandoning Scrivener totally is out of the question for me. I use the Scrivenings view constantly on my Mac, as well as stacked corkboards, the Outliner view, keywords, custom metadata… ad infinitum. (About the only features of Scrivener I don’t use are document notes, scriptwriting, and research. Oh, and the various LaTeX workflows.) I also use Aeon Timeline, and while theoretically I could use AT with Ulysses, I’ve got Scrivener all set up with it.

Ulysses… hmm. What about using Ulysses as an iOS editor for Scrivener projects? I can’t access many of my Mac Scrivener features in iOS Scrivener anyway. I already know and pay for Ulysses (I write this blog on it.) Ulysses has as slick an iOS-style interface as any app going. Any metadata I need to refer to (synopses, keywords, etc.) is available on iOS via Aeon Timeline. My research is already available on iOS via Evernote. I can even edit metadata in AT if I need to and sync it up to my Scrivener project on my Mac.

I’m no stranger to using non-Scrivener editors on iOS. In the Bad Old Days before iOS Scrivener, I used both the Index Card app and the Editorial app to edit my Scrivener projects, using Scrivener’s External Folder Sync feature. It was harder to describe than it was to do.

It’s taken me some experimentation. Scrivener 3 is more complex than Scrivener 2 so there are more pitfalls on the Scrivener side. Also, Ulysses is more complex than either of my old two iOS apps, though that turns out to be all to the good.

Nonetheless, I’ll be posting my new Mac Scrivener 3 <=> iOS Ulysses editing workflow in a series of several blog posts:

  1. Translating Between Scrivener 3 and Ulysses: Ulysses speaks Markdown. Scrivener speaks Rich Text. Rich text has a lot more formatting flexibility than Markdown. This means modifying some things in your Scrivener project, and avoiding certain Scrivener features. I’ll cover what you’ll need to do to your Scrivener manuscript to prepare it to work smoothly with Ulysses’s Markdown. WARNING: You may not be willing to live with these limitations. In that case, this isn’t the workflow you’re looking for.
  2. Setting Up Sync: I’ll reveal the nitty gritty of using either iCloud or Dropbox (dealer’s choice) to sync between Mac Scrivener 3 and iOS Ulysses. I’ll provide detailed sync settings for each app.
  3. Avoiding The Editing “Gotchas”: I’ll tell you how to sidestep the “OMG no!!!” moments, or at least face them with confidence.
  4. Compiling Your Project: I’ll describe the modifications you’ll need to make to your Scrivener compile formats to output your Ulysses-savvy manuscript.
  5. But What If I Don’t Want To Use Aeon Timeline?: I’ll go over some strategies for getting at least some of your metadata into Ulysses. Note that these methods are minimally, if at all, automated. If you update the metadata in Ulysses, you, and you alone, will be responsible for updating said metadata in your Scrivener project by hand. Be told.

iOS Scrivener Two and a Half Years On #amwriting

The truth: I hardly use iOS Scrivener any more.

It’s just too limited compared to Mac Scrivener (or even Windows Scrivener). I can never see the aspects of my project that I really want to see. There’s no Scrivenings mode. There are no collections. The Corkboard only ever shows one level of one folder. Keywords and custom metadata are missing.

It goes on. I self-publish, and the facilities to produce a manuscript that’s ready to upload to Amazon and Smashwords just aren’t there. The iOS Scrivener compiler has few features compared to Mac or Windows.

As for research, I don’t use Scrivener at all for that. I use Evernote instead. It’s much easier to find what I need there, and I can display Evernote on a second screen on Mac. On the rare occasions when I use iOS Scrivener these days, I can split the screen between Scrivener and Evernote. I really don’t like my research crammed into the same app as my manuscript. (N.B.: This is Scrivener heresy. One of its heavy selling points is keeping research and manuscript together. I’ve tried it. Every third project, it seems, I try it again just to see if it works better than Evernote. The answer has always been no so far.)

So iOS Scrivener doesn’t work well for me for either planning or publishing. Its lack of easily configurable overview makes it less than ideal for drafting. The only time I find myself using it is when I want to jump start my actual word production for the day by using handwriting recognition. But since I found a workaround to use handwriting recognition with my Mac, I don’t even use iOS Scrivener for that any more.

It’s not a bad app, iOS Scrivener. I like it. If Mac Scrivener didn’t exist, or if I had only an iPad, it would be my writing app. But as I have a lovely tiny Macbook Air 11, I just don’t use it.

Bummer.

iOS Scrivener Sync Altermatives, Part 1: iCloud Drive #amwriting

Many Scrivener users want iOS sync to work via iCloud Drive. Desperately. I hear from users on the Literature and Latte forums that they’re keeping their working Mac/iOS projects in iCloud Drive with no apparent problem.

Don’t do it! I also hear users who lose all their writing this way. It’ll work fine—until it doesn’t. Because of Scrivener’s unique “hidden multiple files” project format, the only recommended cloud service for “working” projects is Dropbox. Period.

Nonetheless, I’m going to suggest ways to use iCloud Drive to get work from Mac to iOS and back, and from iOS device to iOS device. These are file transfer solutions, not sync solutions. They’re not automatic. They’re not “transparent.” They don’t happen in the background without you doing anything (once you’ve set it up). If you’re looking for a “set it and forget it” solution, these aren’t it.

What they are, is safe. They use iCloud Drive. You can automate parts of the process. Still with me? Good! Let’s get into the setup.

System Requirements

iOS Scrivener 1.2 or greater
iOS/iPadOS 11 or greater
Mac Scrivener 2 or greater
Any version of MacOS that supports iCloud Drive

For iOS 11:
FileApp
For iOS 12:
The Shortcuts app, and a shortcut as described here: UnZIP and Open In…

Mac – iOS:

Mac side:

  1. First, set up your iCloud preferences for maximum safety when working with Scrivener and iCloud Drive
    1. Open the Mac System Preferences app, and open iCloud preferences.
    2. Next to iCloud Drive, click the Options… button.
    3. Turn off “Optimise Mac Storage”, in the bottom left of the options dialog. This is essential. Scrivener depends on your projects being physically present on your hard/ssd drive. If any portion of a project has to be downloaded from iCloud, you risk project corruption.
    4. For maximum safety, turn off “Desktop and Documents Folders.” This is less urgent than the “optimise Mac storage” setting, but if you don’t need this for other apps besides Scrivener, please turn it off. You will not use this to transfer Scrivener projects.
  2. Next, set up a transfer folder.
    1. Open up an iCloud Drive window. Create a new folder, and name it something obvious, like “Scrivener Transfers”.

    Work on your Mac Scrivener project as you usually do. When you’re ready to stop work on your Mac:

  3. From the File menu, select File->Back up->Back up to…

  4. In the Back up to: dialog, check the “Back up as ZIP File” box towards the bottom of the window. This is essential. Here’s where you make this process safe for your data. By making a ZIPped backup and transferring that, you save your project in a single file that isn’t vulnerable to sync corruption like an unzipped, .scriv project.

iOS side:

When you’re ready to work on your project on your iOS device:

  1. Open iOS Scrivener.
  2. Navigate to your projects screen if needed.
  3. If there are any copies of your project on your iOS device:
    1. Tap the “Edit” button at the top of your vertical projects button.
    2. Delete the iOS copies of the project. This will eliminate any possible confusion by working on an old copy of your project.
    3. Tap the “Done” button
  4. For iOS 12 or 13
    1. Open the Files app
    2. Navigate to the “Scrivener Transfers” folder (or whatever you named it)
    3. iOS 13+:
      1. Tap on the (most recent) backup project. The Files app will unZip the project. Wait until the project is unzipped AND uploaded to iCloud.
      2. Tap on the unZipped project. It will open in Scrivener.
    4. iOS 12:
      1. Create an “Unzip and Open In…” shortcut as described in this L&L forum post: https://www.literatureandlatte.com/forum/viewtopic.php?p=287616#p287616
      2. Tap on your zipped project, and select Unzip and Open In… as your action.
      3. After unzipping, select Scrivener as your target. Your project will open directly in Scrivener.
  5. For iOS 11:
    1. Get a free third-party utility, FileApp. (Not the same as Files!!!)
    2. Open FileApp. Tap on the plus icon in the upper right corner. Then tap the import icon in the lower left.
    3. Tap Browse, navigate to your transfer folder on iCloud Drive, and select your zipped project. It will be copied to FileApp
    4. Still in FileApp, tap your project to unzip it there.
    5. Drill down into the unzipped project until you find a folder that has an extension of .scriv (very important!)
    6. Long press on that .scriv folder, then tap the export icon and open your project in Scrivener.

When you’re ready to put away your iOS device:

  1. Return to the projects screen.
  2. Tap the “Edit” button at the top of your vertical projects button.
  3. Select the project you just worked on.
  4. Tap the export button
  5. iOS Scrivener will make a zipped backup of your project
  6. Save to to the “Scrivener Transfers” folder (or whatever you named it) in Files
  7. (Optional) Delete the project from your iOS Scrivener app (select the project and tap “Delete” at the bottom of your screen) If you do this, you can avoid confusion about which version of your project you worked on last.
  8. Tap the “Done” button

Back to the Mac:

When you’re ready to start work on your Mac again:

  1. From the Finder, open the “Scrivener Transfers” folder (or whatever you named it) on the iCloud drive.
  2. Delete the unzipped project—it’s now old
  3. Double click on the most recent zipped version. Rename the unzipped project to something obvious (“My Project From iOS”) and drag it to your desktop.
  4. Go ahead and double-click the iOS version on your desktop to open it. Scrivener will incorporate the iOS changes. Close the project.
  5. Open your old Mac Scrivener project in your usual way.
  6. From the File menu, select File->Import->Scrivener Project
  7. In the Open dialog, select the project version from iOS that you dragged to your desktop.
  8. When you see the “Merge?” dialog, go ahead and select “Import and Merge”. After you’ve checked to be sure your changes made it over, you may delete the iOS version on your desktop (it’s secure in zipped form in your transfers folder.)

Optional Automation

If you’d like to have the “Mac Side” steps 3 and 4 automated, do this:

  1. From the Scrivener menu, select Scrivener->Preferences…
  2. Tap on the Backup icon
  3. Turn on these Backup preferences: Automatic backup, backup on close, backup on manual save, compress backups as ZIP files, use date in backup file names.
  4. Keep at least 25 backups.
  5. Choose your iCloud “Scrivener Transfers” folder as your backup location.

    Now whenever you either close your project, close Scrivener, or use cmd-s to save, a fresh zipped backup will be saved in your Scrivener transfers folder, named so you can tell them apart, ready to be opened in iOS Scrivener. If you don’t think you’ll turn off your Mac, close your project, or remember to type cmd-s, there’s one last automation step:

  6. Still in the Preferences dialog, tap on the General icon and select Automatic Quit. Put a checkmark beside automatic quit, and adjust the interval so that it’s not so short as to be annoying, but often enough that Scrivener will quit (thus making an automatic backup in iCloud) before you pull out your iPhone or iPad to work.

iOS – iOS

iOS to iOS is easier than the above in that we only need to worry about one environment. It’s harder because we have no way to automate any of this. Using this method to transfer files between two (or more!) iOS devices is totally dependent on user discipline to keep versions straight. Be told.

Prepare the Files app

  1. Open the Files app on your first iOS device, which I’ll call D-One.
  2. Next, set up a transfer folder in iCloud drive. Just as for Mac – iOS, create a new folder, and name it something obvious, like “Scrivener Transfers”.

Switching from D-One

When you’re ready to put away D-One, or switch to your other iOS Device, D-Two:

  1. Return to the projects screen.
  2. Tap the “Edit” button at the top of your vertical projects button.
  3. Select the project you just worked on.
  4. Tap the export button
  5. iOS Scrivener will make a zipped backup of your project
  6. Save to to the “Scrivener Transfers” folder (or whatever you named it) in Files
  7. (Optional) Delete the project from your iOS Scrivener app (select the project and tap “Delete” at the bottom of your screen) If you do this, you can avoid confusion about which version of your project you worked on last.
  8. Tap the “Done” button

Starting up D-Two

When you’re ready to work on your project on your second iOS device, D-Two:

  1. Open iOS Scrivener.
  2. Navigate to your projects screen if needed.
  3. If there are any copies of your project on D-Two:
    1. Tap the “Edit” button at the top of your vertical projects button.
    2. Delete the iOS copies of the project. This will eliminate any possible confusion by working on an old copy of your project.
    3. Tap the “Done” button
    4. For iOS 12 or 13
      1. Open the Files app
      2. Navigate to the “Scrivener Transfers” folder (or whatever you named it)
      3. iOS 13+:
        1. Tap on the (most recent) backup project. The Files app will unZip the project. Wait until the project is unzipped AND uploaded to iCloud.
        2. Tap on the unZipped project. It will open in Scrivener.
      4. iOS 12:
        1. Create an “Unzip and Open In…” shortcut as described in this L&L forum post: https://www.literatureandlatte.com/forum/viewtopic.php?p=287616#p287616
        2. Tap on your zipped project, and select Unzip and Open In… as your action.
        3. After unzipping, select Scrivener as your target. Your project will open directly in Scrivener.
    5. For iOS 11:
      1. Get a free third-party utility, FileApp. (Not the same as Files!!!)
      2. Open FileApp. Tap on the plus icon in the upper right corner. Then tap the import icon in the lower left.
      3. Tap Browse, navigate to your transfer folder on iCloud Drive, and select your zipped project. It will be copied to FileApp
      4. Still in FileApp, tap your project to unzip it there.
      5. Drill down into the unzipped project until you find a folder that has an extension of .scriv (very important!)
      6. Long press on that .scriv folder, then tap the export icon and open your project in Scrivener.

Repeat the cycle as needed. Enjoy!

Scrivener iOS Update (Yay!) #amwriting

After a long hiatus, Literature and Latte have updated Scrivener iOS to v. 1.2! This update fixes several long-standing, annoying, non-data-loss bugs. It also provides compatibility with iOS / iPadOS 13.

Bugs fixed:

  • All modern screen sizes supported. No more letterboxing!
  • Dynamic type better supported in the Binder and the remaining UI. If you like to cram stuff on your screen, you can. If you like big type, you can have that, too.
  • Fixed the search field disappearance bug.
  • Fixed the disappearing image link bug.
  • And many more!

I’m enjoying the ability to show more stuff in the Binder synopses. If you’re a Dark Mode fan, you’ll like the new Dark Mode support.

Many people protest iOS Scrivener’s Dropbox sync protocol. Loudly. I’m going to be writing a new series on an alternative to Dropbox sync with iOS Scrivener. Learn how to improve your data integrity, and transfer your Scrivener projects amongst your devices, iOS and otherwise, with a cloud service of your preference and tools provided by iOS / iPadOS 13.

Stay tuned!

Handwriting Input for Mac Scrivener—the Hard Way; AirDisplay v. YAM Air Review #amwriting

The most productive way for me to write fiction is handwriting, slow though it is. But I find the necessary transcription to digital form painful. Don’t even talk about typing from paper copy—repeating the stuff I’ve already written is like fingernails on a chalkboard. Even using a notetaking app that will convert a page of handwriting to digital text for pasting elsewhere requires a cleanup effort that drives me loopy. No, the way I’ve found that works for me is using a handwriting-recognition keyboard on iOS Scrivener. Do the cleanup as I write, that’s the ticket.

YAM Air lets me use my iOS handwriting keyboards to input directly to Mac Scrivener

Camp NaNoWriMo, though, meant I needed to keep track of my writing minutes. That’s hard for me to do on iOS. I have to start timers, turn off timers, restart timers… not to mention recording my results. It’s an error-prone process. So I stuck to the Mac most of July, where RescueTime tracked my app usage. But MacOS has deprecated its old Ink handwriting interface, so even if I had a graphics tablet it was typing for me on my Mac, until…

I noticed that one of the apps I use to make my iPad serve as a second monitor, AirDisplay, let me pull up the iOS on-screen keyboard. Yes, that let me use my iOS handwriting keyboards to input directly to my Mac!

All was not smooth with AirDisplay, though, and I can’t recommend it for this purpose. It was challenging to get Scrivener to stay visible—I found it almost impossible to keep menu bar menus accessible, let alone keep my insertion point visible so I could see my typing. The final deal-breaker was a bug in AirDisplay that means the Delete button on my iOS keyboards won’t work.

Maybe you can write without ever needing to delete a letter, but I can’t.

Disappointed, I wandered around the App Store and discovered the YAM (Yet Another Monitor) family of apps. YAM Air turned out to be the iPad-as-a-second-monitor app of my dreams.

When I bring up the iOS keyboard, the Mac screen stays stable behind it, so that it’s easy to access Mac menus. The stable screen position also lets me take advantage of typewriter scrolling in Mac Scrivener to keep my insertion point in view. Yes, if I need to access something at the bottom of the screen I must put away the keyboard, but if I need to do that I’ve stopped writing anyway.

Now, AirDisplay does a fine job as a second display app. Its iOS keyboard interface is buggy, though, and managing the display behind the keyboard is awkward. But YAM Air’s iOS keyboard interface is stable, and the display behind the keyboard is straightforward.

Also, YAM Air offers drag-and-drop between iOS and Mac. How cool is that? And all for $3.99 USD.

It’s YAM Air and handwriting on my Mac for me! Yay!

I Get Questions re: Adonit Pixel, iPad 6th Generation, and Notetaking #amwriting

A reader recently asked:

I read your post about using the adonit pixel with an ipad 6th gen!

I’d like to buy this gen ipad for notetaking @ school. You mentioned this pair worked fine (despite not being listed on adonit’s site as a compatible apple device)

I was wondering if you could describe what it likes to actually write notes on a notetaking app? it would help a lot with making my decision on whether or not to just chuck my pixel for the apple pencil.

First, my disclaimer: I’ve never actually used my iPad for note-taking in class, nor do I use anything else. I’m the world’s worst classroom note-taker. I survived my university experiences by borrowing others’ notes, reading classroom handouts, or by reading the text. Just reading, not taking notes. Occasionally, I’d use Post-its to mark important passages. My ADHD makes it difficult to learn from listening; if I try to actually take notes at the same time the result is that I learn nothing. My primary learning modes are reading and hands-on. I will make notes during hands-on exercises, though.

So given that my experience is 95% based on creating background notes for my novels, any note-taking app will work with the Adonit Pixel; turn it on and it will act like a plain capacitative stylus, or your finger. The problem is that if you want to be able to use its pressure-sensitive and palm-rejecting capabilities, you’ll need to use a note-taking app that supports those. Adonit have a list of apps that support these features with the Pixel on this page.

What’s more important, in my opinion, is choosing a note-taking app that works well with your method of note-taking. If your system works well with, say, Apple Notes, then use Apple Notes. Same for Notability, Goodnotes, or my personal favourite, NoteShelf. There are many others to choose among. I chose NoteShelf for its flexibility and its superior integration with Evernote, but Evernote integration may not be important to you. If the note-taking app which works best for you doesn’t support the Pixel’s pressure sensitivity and this is important to you, by all means go get an Apple Pencil.

Bose QuietControl 30 Review #amwriting #campnanowrimo

You who’ve been with me a while know that I can’t resist playing with new tech. So I ordinarily wouldn’t have bought the Bose QuietControl 30 (QC30) in-ear headset during July Camp NaNoWriMo—but I made the mistake of putting it on my birthday list, and to my astonishment, it arrived! (Thanks, Hubby!)

The Bose QuietControl 30

As an ADHD writer, I need a serious noise-attenuating headset. I’ve had a mid-level active noise cancelling (ANC) in-ear headset, the Audio-Technica ATH-ANC33IS, for years. It does great for airplane noise, but for coffeehouse music and conversation, not so much. I’ve had two gaming headsets, which do well on passive noise attenuation. But I left the quite good Hyper X Cloud II over-the-ear set behind at coffeehouses no fewer than three times, the last time for good. It just wasn’t meant to be. And the Razer Hammerhead BT—well, it’s just not up to attenuating the coffeehouse milieu, either, not even with Comply Foam Eartips installed.

Since I can’t stop losing over-the-ear headphones, there seemed to be only one choice for wide frequency, in-ear ANC—the outrageously expensive Bose QC30. Four times the cost of the ATH-ANC33IS or Razer Hammerhead BT, is it really worth that much money?

Yes. Yes, it is, if you need that level of attenuation. The QC30 drops outside music and loud conversation volume to such a low level that I can turn down the volume on my soothing background music and just write. OMG, it’s wonderful! Occasionally I start thinking that it’s not doing much—but then I turn off the ANC and hastily turn it back on.

The QC30 music quality is great, for my not-too-picky taste. Will it satisfy serious audiophiles? Probably not, but it’s not shabby. Check out this Sound Guys article if you’re curious. I’m happy with how it treats my Bach concertos, though.

There’s also the “Control” part of QuietControl. I can increase or decrease attenuation at will. In other words, I don’t have to dig an eartip out of my ear in order to talk to the coffeehouse barista, then replace it afterwards. I just lower attenuation, talk normally, then raise the attenuation back up to max.

Don’t be discouraged by the (comparatively) low ratings for the QC30 v. the Bose over-the-ear headsets. Expectations for Bose are high, and in-ear headsets always have lower ratings than their over-the-ear counterparts. Here are some common complaints:

  • The batteries die after two years. Rechargeable lithium batteries wear out. Depending on how many times you charge them, this isn’t unexpected. Not even Bose can change physics.
  • The QC30 doesn’t stand up to workouts. Bose doesn’t claim it will. Their sports headsets are not noise-cancelling. Their noise-cancelling headsets are not intended to stand up to sports.
  • The eartips don’t fit. They’re good eartips, provided in small, medium, and large, but of course they won’t fit everyone. Poor eartip fit is the cause of not only fit complaints, but many poor sound complaints as well. I’m lucky the large tips fit me, because the QC30 won’t accept third-party eartips. In my opinion, the inability to accept third-party eartips is one of its few flaws.
  • The neckband shifts position. It can slip off to one side a bit if I’m taking a brisk walk to the neighbourhood Starbucks whilst playing Pokemon Go. The only time I’ve had a real problem with this is if I’m listening to music, forget myself, and start dancing. This appears to be part of the “not ready for workouts” syndrome.
  • The ear wires/neckband physically wear out. I haven’t had mine long enough to give this a test. However, by design necessity in-ear headsets are more delicate than over-the-ear ones. The wires and components of the QC30 are heavier than those of my old AT headset, which has lasted me years. Many Bose customers complaining about this say that it happens after the 1-year warranty runs out—and that their expectations for Bose are that the set will last several years more. I’ll revise my review if this happens, but like my Audio-Technica set, I intend to treat my QC30 as if it’s made of glass. Similar complaints were rife about the AT set, and I managed to get five years out of it (it’s still going, in fact.) Honestly, I’ll likely wear out the battery before I wear out the rest of the device.
Tips for Using the Bose QC30 Headset

Update your firmware. There are many reviews complaining about the voice microphone for phone calls, sound quality, etc. My unit arrived with firmware 1.2.x. By the time I finished updating, the firmware version was 3.0.3! Don’t just depend on the Bose phone app, Bose Connect. I got a more recent copy of the firmware by going to the Bose update site, btu.bose.com. I have had zero problems with sound quality or with folks I call complaining about call quality.

Change the way you think about voice pickup. There’s no microphone in the control module. It’s not hidden in the neckband, either. No, the microphones(!) are on the earbuds themselves. So holding the control module or the neckband closer to your mouth won’t help. Just speak normally. I’d suggest keeping your voice even a bit softer than normal—one person I called said my voice was “over-modulated”. That meant that I was speaking too loudly for the mics and they were distorting my voice. But please do be sure you have the latest firmware (see above.)

Screen Protectors: RhinoShield Impact Protection vs. Bodyguardz HD Impact #amwriting #Rhinoshield

I’ve long used fancy impact protection screen protectors on my touchscreen devices—the protectors with multiple layers of polymers (AKA plastic). Typically, the top layer is oleophobic (literally “fat-fearing”, like the touchscreen it covers), glossy, and scratch-resistant, to mimic the touchscreen surface. The interior features layers of shock-absorbing and shock- distributing materials, with a non-residue adhesive next the touchscreen itself.

Image courtesy of Rhinoshield.io

I prefer these to the tempered glass protectors that are so popular now. This is because of what’s happened to my devices when I’ve dropped them, and what’s happened to acquaintances who dropped their glass-protected devices.

I’ve dropped my iPad while it was equipped with a Bodyguardz HD Impact protector—from a height of four feet, screen-first, onto an exposed sharp aluminium corner. A bare iPad would have shattered. Not only did my iPad screen survive, the (plastic, remember) protector wasn’t scratched.

An acquaintance had a similar experience with his glass-protected iPhone. The protector was shattered. Now, his screen beneath was fine—but he had to get that sharp shattered glass off his screen. Eventually he took it to an Apple store to get it picked off.

Add to that the facts that plastic impact protectors are lighter, thinner, and more stylus-friendly, and you won’t see my electronics sporting glass screen protectors any time soon.

So I should be a Bodyguardz customer forever, right? I was—but then I upgraded to an iPhone 8 Plus. Bodyguardz are phasing out their plastic HD Impact protectors. You have to search their site for “HD Impact” to even find them, and they’ve stopped producing them for newer phones and tablets. The 8 Plus isn’t on the list of supported devices.

Bummer. I searched the internet for a new vendor, and found Rhinoshield. The technology described is similar to the HD Impact, and I was impressed by their hammer video. I watched carefully and noticed the clear protector turning opaque under each blow, as the force was distributed and absorbed. In short, I could see it working. Way, way cool.

I’ve applied my new Rhinoshield to my iPhone 8 Plus, and found two more features impressive. First, the fit is—gasp—even better than that of the Bodyguardz product. Rhinoshield have made a superbly close-fitting protector with tiny, tiny cutouts for the home button, camera, light detector, and speaker. Bodyguardz, in contrast, make their cutout for the home button large, and put in a large “notch” at the top to accommodate the speaker, camera, and light sensor. Rhinoshield covers more of my screen.

Secondly, Rhinoshield’s recommended installation (the “hot dog” technique) resulted in the easiest screen protector installation I’ve ever done. After 48 hours, the only way to see the protector is to shine a light on it sideways to highlight the edges.

It’s a pity I didn’t find Rhinoshield earlier. But I won’t go back to Bodyguardz for my next screen protector, even if they still have one that fits.

Hint for Using a Layered Plastic Screen Protector

When an oleophobic screen protector comes from the factory, it feels “squeaky”, like your hair after a shampoo. After a day or three of use, oils from your fingers build up, and it feels as slick as glass. To make this go faster, put a tiny, tiny drop of cooking oil on the installed protector and spread it over the entire surface with your fingers. Take care not to get it into the speaker! Remove any excess with a microfibre cloth. Now the protector will feel as slick as your touchscreen.

iPad 6th Generation v. Adonit Pixel Stylus—Review #amwriting

It’s frustrating being an Adonit stylus fangirl, sometimes. Adonit themselves seem content to ignore new iPad releases. I’ve had an Adonit Pixel stylus since April 2017, and I couldn’t find any information as to whether my stylus would work with an iPad 6th generation, which has been available for more than a year.

My new iPad 6th Gen. and my older Adonit Pixel Bluetooth Stylus get along just fine!

But my iPad Air 2 (it’s three years old) was rapidly dying, so last week I replaced it with an iPad 6 and took a chance that I wouldn’t need to buy an Apple Pencil.

I win!

My Pixel stylus works fine with my iPad 6. All my drawing apps that supported the Pixel before still support it (except for Astropad, who are abandoning all pressure-sensitive styluses except for Apple Pencil.)

To give a brief recap of the relative merits of Adonit Pixel v. Apple Pencil:

Pixel Pros

  • It has 2048 levels of pressure sensitivity.
  • It works with iPhones.
  • It has programmable function buttons.
  • It’s less expensive than an Apple Pencil.
  • Its battery is durable. Mine is still going strong after 2 years.

Pixel Cons

  • It doesn’t work with iPad Pro models.
  • It connects with specific apps rather than with the iPad or iPhone as a whole.
  • It requires some setup to get the most from the stylus. In particular, a user needs to set his or her handwriting angle in each app that supports Pixel. The little hand position diagrams can be misleading—best practice is to try each angle setting in each app to see which works best.

Apple Pencil Pros

  • If Apple says it works with a device, then it does. No experimentation is needed.
  • It’s both pressure and angle sensitive.
  • Setup is like that of any other Bluetooth device.
  • It’s not limited to use only in apps that support it.

Apple Pencil Cons

  • The Pencil doesn’t work with any iPhone, and is limited to iPad Pro models, and very recent less-expensive iPad models.
  • It’s more expensive than the Adonit Pixel.
  • It has no function buttons.
  • There are problems with the Pencil battery if you don’t use the Pencil often.

Honestly, if I were buying now, it would be a hard decision. I’m accustomed to my apps that support the Pixel, so the Pencil’s usability in more apps isn’t persuasive. On the other hand, Apple will make sure that the Pencil will work with my iPad 6 through iOS upgrades regardless. There’s no such assurance for the Pixel.

If my Pixel should bite the dust, I’ll probably get an Apple Pencil. But as long as my Pixel holds out, I’ll enjoy pressure-sensitive drawing on my iPhone as well as on my iPad.