Support for mobile devices

As a general note of support, my Android tablet is increasingly my primary work horse for serious research. It is ideal for finding, reading, and annotating papers (especially with stylus). While I love Paperpile on the desktop, I am frustrated that it is simply unavailable where I would use it most. Here are what I would suggest as the essential features to enable on a tablet:

  1. Read access to pdfs in account. It’s extremely important to be able to quickly access key articles on the go, especially at conferences, and in meetings.
  2. Upload articles to account. I hunt down research articles frequently on tablet, and it is obnoxious to have to find them again later when I’m near a desktop.
  3. Annotation support. The stylus on a tablet is really ideal for annotating pdfs, making this feature actually more useful on a tablet than a desktop.
8 Likes

For point number 2, may I suggest Push Bullet. It’ll allow you to send links (even pdf’s) between all of your devices. It has saved me from the exact problem. I know you want a more comprehensive experience with Paperpile, but this could be a work around till then.

Hope that helps.

1 Like

What is the status and road map for this feature? As I understand it development has focused on metaPDF. However, the more I use Paperpile, the more I wish I we had a legitimate mobile option. Not just a star papers to read later, or searching the file directory on google drive. I’m sure many of us are interested in a road map for this feature.

Thanks

1 Like

I second that. I mentioned this in another topic - it would be very helpful to have a bit more transparency on which features are accepted and prioritized for implementation, and what is the overall roadmap for Paperpile development.

2 Likes

We don’t share public roadmaps. Roadmaps change all the time and if we miss a milestone our users get disappointed and if our users are disappointed we feel bad about it even though we most likely did work hard… So no one really wins.

Even though I’m not sharing time frames, I think from what I’m writing here on the forum it’s pretty clear what we are working on. Our current priorities are: integrating MetaPDF in Paperpile, EZproxy support, Word support and Mobile.

This is not a ranked list, we work in parallel on several things. Also this selection of priorities is not by chance, it’s supported by all the data we collected here in the forum, from support messages and our feedback form we send every paying customer.

Whenever something is ready to ship we will release it.

2 Likes

Shortly after I wrote this question I found your answer to not sharing roadmaps and read the associated articles. I understand. I love the product and will continue anxiously await mobile support!

Thanks for the response and clarification.

By “roadmap” I mean the items you guys accepted for implementation, not necessarily the anticipated release dates.

We try to answer all feature requests one by one. If it’s unclear what we think about a feature and how likely it is to see it implemented just ask.

Please at least one version to read the papers within Paperpile on an Ipad. Either using Safari or Chrome for ipad. I really don’t want to go back to Mendeley which works really fine on my ipad.

1 Like

We’ve tried a read-only version for mobile and other browsers. It sounded easy enough but we have found that this is not the best use of our resources. In particular supporting a decent workflow to download and open PDFs on mobile is not straightforward. We made the decision to rather focus on proper mobile support than wasting time on half-baked solutions (which would also come with a huge support overhead).

We stand by the decision more than ever, even if we lose customers back to Mendeley. I’m afraid this is all I can say at the moment. I probably should add that I’m the one here in the forum who wants a mobile version the most…

9 Likes

Fair enough! I will be looking forward for the proper mobile support.
:smile:

+1 This post summarizes my desires for Paperpile also.

Please ensure that annotations are portable across PDF readers. (Some annotators appear to use propriety formats that aren’t visible in other viewers.) I’m a Linux + Android guy, and I particularly like the combination of evince on the desktop and RepliGo reader on my tablet.

Please ensure that annotations are portable across PDF readers.

The annotation tool app.metapdf.com (made by Paperpile) already uses open standards for PDF annotations, so I’m sure this won’t be a problem.

Just adding support to the call for a version of paperpile on iOS. The most important feature for me would be the ability to add papers and organize them. I discover many papers over Twitter, save these to Pocket, and then comb through my Pocket entries and add some to Paperpile. This would be much more pleasant to do on my iPad than on my laptop. Annotating .pdfs has plenty of good work arounds that are compatible with Google Drive, so this is a much lower priority for me. Being able to cite while writing in Google Docs is also a lower priority, though this would also be handy too.

After reading this thread, I would like to offer the following hopefully helpful suggestions.

Since stored PDF files reside in a folder that is accessible from the mobile Google Drive app can’t you just browse that directory tree to read articles in your Paperpile collection?

Since you can make annotations in various readers when opening from Paperpile, I assume this does not corrupt the Paperpile database, although maybe there is some reindexing that goes on in the background when opening a PDF from within Paperpile?

There is a feature of the F1000 service, from another research tool provider, that allows you to select a monitored folder for adding new references. If Paperpile had a similar sub-folder for scanning new references, it would simplify adding them from any device. Tags and other Paperpile database specific annotations would need to be added afterwards from within Paperpile.

Haven’t experimented yet, since I am not inclined to risk corrupting my Paperpile database until I hear back from this forum.

Cheers!

Yes, the whole idea of Google Drive sync is to make the papers available (i) on all devices and (ii) for all apps. So many users already read their papers on their mobile devices through Google Drive.

The “watched” folder idea is something that has been suggested before. I think also Mendeley has such a feature. The problem is it’s technically not possible with our current privacy settings. Paperpile can’t see any files that you have not uploaded through Paperpile. That’s a good thing, we don’t want to read your Google Drive! But it means we can’t do everything that’s possible for a Desktop app where any app can read all your files.

1 Like

I know you’re all working hard. The scope detailed here is huge and I understand why it’s taking time.

However, the ability to add items to PP from mobile is a killer feature. Communication and by extension, links to references, happen on mobile. Keeping a copy of Mendeley installed just for this one use case is dumb.

I’ve remained subscribed in the hope that mobile support will drop soon. Please either address the issue or release a public api. This is taking too long.

2 Likes

Actually it’s going much faster than expected. I’m afraid there is no way for us to prioritize this higher than we already do. A public API would only be a distraction and I don’t think no third party developer would be able to spend more time and money on this than we do.

1 Like

Great news Stefan. I’m appreciative of all the hard work your team is putting in.

I’m not sure I or any other developer has more incentive to pour more resources into this than you are already. I’m glad to hear you’re ahead of schedule. My question was, why aren’t you reducing the scope? Building less is one sure way to speed things up.

You clearly already have a clipping api for your chrome extension so I must ask what would be so difficult about making it public?

We actually already have reduced the scope. Rather than have a full featured app on one platform first and delay the other platform for another year, we plan on releasing simple apps for Android and iOS relatively closely to each other.

Releasing a public API is not “difficult” in a sense we don’t know how to do it. It is extremely difficult however given that we need the resources elsewhere and an API needs lots of work to be useful. Things like authentication, rate limiting, API design, documentation, update management, developer communications… is all part of that. It’s a huge liability to have developers relying on a API. It’s not something we can do at the moment.

That said, the new mobile apps and the Word plugin will use some generic APIs which we hope to release publicly at some later point.

1 Like