Journal-based folder structure in Google Drive

Feature requests
#1

I understand the reasons for maintaining a fixed default for automatic organisation of PDFs into folders in Google Drive, but I find the current structure extremely unhelpful and difficult to navigate.

Each folder (representing the first letter of the first author’s surname) contains 100s of PDFs. Some authors (or different authors with the same surname) have 10s of papers listed. Often I do not remember the name of the first author of a paper I wish to read or annotate. I therefore struggle to find the paper I want.

I am far more likely to remember the journal in which the paper was published. Given that there are many more journals in my library than there are letters in the alphabet, each folder will contain a far more manageable number of papers.

I’d therefore very much like a journal-based file structure rather than an author-based structure.

Thanks!

3 Likes
#2

I was concerned when I first saw the alphabetical structure, but then I realized that 95% of the time, if I need an article, I can find it via Paperpile. For the other 5% of the time, I can look up the name of the author in Paperpile quickly and then find the article. And that 5% is getting smaller, because I’m finding the sharing feature to be quite useful. Finally, if I really need the file, I can open in paperpile, download it to desktop. So, I rarely even go into the files. I don’t doubt that it’s annoying for you, but curious what you do that these approaches don’t work. - Mark

#3

I spend a lot of time on mobile and offline.

#4

Another complication is that only journal articles have a journal to sort by. Some users mostly cite books or other resources. Clearly there would have been solutions around that but the cleanest is the sorting by author.

Also some users have mostly papers from a few journals, say Phys Rev. They would end up with hundreds of papers in just a few folders. That’s not ideal for human searching and also means some efficiency issues for our sync algorithm.

#5

I’d be more happy if file structure on Google Drive mirrored that in Paperpile. I’ve heard that they decided against this, but I haven’t heard a strong argument. I guess it only might have been more challenging programmatically to keep everything in sync when files are moved across folders in Paperpile and this would have to be mirrored in Google Drive, and vice versa. However, there are a couple of sync apps, including open-source ones, that could have been taken advantage of.

Sorting by journal title would be useless for me - I don’t care which journal has the article been published in. The only sorting that would make sense in my case would be either alphabetically by title, or “year of publication[space/dot/hyphen]title”.

#6

Journal-based folders in gDrive are important, and for me it’s a must have.

@stefan What you could do to implement it and make everyone happy: Leave your Alphabetical folder structure, let the user decide where to create a journal-based folder and clone each corresponding journal pdf in this folder. This clone operation can also be done manually, just click Shift+Z on a file/folder (No influence on data usage). That’s possible because of google’s special filesystem, it’s not folder oriented, but more like a big table - the folders we see are just tags.

I could give a long explanation why I need it, but it’s easier to explain that all the well established interaction principles don’t work anymore if you have all files in a single folder.
P.S.: Looking through the forum I see that I’m not the only one having usability problems with this one-folder solution.

1 Like
#7

If I understand correctly, the main reason someone would need a different file structure is if they are looking for a paper on mobile? (As is pointed out above, one can otherwise find the journals via Paperpile.) It seems to me that this problem will be solved when Paperpile releases their mobile app. Unless I’m missing something?

#8

You are missing the mobile app - like all of us.

Paperpile works great on a regular basis in an office on campus with fast and stable internet. But when that procrastinated wall of work hits you and you need to work in an airplane or in a train or in a different country without stable internet access, things can get quite frustrating. And since development of features is (understandably) slow I am also very interested in more intermediate fixes that facilitate offline work like the requested folder structure, persistent bibtech export of the library and so on. I do like the approach to do a few things right so I can get that things are sidelined that I found important.

More generally speaking I disagree with the general response of the devs regarding feature requests as: this is the first time we have heard someone mention this so it is probably not essential to many users. I doubt the target audience of this software spends a lot of time requesting features on a forum, much less add their names to an existing request. If you want to know how popular a feature is, have people vote on it with something like http://www.uservoice.com .

3 Likes
#9

We get thousands of emails and in-app messages. So I think we have a very clear understanding what users want. Assume we get say 200 emails asking for a word plugin and say 5 for customized folders. I think we know everything we need and an additional voting mechanism would not add much. Uservoice is pretty much also a forum so you would also only get a fraction of people bothering going there, signing in and voting.