Update. I’ve written a post that follows up on this one.

I want to make it clear that although I am documenting some glitches here, I highly recommend Papers for Mac.

In Cognitive Productivity I described and advocated for a 2s rule: You need to be able to access 80% of the files you work with on any given day within 2s. So, if there are a 10 PDFs that are critical to your project, and you need access to some random file in that lot, 8 times out of 8 you should be able to get to such a file in 2s. Obviously, if you want to access the same file twice that day, then it the probability of quickly accessing it should increase.

This is a very important rule, because when you are doing cognitive work, time is of the essence. For example:

1. Information in “working memory”, decays rapidly in your brain. If takes a while to get to that file (which for knowledge workers is often a PDF file), your mental context may start to get fuzzy. This is related to the finding that task switching costs a lot, and that multi-tasking doesn’t work.
2. Also, if you are working with lots of files, as many of us are, then those seconds quickly add up.
3. In order to work deeply with knowledge resources, you often need to create “meta-docs” (notes about your notes). For these meta-docs to be useful, you must be able to create, store and access them very quickly.

I’ve talked with hundreds of people about their file access strategies. Alas, very many, don’t have a system that satisfies this rule. (I’m preparing to do empirical studies on this.) As a result, many people have given up on external note-taking. Gasp! They might still create inline annotations. But as I argued in Cognitive Productivity, that is sometimes not good enough.

Apps for Managing Knowledge Resources

Many rely on applications to manage their key knowledge resources. Example apps include Reference management software and archiving apps like Evernote, DevonThink and Ironic Software Leap or Yep.

There are significant problem with many of these apps. I am not a fan of apps that put my knowledge resources in a proprietary database or, worse, the cloud. That is far too indirect, risky and slow. Furthermore, it cuts me off from essential OS X and third party tools like launchers, such as LaunchBar (ObDev) and Alfred. Also, I side with Apple co-founder Steve Wozniak with respect to cloud services. Obviously privacy/security are an issue. And the multiple number of cloud services is another. Availability (service outages) even just potentially is a concern. I won’t repeat all the issues and arguments here. That is not to say I don’t use cloud services. But I don’t want to put the bulk of my key knowledge resources in “the cloud”.

In Cognitive Productivity I showed how to use LaunchBar to satisfy the 2s rule with apps that store information properly on the filesystem.

Springer’s Papers 3: Issues with Filenames and Access to PDF Files

This brings me to Papers3 now owned by Springer, my reference management app of choice. (There are many alternatives and some fine candidates.) Papers2 stored files on the filesystem in a very readable manner. Then came Papers3, which introduced Dropbox syncing. For reasons alluded to above I won’t store my PDFs in Dropbox. Unfortunately, Papers3 introduced opaque file naming along with Dropbox integration. They also initially made file access opaque for regular users (giving them an EverNote-like experience). But I worked around those issues. And Springer relented.

All was then well with Papers3, for many of us at least, until recently they introduced Virtual Disk and Wi-Fi syncing.

I had long wanted Wi-Fi syncing, for my benefit and that of my readers, because it potentially provides a secure, cloud-free way to sync papers between devices. So earlier this week I tried this feature out.

This led to a couple of issues.

First, their iOS app Wi-Fi syncing feature is not reliable. In fact, Papers for iOS frequently crashed during Wi-Fi sync. It did provide me with my Papers meta-data (file names and folders), which may have allowed me to patch together a workflow involving BitTorrent Sync.app. However, I found that iOS BitTorrent Sync.app also crashed frequently, at least when I tried to sync all my PDFs. (Neither Papers3 nor BitTorrent Sync.app on iOS actually seem to want you to replicate an entire folder. The option is disabled by default in both apps.)

The first problem was not that serious because I could simply stop using Wi-Fi sync, one would think…

But then I noticed something… Papers 3 no longer assigns human names to newly imported PDF files. So instead of a file being named, say “Sloman-2004-What are theories of emotion about-Sloman2004tw” it would be named something cryptic like “182BF253-6B85-46C5-9B8B-8AFBFA6756E3.pdf”. (Because I have a kick-ass, quite comprehensive, activity tracking-system —which I will contribute to the literature on “the quantified self” —I was able to ascertain that the appearance of this show-stopping filenaming problem coincided with my Wi-Fi syncing.) This was despite the fact that Papers’ Preferences Library tab was still clearly configured to have papers sorted into folders by type, author, year; and papers named by author, year, and title. Papers is now ignoring my orders (or breaking its promise). Rats!

Now obviously that filenaming issue is a major problem. I can’t use spotlight (queries like “name:sloman name:.2004 name:.pdf” or LaunchBar (with a string like “Slo2004whem”) to get to my new PDFs!

So I looked into this and found that Papers recently introduced a virtual file system which provides a view onto the papers database that respects the human naming contract. This could in principle be helpful for the 2s rules, though non-technical users may have a problem. I’m reasonably technical 🙂 . But I can’t expect my clients and customers to be technical. Still, I investigated. The Papers Virtual File System, which does not seem to be a regular disk image, is populated by Papers with one’s entire papers library, structured in folders and papers as it used to elsewhere before (per my configurations). Not “Rats!”

However, this folder is not indexed by Spotlight. (A milder version of this issue arose in the early days of Papers3.) And so far I have not been able to get LaunchBar to index this. I can think of work-arounds for this, given that the information is available in the Finder. Or perhaps there is a simple solution? But “no”. In May, Springer Papers explicitly wrote on their support page:

Please note that the “browse in finder” feature is still at its beginnings and we have many plans for improvement (e.g., Spotlight support is high on our TODO list).

Well, I could write a script that would create and maintain aliases or symbolic links to Papers’ virtual file system. However, it’s not reasonable to expect customers to do this. I need to make recommendations to my readers, and not ask them to apply hacks.

The problem isn’t just that the filename is bad on disk. It’s that when I open a PDF, I see the cryptic filename in the File window of my PDF reader (Skim.app). So navigating between these files is not easy.

I have a support ticket with Springer on this filename issue. I am confident that Springer will fix this issue promptly or propose a work-around. They responded to concerns regarding their initial release of Papers3. I stuck with them (using work-arounds and hacks to overcome the bumps). And I don’t regret doing so. I highly recommend the app.

Meanwhile, I will use Time Machine to revert my Papers library and presumably a bunch of ~/Library/ papers configuration files.

You might want to take the foregoing into consideration before enabling Wi-Fi syncing. It is altogether possible that the cryptic filename issue is due to some other problem. Maybe there’s a user error here. I quickly searched and couldn’t find others who had this problem. I will update this post when I have further pertinent information.

Updates

2015-08-07 5:45 PM PT. The first time I tried to recover from Carbon Copy Cloner backup I used all but one of Springer’s instructions, which didn’t solve this problem. I had skipped this step: “Make sure that […] citations is not running”. Newly imported files were still being assigned cryptic file names. To be safe, the second time I went beyond the instructions and: (a) I deleted all my Library cache files related to Papers; (b) I rebooted before and after doing the backup procedure. I again ensured no other copies of my Papers might still be referenced by Papers.app. To save some time, I used my buggy Papers3 library folder to reimport the PDFs that had I had added since my last backup. All seems to be working now. Of course, I will need to re-add the lost meta-data of papers that Mekentosj couldn’t automatically resolve.

Fortunately, my Friday evening date is a couple of hours late. So I can make up some of the lost time before she and I watch Out of Africa together.

2015-08-15

Springer promptly provided me with very helpful feedback. I’ve posted an update here.